On-Premises ERP to Business Central Cloud Migration: What You Need to Assess Before You Move
For many organizations, the move from an on-premises ERP to the cloud does not begin with urgency. It begins with friction.
At first, the friction feels manageable. A reporting request takes longer than it should. A server issue creates a delay that becomes “normal.” Remote access works, but not well enough to stop people complaining about it. A customization no one fully understands is still running because nobody wants to touch it. Finance gets the numbers out, but month-end depends too heavily on workarounds, spreadsheet patches, and institutional memory.
Eventually, that friction becomes a pattern. And once it becomes a pattern, leadership starts asking a more serious question: is it time to move to the cloud?
That is where many businesses make the first avoidable mistake. They start discussing migration as if it were mostly a technical event. They talk about timeline, go-live, software subscriptions, and data transfer. Those things matter, but they are not the real decision. The real decision is whether the business is ready to move from an older operating model into a modern one without dragging unnecessary complexity, risk, and cost along with it.
That is why any successful on-premises ERP to Business Central cloud migration should start with a cloud assessment, not a cutover date.
This matters whether you are moving from Dynamics NAV, Dynamics GP, Sage, or another legacy on-prem ERP. The destination may be the same, but the migration logic is not. The customization profile, data quality, reporting dependencies, security posture, and integration footprint all shape whether the move becomes a simplification exercise or a very expensive reinvention of old problems.
Why businesses move to Business Central cloud in the first place
When businesses talk about cloud ERP, the conversation often gets flattened into a few predictable talking points: lower infrastructure overhead, easier remote access, automatic updates, and stronger security. Those advantages are real, but on their own they rarely justify a move. Most leadership teams are not replacing an on-premises ERP just because “the cloud is better.” They move when the current system is no longer keeping pace with how the business needs to operate, report, secure data, and scale.
In practice, that usually shows up in familiar ways. Finance teams spend too much time working around process gaps. IT carries technical debt tied to aging servers, unsupported customizations, and integrations that are poorly documented or overly dependent on a few internal resources. Approval workflows become inconsistent, reporting leans too heavily on manual effort, and distributed users expect a level of accessibility and performance that older on-prem environments struggle to deliver reliably. Even routine upgrades or change requests start feeling bigger, slower, and riskier than they should.
This is where Microsoft Dynamics 365 Business Central becomes more than just a cloud replacement for a legacy ERP. For many organizations, it is attractive because it sits inside a broader Microsoft ecosystem that already shapes how the business works. That includes Azure for cloud infrastructure and security services, Microsoft 365 for collaboration and productivity, Power BI for reporting, Power Automate for workflow automation, and other connected tools that help reduce the operational distance between finance, operations, IT, and leadership.
The value, then, is not simply that Business Central runs in the cloud. It is that Dynamics 365 Business Central, combined with the wider Microsoft platform, gives companies a chance to modernize the structure around the ERP itself: security governance, extension strategy, reporting discipline, integration design, business continuity, and long-term supportability. That is why some migrations create durable operational improvement, while others simply move legacy complexity into a new subscription model with a more modern interface.
The real mistake: treating migration like a move instead of a redesign decision
A surprising number of ERP migration projects begin with a false assumption: if the business can technically move, then it should move as quickly as possible.
But technical feasibility is only one part of readiness.
A company may be fully capable of migrating data into Business Central cloud and still be poorly prepared for what happens after go-live. That is especially true when the current ERP environment contains years of layered workarounds, old customizations, duplicate reports, inconsistent access controls, or undocumented integrations that “just work” because one person knows how they behave.
That is why the assessment phase matters so much. A good assessment does not ask only whether migration is possible. It asks better questions:
- What should be carried forward?
- What should be redesigned?
- What should be retired?
- What creates risk during cutover?
- What will increase long-term cost if we keep it?
- What will improve the business if we fix it now instead of later?
Those questions are where the real return on a cloud ERP move is found.
What actually changes when you move from on-premises ERP to Business Central cloud
A move to Business Central cloud changes more than hosting. It changes responsibility boundaries, operating habits, and the way finance and IT work together.
Here is the simplest way to think about it:
| Area | On-premises ERP | Business Central cloud |
|---|---|---|
| Infrastructure | You manage servers, patching, availability planning, and local dependencies | Microsoft manages the service infrastructure |
| Access and identity | Often tied to legacy network patterns or inconsistent access methods | Modern identity controls become central to security and governance |
| Upgrades | Heavy, irregular, often avoided | Ongoing release readiness becomes part of normal operations |
| Customization model | Legacy modifications often accumulate over time | Extension discipline becomes more important |
| Support model | Infrastructure and application issues are often blended together | Operational support shifts toward process, permissions, integrations, and adoption |
| Reporting maturity | Manual exports and spreadsheet logic often grow over time | Better governed reporting becomes possible, but only if data and definitions are cleaned up |
This is why moving to the cloud should never be framed internally as “we will have fewer things to manage.”
In reality, the business manages fewer infrastructure tasks, but must manage governance more intentionally.
That governance includes:
- identity and access
- role design
- change control
- testing discipline
- extension oversight
- reporting ownership
- post-go-live support
If these areas are weak before migration, moving to the cloud can expose the weakness rather than solve it.
Start with a cloud assessment, because that is where the real migration risk lives
The purpose of a cloud assessment is not to produce a long report that nobody reads. Its purpose is to give decision-makers a realistic view of what the migration will cost, what it will change, and what could go wrong if the business treats it like a simple lift-and-shift.
A strong assessment usually covers six areas.
1. The real ERP footprint
Many companies think they know their ERP footprint until they try to migrate it.
The question is not what modules are technically available. The question is what the business actually relies on. That includes not only finance and operations, but also:
- reporting packs
- approval workflows
- integrations to payroll, CRM, eCommerce, banking, EDI, or WMS
- local practices that never made it into formal process documentation
- key reports that leadership expects every month
This step matters because hidden dependencies are what turn a “manageable” migration into a painful one.
2. Customizations and extensions
Legacy ERP environments often contain years of accumulated changes. Some are still essential. Others were built for an old business model, a temporary workaround, or a process that no longer exists in the same form.
This is one of the most important points in any on-premises ERP to Business Central cloud migration: not every customization deserves to survive the move.
A mature assessment will separate customizations into three groups:
- still critical and worth redesigning properly
- useful but replaceable with standard functionality or modern extensions
- obsolete and ready to retire
This is one of the clearest ways to reduce both migration cost and future complexity.
3. Data quality and reporting logic
Data issues are often tolerated in legacy environments because teams know how to work around them. Migration removes that comfort.
Duplicate customer records, inconsistent item structures, outdated vendors, legacy chart of accounts decisions, and poor dimension discipline all create downstream problems. So do management reports that depend on manual adjustments outside the ERP.
For finance leaders, this is not just a technical issue. It is a credibility issue. If the migrated system produces numbers that require explanation every month, trust in the project erodes quickly.
4. Security and access governance
One of the most common misconceptions in cloud ERP is that moving to the cloud transfers security responsibility away from the customer.
That is not how it works.
Business Central cloud can materially improve security posture, particularly when paired with Microsoft identity tools such as Entra ID, MFA, and Conditional Access. But those tools still require decisions. Someone must define roles. Someone must enforce least privilege. Someone must control partner access. Someone must review whether permissions still match job responsibilities.
For finance, this matters because access design directly affects control quality. For IT, it matters because modern cloud security depends less on perimeter assumptions and more on identity discipline.
5. Integration risk
Many ERP projects underestimate integration complexity because the systems involved are already live. That creates a dangerous illusion: if the integration works today, it must not be that risky.
In reality, existing integrations often survive because they are familiar, not because they are robust.
Any serious cloud assessment should identify:
- every system that exchanges data with the ERP
- who owns that integration
- how often it runs
- what breaks if it stops
- whether it can move as-is, needs redesign, or should be retired
This is especially important in businesses with warehouse systems, eCommerce platforms, third-party logistics tools, payroll software, payment integrations, or banking connectivity.
6. Peak-period performance and cutover sensitivity
Performance is rarely just a question of whether the cloud platform is capable. It is usually a question of how the business uses the system.
Month-end spikes, remote users, reporting bursts, large imports, high-volume integrations, and poorly timed background jobs can all shape the user experience. If this is not understood before migration, teams often label the problem incorrectly after go-live by saying “the cloud is slow” when the real issue is workload design, network behavior, or extension inefficiency.
The most important cloud migration question: what should move, what should change, and what should end here?
This is where good migration programs separate themselves from expensive ones.
Every on-prem ERP environment contains a mix of:
- processes worth preserving
- processes worth redesigning
- and processes that should be retired completely
That distinction matters more than most migration timelines.
What should usually move:
- core financial controls that still serve the business well
- clean master data
- essential historical records
- validated reporting logic
- operational workflows that still match current business reality
What should usually be reconsidered:
- approval paths built around outdated roles
- manual reporting workarounds
- screen or form changes that reflect old usability issues
- integrations with unclear ownership
- custom logic created to compensate for obsolete limitations
What should often be retired:
- dead reports
- duplicate processes
- “temporary” customizations that became permanent by accident
- workarounds for departments that no longer operate the same way
- local exceptions that no longer justify enterprise complexity
This is why cloud assessment creates value even before migration begins. It gives the business a structured way to simplify before it modernizes.
Business Central cloud security: what gets better, and what you still own
Security deserves special attention because it is often discussed too vaguely.
The real cloud security conversation is not about whether data is “in the building” or “offsite.” It is about whether the organization has a stronger, more governable security model after migration than it had before.
That is where Business Central cloud has a real advantage. Modern identity and policy controls give companies a much better foundation than many legacy on-prem environments. But the phrase “shared responsibility” has to be taken seriously.
Microsoft is responsible for securing and operating the service infrastructure. The customer remains responsible for access governance, role design, policy enforcement, administrative discipline, and process-level control integrity.
That distinction matters because many of the most damaging ERP security issues are not infrastructure breaches. They are governance failures:
- shared accounts
- excessive privileges
- weak approval structures
- partner access with no periodic review
- dormant users with live permissions
- poorly documented admin rights
A strong migration program uses the move to Business Central cloud as an opportunity to correct these patterns, not carry them forward.
Cost: how to evaluate the migration honestly
One of the most useful ways to improve cloud ERP decision-making is to stop talking about “the cost” as if it were one number.
In reality, there are at least three different cost categories that matter.
Cost to migrate
This includes implementation, migration work, testing, training, process redesign, data cleanup, and cutover planning.
Cost to run
This includes subscriptions, support, integration monitoring, add-ons, reporting maintenance, and steady-state administration.
Cost to change
This is the category many businesses underestimate. It includes the effort required to adapt the system over time as the business evolves. If the migrated environment is cluttered with unnecessary complexity, every future change becomes harder and more expensive.
That is why the best CFO-led evaluations of on-premises ERP to Business Central cloud migration look at a three-to-five-year horizon rather than a project-only budget.
| Cost lens | What it should include | Common mistake |
|---|---|---|
| Cost to migrate | implementation, testing, cleanup, training, cutover | underestimating effort tied to legacy complexity |
| Cost to run | licenses, support, integrations, add-ons | assuming recurring ownership will be low by default |
| Cost to change | future enhancements, release testing, expansion needs | ignoring how today’s decisions affect future agility |
If a migration budget looks attractive only because it excludes cleanup, redesign, testing, or post-go-live stabilization, it is not a realistic budget.
Downtime: why it is usually a planning problem, not a cloud problem
Downtime is one of the most emotionally charged parts of ERP migration because it affects trust across the business. Leadership can absorb a serious project. What they struggle to absorb is a chaotic go-live.
The key point is this: downtime is rarely caused by the cloud itself. It is usually caused by weak preparation.
The biggest drivers of downtime tend to be:
- data that was not validated properly
- reconciliations that were left too late
- integrations that were only partially tested
- unclear sequencing during cutover
- user permissions not ready on day one
- rollback assumptions that were never realistic
A practical cutover strategy should fit the business, not the project deck. Some companies can support a big-bang cutover. Others are better served by a phased approach. Highly controlled environments may consider parallel validation in limited scenarios, though that often adds more strain than expected.
The important thing is not choosing the most impressive approach. It is choosing the one the business can execute with discipline.
Performance: why user complaints after go-live often trace back to pre-migration blind spots
Performance is another area where weak diagnosis creates weak decision-making.
When users say the cloud is slow, they may be describing several different problems:
- remote access latency
- overworked integrations
- inefficient extensions
- reporting loads at the wrong time
- poor scheduling of background processes
- large data volumes being handled badly
This is why performance assessment should happen before migration. If you know when the business experiences peak load, which users are remote, which reports are critical, and which integrations create the most volume, you can plan for a much better post-go-live experience.
Performance is not just a platform characteristic. It is the outcome of architecture, design, process timing, and operational discipline.
Source system matters: NAV, GP, and Sage each bring different migration realities
Although many blogs flatten this topic into one generic cloud migration story, the source system matters a great deal.
Moving from Dynamics NAV to Business Central cloud
NAV environments often carry a longer history of custom development. The key challenge is deciding how much of that history still serves the business and how much should be redesigned or retired. In many NAV migrations, the real work is not data movement but rationalization.
Moving from Dynamics GP to Business Central cloud
GP environments often reveal more surrounding process dependency than expected. Reporting logic, approval habits, and adjacent tools may sit outside the system more heavily than leadership realizes. That means the assessment must look beyond the application itself.
Moving from Sage to Business Central cloud
Sage migrations often expose the need for stronger process standardization and cleaner data structures before the value of Business Central is fully realized. In these situations, migration and operational discipline improvement go hand in hand.
This source-system nuance matters for ranking, but more importantly, it matters for readers. A useful blog should help them see that not every legacy ERP creates the same migration path.
Quick assessment checklist before you commit
Here is a simple way to pressure-test readiness before moving from an on-prem ERP to Business Central cloud:
| Question | If the answer is “no,” what it usually means |
|---|---|
| Do we have a clear inventory of customizations and integrations? | Scope and cost are probably understated |
| Do we know which reports and processes are genuinely business-critical? | Cutover and post-go-live support risk will increase |
| Are our user roles and access rules current and defensible? | Security and control design need attention before migration |
| Do we understand our data quality issues? | Reconciliation and reporting trust may suffer after go-live |
| Have we separated migration cost from long-term run cost? | The business case is likely incomplete |
| Do we know which source-system habits should not be carried forward? | Complexity may simply be recreated in the cloud |
FAQs
What is an on-premises ERP to Business Central cloud migration?
It is the process of moving from a legacy on-prem ERP system, such as NAV, GP, Sage, or another on-premises platform, into Business Central cloud, including data, processes, user access, integrations, security design, and reporting readiness.
Why is a cloud assessment important before ERP migration?
A cloud assessment identifies the issues that shape migration risk and long-term success, including customizations, data quality, security gaps, integration complexity, reporting dependencies, and cutover readiness.
Is Business Central cloud secure for finance and operational data?
Yes, Business Central cloud can provide a strong security foundation, especially when combined with modern identity controls like MFA and Conditional Access. However, customers still remain responsible for governance, permissions, policy enforcement, and access review.
What causes downtime during ERP cloud migration?
Downtime is usually caused by poor preparation rather than the cloud platform itself. Common causes include weak data cleanup, incomplete integration testing, unresolved reconciliations, and unclear cutover ownership.
How do you estimate the real cost of moving from on-prem ERP to Business Central cloud?
The best way is to evaluate cost in three layers: cost to migrate, cost to run, and cost to change. Focusing only on licenses or project fees usually understates the real investment.
Can businesses migrate from NAV, GP, or Sage to Business Central cloud?
Yes, but each source system creates different migration considerations. NAV often involves more customization rationalization, GP often reveals adjacent reporting and process dependencies, and Sage often requires stronger standardization before the migration delivers full value.