ERP Migration Strategy: Lift and Shift, Replatform or Replace?

Most ERP migrations are decided in the wrong order. The budget gets argued first, the vendor gets chosen second, and the question that shapes both, how much of the current system you are actually taking with you, gets answered by default somewhere in month three. An ERP migration strategy is that question answered on purpose, before anyone signs anything.

There are three routes to the cloud: lift and shift, replatform, or replace. Each carries a different mix of cost, risk and disruption, and each leaves you with a different system at the end. This guide sets out what each route really involves, the vendor deadlines pushing the decision in 2026, and the questions that point to the right route for your business.

The short answer

Lift and shift moves your existing ERP onto cloud servers unchanged. It is the fastest and cheapest route, and it keeps every customization and every problem you have today. Replatforming moves you to the same vendor’s next-generation or cloud edition while keeping your data and most of your processes, so it sits in the middle on cost and risk. Replacing means a new ERP, or a clean implementation of the current one, with processes redesigned and only the data you choose carried across. It costs the most up front and changes the most, and it is the only route that clears out years of accumulated workarounds.

None of the three is right by default. The right route depends on how long your current ERP will be supported, how much of your customization still earns its keep, and whether your processes are something you want to preserve or something you have been putting up with.

The three routes, explained

Lift and shift (rehost)

The ERP stays exactly as it is, same software, same version, same custom code, and moves from your own servers onto cloud infrastructure such as AWS or Azure. AWS describes rehosting as moving applications to the cloud “without making any changes to the application” (AWS Prescriptive Guidance).

What you gain is speed and an end to hardware: no server refresh, no data center lease, and disaster recovery that is easier to arrange. What you do not gain is anything new. The users see the same screens, the reports run the same way, and the vendor’s support dates do not move an inch. If your ERP version reaches end of support in 2029, it reaches it in the cloud too. Check one more thing before choosing this route: whether your current licenses allow the software to run on a public cloud at all. Some older on-premise licenses do not.

Replatform (upgrade and move)

You stay with the same vendor but move to its current generation, usually a cloud or vendor-hosted edition, and bring your data, configuration and much of your custom code with you. The best-known example is an SAP ECC to S/4HANA system conversion, which SAP customers call a brownfield migration. AWS defines replatforming as moving to the cloud while introducing “some level of optimization” along the way.

This route resolves the support deadline without restarting the business from a blank page. The catch is that custom code written for the old platform does not always survive the move, so part of the budget goes on finding, fixing or retiring it. The older and more customized the system, the larger that part becomes.

Replace (reimplement)

You implement a new ERP, or a fresh implementation of your current vendor’s product, and design the processes again. Moving from Dynamics GP to Dynamics 365 Business Central or NetSuite is a replacement. So is an S/4HANA greenfield project, where the company starts from SAP’s standard processes rather than converting its old system.

Replacement migrates far less than people expect. Microsoft’s own GP to Business Central migration tool is a good illustration: it moves master data such as customers, vendors and items, plus open transactions, and receivables and payables arrive as outstanding balances rather than original amounts, so a partly paid invoice lands in the new system as the amount still owed. Older detail can travel separately as a historical snapshot for reporting (Microsoft Learn). That is the point of replacement: you choose what comes with you, and everything else is left behind on purpose.

A fourth, hybrid route is worth knowing about if you run SAP. Selective data transition, sometimes called bluefield, takes chosen parts of the old system, such as certain company codes or a run of history, into a new S/4HANA system and redesigns the rest. It suits large estates where some areas deserve preserving and others do not.

Lift and shift vs replatform vs replace, side by side

	Lift and shift	Replatform	Replace
What moves	The same ERP and version, onto cloud servers	Your data, configuration and most custom code, onto the vendor’s current edition	Master data, open balances and the history you choose, into a new system
Typical example	An on-premise ERP moved onto AWS or Azure infrastructure	SAP ECC to S/4HANA system conversion	Dynamics GP to Business Central or NetSuite; S/4HANA greenfield
Upfront cost	Lowest	Middle	Highest
Disruption to users	Low	Medium	High
Customizations	All kept, including the ones nobody uses	Most kept; incompatible code must be fixed or retired	Only what you choose to rebuild
Solves an end-of-support deadline?	No	Yes	Yes
Best when	Hardware or data center pressure, and the ERP is supported for years yet	Processes are sound and the vendor has a clear upgrade path	Processes have drifted, workarounds have piled up, or the product is being retired

The deadlines forcing the decision

For many companies, the timing is not their own. Three widely used ERP products have published support dates that now sit inside a normal planning horizon.

Product	Key dates
SAP ECC 6.0 (enhancement packages 6 to 8)	Mainstream maintenance ends December 31, 2027. Extended maintenance runs to December 31, 2030, at a premium of two percentage points on the maintenance rate. A transition option inside RISE with SAP covers 2031 to 2033 for large customers who move to private edition first.
Microsoft Dynamics GP	Product support and updates end December 31, 2029. Security patches end April 30, 2031.
Oracle E-Business Suite 12.2	Premier Support extended through at least 2036.

A deadline is a reason to decide, not a reason to panic. The software keeps running after support ends; what changes is what the vendor will fix. After SAP’s mainstream maintenance, customers without extended maintenance move to customer-specific maintenance, which covers fixes for known problems but no new legal or tax updates. For a finance system, those tax updates are the part that matters.

Gartner has been notably calm about this. In early 2025 it estimated that more than 60 percent of SAP customers remained on ECC on-premises with no decision yet to move, and that four in ten of today’s ECC customers will still use it in key business areas in 2030. Its advice to customers who struggle to put a number on the value of S/4HANA was to consider whether staying on ECC for the near term is viable (The Register, February 2025). Waiting is a legitimate strategy, provided it is a decision and not a drift.

How to choose: five questions

1. How long will your current version be supported? If support runs well past your planning horizon, lift and shift is a reasonable way to get off aging hardware now and leave the bigger decision for later. If support ends within three or four years, lift and shift only moves the problem to a more expensive address.
2. How many of your customizations are still used? Count them, then count the ones people actually rely on. A long list of rarely used custom reports and modifications is the strongest single argument for replacement, because every one you carry forward has to be tested, fixed and maintained again.
3. Are your processes an advantage or a habit? Some companies run a way of pricing, scheduling or fulfilling orders that genuinely sets them apart, and they should protect it. Others have processes shaped by the limits of a system bought fifteen years ago. The first group leans toward replatforming; the second gains most from starting again.
4. What condition is your data in? Duplicated customers, retired items that were never closed, and years of history nobody reports on all cost more to move than to leave behind. Poor data favors replacement, where only clean master data and open balances need to travel.
5. How much change can the business absorb this year? Replacement asks finance, operations and sales to learn new ways of working at the same time. If the company is mid-acquisition or short of key people, a smaller step now may beat a bigger one that stalls.

The two-step route, and when it makes sense

Some companies lift and shift first and transform later. It is a sound plan when the pressure is physical, a server contract ending or a data center closing, and the ERP itself still has years of support ahead. It is a poor plan when it is a way of postponing a decision the business already knows it must make, because the company pays for two migrations instead of one, and the second still has to happen on the vendor’s timetable.

AWS’s own guidance for large migrations points the same way: rehosting, relocating, replatforming and retiring are the common strategies, while full refactoring is generally not recommended at scale. Move what must move, retire what nobody uses, and keep the deep redesign for the parts of the business where it pays.

The mistakes that sink each route

The failure rate for ERP programs is high enough to take seriously. Gartner told its Symposium audience in November 2025 that 70 percent of ERP initiatives fail to fully meet their original business case goals and 25 percent fail catastrophically. Among the causes it listed were unrealistic scope, underestimated complexity, limited change management, and customization too closely tied to existing processes (The Register, November 2025). Each route has its own way of walking into those traps.

• Lift and shift treated as the destination. The system moves, the bills change, and nothing else does. Without a plan for what comes next, the company has paid to relocate its technical debt.
• Replatforming without a custom code audit. The scope looks contained until testing finds the custom programs that no longer work. Audit and retire before you convert, not during.
• Replacing the system but rebuilding the old processes. This is the most expensive mistake of all: the cost of a new ERP with the habits of the old one. If the team insists every report and screen must look as it did, the project has quietly become a replatform at replacement prices.
• Migrating all the history. Ten years of closed transactions rarely need to live in the new system. Archive them where they can be reported on and move balances instead.

Whichever route you choose, the run cost after go-live deserves the same scrutiny as the migration itself. Oversized environments set up “just in case” during a migration are one of the main sources of the cloud budget waste companies report, and our cloud migration cost benchmarks show how quickly that adds up.

Frequently asked questions

What is the difference between lift and shift and replatforming an ERP?

Lift and shift moves the same ERP software and version onto cloud servers without changing it. Replatforming moves you to the vendor’s current or cloud edition, such as SAP S/4HANA from ECC, carrying your data and much of your configuration across. Lift and shift changes where the system runs; replatforming changes the system itself.

Is lift and shift a bad idea for ERP?

Not always. It is a good fit when the ERP has years of vendor support left and the pressure to move is about hardware or a data center. It is a poor fit when support ends soon, because the deadline follows the software into the cloud.

Do we have to leave SAP ECC by 2027?

No. Mainstream maintenance for ECC 6.0 enhancement packages 6 to 8 ends on December 31, 2027, but extended maintenance is available to December 31, 2030, at a higher rate, and the software keeps running after that. What you lose without maintenance is new legal and tax updates, which is why most finance teams plan to move before support runs out rather than after.

How much historical data should we migrate to a new ERP?

Usually much less than you think. Most replacements move master data, open transactions and summary balances, and keep detailed history in an archive or reporting store. Microsoft’s GP to Business Central tool, for example, migrates outstanding balances and offers older detail as an optional historical snapshot.

Which ERP migration approach is cheapest?

Lift and shift has the lowest upfront cost and replacement the highest. Over five years the order can reverse: a lifted system still carries its maintenance burden, its customizations and its support deadline, while a well-run replacement removes them. Compare the routes on total cost over the life of the system, not on the first invoice.

Choosing the route before the budget

The companies that come out of an ERP migration well rarely had the biggest budget. They decided early what they were taking with them and what they were leaving behind, and they made that call with the support dates, the customization list and the state of their data in front of them.

That assessment takes a few weeks, and it changes every number that follows. Our cloud solutions team reviews your current ERP estate, shows which route fits each part of it, and costs the plan before you commit. Talk to our team to start.