Migrating from Legacy and On-Premise ERP to Business Central

There is a particular kind of ERP that a lot of organizations are stuck with. It works, mostly. It has been customized over ten or fifteen years to fit exactly how the business runs. Everybody complains about it and nobody wants to touch it, because the person who understood the customizations left in 2019 and the vendor stopped supporting the version you are on two releases ago. Every year the decision to migrate gets deferred, and every year the migration gets a little harder. I have sat on both sides of this: helping organizations decide whether to move, and then integrating and migrating the data when they do. This guide is the honest version of what that journey actually involves, with Microsoft Dynamics 365 Business Central as the destination.

The message up front: a legacy ERP migration is not a technology project, it is a business change project that happens to involve technology. The database, the data mapping and the go-live weekend are the parts everyone plans for. The customizations you cannot let go of, the integrations nobody documented, and the users who quietly refuse to change how they work are the parts that sink projects. Plan for those and the rest is manageable.

1. Why organizations move off legacy ERP now

Ask a vendor why you should migrate and you get a slide about digital transformation, agility and being future-ready. Those words describe nothing you can act on. The real drivers that push organizations off a legacy on-premise ERP are more concrete, and being clear about which one is actually forcing your hand shapes the entire project.

• End of support and end of life. This is the single most common trigger. The version you run drops out of mainstream support, security patches stop, and the vendor makes it clear the only supported path forward is the new platform. Dynamics NAV and Dynamics GP customers have both been on the receiving end of exactly this message. Running unsupported ERP is a risk that auditors, insurers and eventually regulators stop tolerating.
• The cost of customization has become the cost of ownership. A heavily modified legacy ERP is expensive to keep alive. Every upgrade is a bespoke project because the base code was altered. Every change needs a specialist who understands the modifications. The customizations that once made the system fit the business now make it impossible to move, and the maintenance bill only climbs.
• Talent scarcity. The pool of people who can work on aging platforms shrinks every year. When the developer who maintained your system retires or moves on, replacing them is slow and expensive, and each new hire needs months to understand a codebase nobody documented. You are maintaining a system on borrowed institutional memory.
• Integration friction. Modern business runs on connected systems: e-commerce, CRM, banking, tax authority portals, warehouse and field systems. A legacy ERP with no modern API surface turns every integration into a custom, brittle, file-based interface that breaks quietly and costs a fortune to maintain. The friction of connecting the old system to everything else becomes a daily tax.
• Compliance and regulatory change. Tax and reporting regimes evolve, and mandatory e-invoicing is the current example across the Gulf and beyond. A legacy platform that cannot be updated to meet a new statutory requirement forces a decision whether or not you were ready to make one. For how this plays out specifically, see the UAE e-invoicing integration guide.

Notice what is not on that list: cloud for its own sake, artificial intelligence, or wanting the newest thing. Those are outcomes, not drivers. The organizations that migrate well are the ones honest about which pressure is actually forcing the decision, because that pressure sets the timeline, the budget and the non-negotiables. An end-of-support deadline demands a different plan from a slow-burning maintenance-cost problem, and pretending otherwise leads to a project scoped for the wrong constraint.

2. On-premise versus cloud ERP: what actually changes

Before mapping the migration itself, it is worth being precise about what you are actually moving to, because "moving to the cloud" hides several distinct changes that land on different parts of the organization. Business Central is delivered primarily as a Microsoft-hosted software-as-a-service product, and that model changes five things in concrete ways.

• Infrastructure. The servers, the database, the operating system, the backups and the disaster-recovery site stop being your problem. On-premise, all of that is your team's responsibility and your capital budget. In the cloud model it is Microsoft's, folded into a per-user subscription. For many mid-sized organizations, retiring the server room and the associated hardware refresh cycle is a genuine and quantifiable saving on its own.
• Upgrades. This is the deepest change and the one people underestimate. On-premise ERP upgrades are projects, often multi-month, often skipped for years because they are so painful. In the cloud model Business Central updates continuously: minor updates monthly and two major releases a year, applied automatically. You do not choose whether to upgrade; you stay current by design. That removes the upgrade backlog forever, but it also removes the option to freeze the system, which is a real cultural shift for teams used to controlling every change.
• Total cost of ownership. The money moves from capital expenditure to operating expenditure. Instead of large periodic outlays on licenses, servers and upgrade projects, you pay a predictable per-user monthly subscription. Whether the total is higher or lower over a five-year window depends heavily on your user count and how much on-premise infrastructure you were carrying, but the shape of the spend changes from lumpy and unpredictable to smooth and forecastable.
• Control. You give up direct control of the database and the deep base code. You can no longer write a stored procedure against the SQL tables or modify the platform itself. In exchange you get a platform that is always current and always supported. For organizations that leaned on that low-level control, this is the hardest adjustment, and it is exactly where heavy legacy customization becomes the migration's central problem, covered further down.
• Security responsibility. Security becomes shared rather than yours alone. Microsoft secures the platform, the infrastructure and the data centre. You remain responsible for identity, access, permissions and how your people use the system. The perimeter you used to defend around your own servers is replaced by identity and access governance, which for most organizations is a net improvement but a different discipline.

The honest framing: cloud ERP is not automatically cheaper or better, it is a different operating model with a different set of trade-offs. You trade control and one-time capital cost for currency, predictability and offloaded infrastructure. For most organizations weighing the move off aging on-premise ERP that trade is favourable, but it is worth understanding it as a genuine trade rather than a pure upgrade. For a fuller treatment of what cloud ERP means in practice, see cloud ERP explained, and to test the fit for your own organization, is Business Central right for your organization.

3. The migration paths, honestly

There is no single "migration to Business Central." There are three fundamentally different routes, they cost different amounts, they carry different risks, and choosing the wrong one is the most expensive mistake in the whole exercise. Be clear-eyed about which one you are actually on.

Path one: upgrade in place. This applies only if you are already on a Microsoft predecessor product, principally Dynamics NAV. There is a defined technical path to bring NAV forward to Business Central, carrying your data and, with work, your customizations across. It is the least disruptive route because the underlying data model and business logic are related. It is not trivial, especially with heavy modifications, but it preserves the most and re-teaches the least. If you are on NAV, this is your natural starting assumption.

Path two: re-implementation on Business Central. You stand up a fresh Business Central and deliberately migrate your data, your configuration and your processes into it, redesigning where the old system had grown warped over the years. This is the route for organizations coming from a non-Microsoft ERP, from Dynamics GP (which has no in-place upgrade to Business Central), or from a NAV so heavily customized that dragging the modifications forward costs more than rebuilding cleanly. It is more work than an in-place upgrade but it produces a cleaner result, because you get to decide what to keep rather than inheriting everything by default.

Path three: a clean fresh start. You treat the migration as an opportunity to rethink how the business runs, adopt Business Central close to standard, and bring across only master data and open balances. History stays in the old system or an archive. This is the boldest route and, done with discipline, the one that delivers the most value, because it sheds a decade of accumulated workaround and complexity. It demands the most from change management, because people have to genuinely change how they work rather than recreating the old system in a new skin.

The decision test I use: how much of your legacy system's complexity is genuine business value, and how much is accumulated scar tissue? If most of the customization encodes real, differentiating process, lean toward upgrade or careful re-implementation that preserves it. If most of it is workaround for old constraints, decisions made by people long gone, and "we have always done it this way," lean toward the fresh start. The instinct to preserve everything because it feels safe is the instinct that carries a decade of mess into a brand new system.

4. From Dynamics NAV or GP to Business Central specifically

If you are already a Microsoft ERP customer, your situation is more specific and it is worth separating the two common cases clearly, because they are not the same journey.

Dynamics NAV to Business Central is the natural upgrade path, and Microsoft designed it that way. Business Central is the direct successor to NAV; under the surface they share heritage in the same data structures and the same business logic, which is why NAV customers get a real in-place upgrade route rather than a full rebuild. Your chart of accounts, your posting groups, your dimension setup, your item and customer and vendor records, the accumulated configuration of how your business posts and reports, much of this carries over with structured migration tooling. The financial and operational logic your people already know largely persists, which dramatically reduces retraining.

The catch, and it is a significant one, is code. NAV customizations were written in C/AL and often woven directly into the base application objects. Business Central does not allow that anymore. All customization now lives in extensions, isolated from the base code (covered in detail in the next section). So while your data and configuration upgrade relatively cleanly, your customizations do not come across as-is: they have to be re-expressed as extensions. The heavier your NAV modifications, the more this shifts a NAV upgrade from a data exercise toward a redevelopment exercise. A lightly modified NAV moves to Business Central comfortably. A NAV with hundreds of altered base objects is, honestly, closer to a re-implementation wearing an upgrade's clothing.

Dynamics GP to Business Central is a different story and it is important not to assume the NAV path applies. GP has a different architecture and lineage, and there is no in-place technical upgrade from GP to Business Central. Moving from GP is always a re-implementation: you set up Business Central fresh and migrate master data and balances into it, with tooling to help extract from GP but no automatic lift of the application itself. That is not a failing of the product; the two systems were simply never the same platform. The practical implication is that GP customers should scope a re-implementation from the start and not be surprised when an "upgrade" turns out to mean a rebuild. For the destination platform itself and how it sits in the wider Microsoft stack, see the introduction to Business Central and Business Central in the Microsoft ecosystem.

5. Data migration: what to bring, what to archive, what to leave behind

Data migration is where teams sink enormous effort into the wrong things. The instinct is to bring everything: every transaction back to the beginning of time, every closed record, every archived note. Resist it. A disciplined data migration sorts your legacy data into three buckets, and the discipline of that sorting is worth more than any tool.

• Master data: bring it, but clean it first. Customers, vendors, items, the chart of accounts, fixed assets, employees. This is the foundation of the new system and it has to come across. But a migration is the one moment you get to clean it. Duplicate customers, obsolete items nobody has sold in five years, vendors long inactive, an inflated chart of accounts full of accounts created for a single transaction in 2014. Migrating dirty master data means paying to carry mess into a clean system. Deduplicate, retire and rationalize before you load, not after.
• Open transactions: bring the live ones. Open receivables and payables, unposted orders, open work orders, current inventory quantities and values, outstanding balances. These are the operational state the business needs to keep running on day one, so they must migrate accurately and reconcile to the penny. This is the migration data that has to be right, because it is what the business trades on from go-live.
• Transaction history: mostly leave it, archive the rest. Years of posted, closed transactions rarely need to live inside the new ERP. Trying to migrate deep history is expensive, slows the new system, and forces you to reconcile detail nobody will ever query in the live application. The better pattern is to migrate a limited window (often opening balances plus the current and prior fiscal year for comparatives) and keep the deep history in an archive or a read-only copy of the old system for the rare audit or lookup. You almost never need ten years of line-level detail inside the operational ERP.

The clean-slate temptation, honestly: the argument to bring almost nothing and start pristine is seductive and often partly right, but it has a real cost that people gloss over. Reporting that compares this year to last year needs comparative data. Certain compliance and warranty and contract obligations reach back years. And users lose trust fast when they cannot find a customer's history in the new system. The right answer is rarely "bring everything" or "bring nothing." It is a deliberate window: enough history to run the business and satisfy compliance, archived access for the rest, and a clear communicated rule about where old detail now lives.

Whatever the scope, build reconciliation into the plan from the start. Every migrated balance must tie back to the source system, signed off by finance, before go-live. A migration that loads data nobody has reconciled is a migration that discovers its errors in the first month-end close, which is the worst possible time.

6. Customizations: from modified base code to the extensions model

If there is one thing that determines whether a legacy migration is smooth or brutal, it is customization. In older systems, including NAV, developers modified the base application code directly to fit the business. That worked, and it is exactly why upgrades were so painful: every change to the standard product collided with your modifications, and every upgrade became a bespoke reconciliation project. Business Central closes that door deliberately. Base code is sealed. All customization lives in extensions: separate packages, written in the AL language, that plug into defined events and interfaces without altering the standard application underneath.

This model is genuinely better for the long term. Because your extensions sit apart from the base, Microsoft can update the platform continuously without breaking your code, which is the whole reason the always-current cloud upgrade model can work at all. But the transition is the hard part, and it is worth stating plainly: heavy legacy customization is the single biggest risk in a Business Central migration. Every direct modification in the old system has to be re-examined and re-expressed, and each one falls into one of a few outcomes.

• Now standard. A surprising amount of old customization was built to fill gaps that the modern product now covers natively. Dimensions, workflow approvals, document management, reporting that used to need bespoke code. The best result for many modifications is deletion: you do not rebuild them, you adopt the standard capability and retire the custom one.
• Rebuild as an extension. Genuine, differentiating business logic that has no standard equivalent gets re-developed properly as an AL extension. This is real development work and it should be scoped as such, but the result is customization that will survive every future upgrade instead of blocking it.
• Replace with an ISV app. Some needs your old system solved with custom code are now met by proven apps from the AppSource marketplace: industry verticals, payment connectors, advanced warehouse or manufacturing add-ons. Buying a maintained app often beats rebuilding and maintaining bespoke code.
• Retire entirely. Some customizations exist because of a constraint that no longer applies, or a request from someone long gone, and nobody actually relies on them anymore. A migration is the honest moment to let them die.

The work that pays off most here is the customization audit done early: catalogue every modification in the legacy system, and for each one decide which of those four outcomes applies before a single line of AL is written. Organizations that skip this and simply ask "rebuild everything we had" carry their entire accumulated complexity into the new platform, pay for the privilege, and lose most of the benefit of moving. The migration is your one clean chance to shed weight. Take it.

7. Integrations and the surrounding system landscape

An ERP is never an island, and the systems around it are where migrations quietly overrun. Your legacy platform connects to things: a CRM, an e-commerce storefront, bank feeds, payroll, a warehouse or point-of-sale system, tax and government portals, business intelligence and reporting, maybe a maintenance or facilities system. Every one of those connections has to be rebuilt against the new platform, and the old interfaces almost never document themselves.

The good news is that this is precisely where the move pays off. Legacy integrations were typically file-based, scheduled, brittle and invisible when they failed. Business Central exposes a modern API surface and native connectors into the wider Microsoft stack, so interfaces that used to be overnight file drops can become real-time, monitored, resilient connections. The connected estate you rebuild is genuinely better than the one you leave behind, which softens the pain of rebuilding it.

The discipline that keeps this from becoming a runaway is mapping the full integration landscape before the migration, not during it. Every inbound and outbound interface, what it moves, how often, what depends on it, and who owns the system on the other end. The interfaces that surprise projects are the undocumented ones: a spreadsheet macro someone built that pulls from the ERP database directly, a nightly export that feeds a report a director relies on, a connection to a partner system nobody remembered until it broke. Discovering those during go-live weekend is how a controlled cutover turns into a crisis. Discovering them during planning is just a task on a list. For a worked example of connecting Business Central to an operational system, see the CAFM and Business Central integration guide.

8. The cutover decision: big bang versus phased

At some point the new system has to become the live system, and how you make that switch is one of the most consequential decisions in the project. There are two broad approaches and a hybrid, and the right choice depends on your risk tolerance, your complexity, and how much you can afford to have go wrong at once.

Big bang. On a chosen date, the old system stops and the new one starts, everything at once, all modules, all users, all sites. It is clean, it is decisive, and there is no protracted period of running two systems in parallel. It is also the highest-risk moment in the entire project, because everything depends on that weekend going right. Big bang suits smaller and mid-sized organizations with contained complexity, where the whole business can be switched and supported over a single controlled window. When it works it is the fastest way to get the migration behind you.

Phased. You bring the new system live in stages, by module, by company, by site or by function, over weeks or months. It lowers the risk at any single moment because you are only ever cutting over a slice, and problems are contained to that slice. The price is complexity: during the phased period you are running old and new together, which means temporary bridges between the two, reconciliation across both, and a longer stretch of elevated effort. Phased suits larger, multi-entity or multi-site organizations where a single big-bang switch would concentrate too much risk into one weekend.

Parallel running is the option people ask for and rarely execute well. The idea is to run both systems fully in parallel for a period, processing everything twice, to prove the new system matches the old before committing. In theory it is the safest validation. In practice it doubles the workload on a team already stretched by the migration, and that double-entry burden means it is often done half-heartedly, which proves nothing. If you use parallel running, keep it short, scope it to the critical processes you genuinely need to validate (usually the financial close), and resource it honestly. A parallel run nobody has time to actually perform is false comfort.

A caution on the go-live date: teams love to go live at the start of a fiscal year for clean reporting, which is sound, but that instinct crams every organization's migration into the same few weeks and concentrates risk against a deadline that cannot move. A hard, immovable go-live date is where corners get cut: testing gets compressed, data cleansing gets skipped, training gets shortened. Choose the date for the right reasons, then protect the quality gates in front of it fiercely, and be genuinely willing to slip the date rather than go live on unreconciled data. A migration delayed is recoverable. A migration that goes live broken can take a year to recover from.

9. Change management and user adoption

Here is the uncomfortable truth that no amount of clean data migration or elegant extension development changes: the part that actually sinks ERP migrations is people. The system can be configured perfectly, the data can reconcile to the penny, the integrations can all work, and the project can still fail because the people who have to use it every day resist, work around it, or quietly keep running the shadow spreadsheets they trust more than the new platform.

Legacy migrations are especially exposed to this because the users have often done their jobs the same way for a decade or more. The old system's quirks are muscle memory. When the new system does the same task differently, even when it does it better, that is experienced as loss, and loss breeds resistance. Underestimating this is the most common reason technically successful migrations deliver disappointing results.

• Involve the real users early. The people who actually run the processes need to be in the design and testing, not handed a finished system at go-live. They know the edge cases the project team will miss, and being involved converts them from resisters into advocates.
• Train on the new way, not the old way translated. Training that says "here is where the button you used to press now lives" reinforces the old mental model. Training that teaches the new process on its own terms lands better and lasts longer. Where a process genuinely changes, explain why, because people accept change they understand.
• Name and support the transition. Productivity dips right after go-live, always. Pretending it will not, or punishing the dip, drives people back to their workarounds. Plan for a support-heavy stabilization period with visible help close at hand, and treat the dip as expected rather than as failure.
• Give the change credible sponsorship. When leadership treats the migration as an IT project happening in the background, users read that as permission not to take it seriously. When leadership is visibly committed and uses the new system itself, adoption follows. The tone is set from the top whether or not anyone intends it to be.

None of this is technical, which is exactly why technically-minded projects neglect it. The budget line for change management and training is the first thing cut when the project runs tight, and it is almost always the wrong cut. A perfectly built system that people refuse to adopt has delivered nothing. Protect that budget as fiercely as you protect the data quality.

10. Cost, timeline and risk: setting realistic expectations

The fastest way to fail a migration is to start it with wrong expectations, so it is worth being blunt about cost, timeline and risk, even though the honest answer is always "it depends."

Cost is never just the software subscription. The subscription is often the smallest line in the total. The larger costs are the implementation partner, the data migration effort, the extension development, the integration rebuilds, the training, and the internal time of your own people, whose hours are real even when they do not appear on an invoice. The single biggest cost driver, by a wide margin, is customization and integration complexity. A near-standard implementation with clean data is a fraction of the cost of a heavily-customized, deeply-integrated migration, and the difference is measured in multiples, not percentages.

Timeline follows the same logic. A small organization moving to close-to-standard Business Central with modest data can be live in a few months. A complex, multi-entity organization with heavy customization, many integrations and years of data to rationalize is a program of a year or more. The dangerous position is the organization that assumes the second situation can be done on the first situation's timeline. Scope drives duration, and honest scoping up front prevents the slow, morale-draining overrun that comes from a timeline set by hope rather than by the actual work.

Where the risk actually concentrates: after enough of these, the pattern is consistent. Risk lives in customization (the biggest single factor), in data quality (garbage migrated is garbage amplified), in undocumented integrations (the ones you find during cutover), and in user adoption (the one that fails silently after go-live). Notice that none of the top risks is the core ERP technology itself. Business Central works. Projects rarely fail because the product could not do the job. They fail because the surrounding complexity was underestimated, and that complexity is knowable in advance if you look for it honestly.

The way to manage all of this is to reduce scope wherever you legitimately can. Every customization you retire instead of rebuild, every integration you simplify, every year of history you archive instead of migrate, every process you bring closer to standard, lowers cost, shortens timeline and removes risk simultaneously. The most successful migrations I have been near were not the most ambitious. They were the most disciplined about doing less, and doing it well. For the shape of the implementation itself once you commit, see the Business Central implementation journey, and for where the platform is heading so you invest against the right roadmap, the Business Central roadmap.

Final thoughts

Migrating off an aging on-premise ERP is one of the harder things an organization does, and anyone who tells you otherwise is selling something. But it is hard in knowable ways, and almost all of the pain lives in four places: the customizations you cannot bear to let go of, the data you insist on carrying wholesale, the integrations nobody documented, and the people who have to change how they work. Get honest about those four early and the project becomes manageable. Ignore them and no amount of good technology saves you.

If you are a NAV customer, the upgrade path to Business Central is real and it preserves most of what you know, with code being the part that has to change. If you are a GP customer or coming from a non-Microsoft system, plan for a re-implementation and stop calling it an upgrade. Either way, treat the migration as the rare chance it is to shed a decade of accumulated complexity rather than faithfully rebuild it in a new system. The organizations that come out ahead are not the ones that migrated the most. They are the ones that had the discipline to bring across only what still earned its place, and the courage to leave the rest behind.

Related reading: Introduction to Dynamics 365 Business Central, Cloud ERP explained, Is Business Central right for your organization, The Business Central implementation journey, CAFM and Business Central integration guide.