Speed only helps when you’re headed in the right direction.
That’s the fundamental problem with lift and shift ERP migration. Moving an existing system quickly may sound efficient, especially when the alternative involves examining years of processes, data, integrations, and customizations. But getting to the cloud faster doesn’t necessarily mean the business is moving forward.
I’ve seen companies spend years working around limitations in legacy ERP systems. Processes become more complicated than they need to be.
Data gets messy.
Customizations accumulate.
Employees develop workarounds that eventually become accepted as “the way we do things.”
Moving all of that to the cloud doesn’t make it disappear.
A move to Dynamics 365 Business Central should be an opportunity to improve how the business operates, not simply relocate the technology supporting it.
If the migration preserves the problems you were trying to leave behind, you may indeed get to the cloud faster... but without taking the business very far at all.
This is the second article in my three-part series on making smarter cloud ERP migration decisions. In the first, we looked at why a successful migration requires business leadership, not just technical execution.
Here, I want to focus on one of the shortcuts that can undermine that effort: lift and shift. Then, in the final article, I’ll look more closely at what businesses should clean up before moving ERP to the cloud, from data and processes to the complexities that have accumulated over time.
Because before you decide how quickly to move, it’s worth deciding what should—and shouldn’t—come with you.
Lift and shift ERP migration means moving an existing ERP environment to the cloud with minimal changes to the applications, processes, or underlying design. The primary goal is usually straightforward: move faster and reduce the amount of change required during the migration.
It's easy to understand why that might sound appealing.
ERP projects require time, money, and attention from people who already have full-time roles. If a company can move its existing environment without redesigning processes, cleaning years of data, or reconsidering every customization, the project can appear smaller, faster, and less expensive.
There’s also a reasonable desire to minimize disruption. Employees know the existing processes. Finance knows how reports are produced. Operations knows where the workarounds are. Even the awkward parts of an ERP can become strangely comfortable after enough years.
From an executive perspective, the logic can seem pretty compelling: Keep what works, move it to the cloud, and improve things later.
The problem is that “later” has a habit of becoming a very long time. Especially when it comes with its own budget request.
Once the migration is complete, the immediate pressure is gone. Employees return to their normal responsibilities, other priorities take over, and the process improvements that had been planned for phase two can quietly slide down the list.
That’s why I look at lift and shift ERP migration as more than a question of migration speed or upfront cost. The real question is what the business is choosing to preserve in exchange for that speed.
If you’re preserving sound processes, clean data, useful integrations, and a well-governed ERP environment, that may be a reasonable tradeoff.
If you’re preserving years of inefficiency and complexity, you’re making a very different financial decision.
Lift and shift often fails because it relocates existing problems rather than solving them. Inefficient processes, inconsistent data, outdated customizations, and ERP technical debt don’t disappear when the system moves to the cloud. They simply continue operating in a newer environment.
That distinction matters.
When I evaluate an ERP environment, I’m not only looking at whether the system works. Most legacy ERP systems work, at least in the sense that orders get processed, invoices go out, and financial statements eventually get produced.
I’m also looking at how much effort it takes to make all of that happen.
How many manual steps have accumulated around a process? How many reconciliations are required to make the numbers agree? Which customizations still solve a real business problem, and which ones exist because of a decision made ten years ago that nobody remembers making?
Those are operating costs, even when they don’t appear as a neat line item on the income statement.
Technical debt works much the same way. Accenture describes technical debt broadly, extending beyond aging software to include architecture, data, infrastructure, and manual processes. That’s a critical distinction in an ERP environment because those elements are interconnected. Carrying them forward without evaluating them can preserve the very complexity the migration was supposed to reduce.
Data is another good example. In the first article in this series, I talked about why poor data doesn’t improve simply because it moves into a new system. The same principle applies here. A lift and shift migration can move duplicate records, inconsistent naming conventions, obsolete information, and years of accumulated exceptions just as efficiently as it moves good data.
That’s why I don’t view ERP modernization as a change of location.
The cloud can provide a stronger platform, but it can’t decide which processes still make sense, which data should be trusted, or which complexity the business no longer needs. Those decisions have to happen before, or as part of, the migration.
Otherwise, you haven’t eliminated the technical debt. You’ve just changed its address.
The problems with lift and shift often become most visible after the migration. I’ve seen projects that were technically successful (the system is live, transactions are processing, and everyone made it through go-live), but the business isn’t necessarily operating any better.
Performance is one place the cracks can start to show. Processes designed around an older ERP environment may not translate cleanly to a modern cloud platform, while outdated customizations can introduce unnecessary complexity.
Integrations can create another layer of risk. Over time, companies connect ERP systems to applications supporting everything from shipping and warehousing to reporting and payroll. Some of those connections are essential. Others may have been built around requirements that have since changed. Moving them without reassessing their purpose and design can usher old dependencies directly into the new environment.
Then there’s user experience.
If employees still have to work around the system, enter information more than once, wait for someone to resolve an exception, or follow a process everyone already knows is inefficient, they aren’t going to experience the migration as an improvement. (And if “then email Bob” is still an official step in the process, we probably haven’t transformed as much as we think.)
That frustration has a cost. Workarounds make processes harder to control. Exceptions increase dependence on institutional knowledge. And when employees don’t trust the system to make their jobs easier, adoption suffers.
That’s why I don’t measure a successful cloud ERP migration simply by whether the new system went live.
I want to know what became easier, faster, more reliable, and more predictable for the business afterward.
Instead of simply moving the existing ERP environment, I encourage businesses to use the migration as an opportunity to improve it. That means reviewing processes, cleaning data, reducing unnecessary complexity, and deciding how the new environment will be governed.
That doesn’t mean redesigning every process just for the sake of change. The goal isn’t to throw away everything the business has built over the years. It’s to be deliberate about what deserves to come forward.
I usually start with the processes that create the most friction:
Then I look at the data supporting those processes. Microsoft’s own Business Central cloud migration guidance includes reviewing data quality as part of migration preparation and recommends making sure data is clean and accurate before it moves.
That’s a good technical practice, but I see it as a business issue too. Decisions, reporting, forecasting, and automation are only as dependable as the information underneath them.
The same discipline should apply to customizations and integrations. I want to know what business requirement each one serves today, not simply why it was created years ago. If there’s no longer a clear answer, that’s a good reason to question whether it belongs in the new environment.
Finally, governance needs to be part of the ERP migration strategy from the beginning:
Those questions may slow the conversation down a little.
And that’s okay.
I’d rather spend time making those decisions before migration than spend considerably more time—and money—untangling them afterward.
Lift and shift can reduce the cost and effort required to get an ERP system into the cloud. But if the migration leaves inefficiencies, technical debt, and unnecessary complexity in place, the business may continue paying for them long after the migration project is closed.
As a CFO, this is where I think the economics of lift and shift deserve more scrutiny.
The migration budget is easy to see. It has a timeline, a project team, consulting costs, and a number everyone can put into a spreadsheet. The costs that come afterward are harder to isolate:
Individually, those costs may not look like much. But across hundreds or thousands of transactions—and several years? They stop being insignificant.
Then there’s opportunity cost.
Every hour and dollar spent supporting unnecessary workarounds and avoidable complexity can't be invested in improving the business. And when technical debt makes the ERP harder to change, even good ideas can become more expensive or take longer to implement.
That’s why the lowest upfront migration cost isn’t necessarily the lowest total cost of ownership.
I’ve made enough financial and technology decisions over the years to know that speed has value. Sometimes moving quickly is absolutely the right business decision.
But speed without improvement is NOT progress. It’s risk acceleration.
The CFO question shouldn’t simply be, “How much will it cost us to migrate?”
It should also be, “What will it cost us to keep operating this way after we do?”
Yes. Lift and shift can be a reasonable ERP strategy when the environment you’re moving is already worth preserving. If the processes work well, the data is reliable, and the existing design supports the way the business needs to operate, there may be little value in changing things simply for the sake of change.
That’s why my rule is simple: Fix before moving.
Before deciding what should come forward, I recommend asking three questions:
If the answer is yes, move it. If the answer is no, I’d rather address the problem during the migration than knowingly carry it into the new environment.
The goal isn’t to make an ERP migration bigger or more complicated than it needs to be. It’s to make sure that when the business gets to the cloud, it hasn’t simply brought along the reasons it wanted to modernize in the first place.
There’s nothing wrong with wanting an ERP migration to move quickly. Time matters. Cost matters. Disruption matters.
But speed only creates value if the business is better positioned when it gets there.
The better approach is to use the opportunity to make deliberate decisions about what’s worth preserving, what needs improvement, and what the business no longer needs.
Stay tuned for the final article in this series, where I’ll take that idea one step further and look specifically at what to clean up before moving ERP to the cloud, including the data, processes, customizations, and other complexity that can quietly accumulate over the years.
If you’re considering a move to Dynamics 365 Business Central and want to talk through what should come with you—and what probably shouldn’t—let's talk.