Discover how to overcome legacy ERP migration challenges and ensure a smooth transition without disrupting business operations. Expert tips for success.
The reason businesses defer replacing a system they know is failing them is rarely cost. It is the fear of disruption. Nobody wants to be the person who broke invoicing, stopped the warehouse or missed a payroll, and the memory of a migration that went badly persists for years.
That caution is reasonable. It is also frequently overcorrected into indefinite deferral, which has its own cost and one that compounds. The businesses that migrate successfully are not braver. They structure the project so that the disruption is bounded, planned and recoverable.
This article covers how to do that.
Being specific about the sources helps, because they are not all equally likely and they have different mitigations.
The most common is that the new system does not fit how the business actually works, which surfaces during testing or after go live. That traces back to inadequate discovery rather than to anything technical.
The second is data that did not migrate correctly, meaning balances that do not tie, records that are missing, or relationships that broke. This is the one people fear most and it is largely preventable through trial loads and reconciliation.
The third is people who cannot use the system, which produces a productivity collapse that looks like a technical failure and is a training failure.
The fourth is an integration that stopped working, which is frequently invisible for a while and then produces a backlog.
And the fifth is simply capacity, where the business absorbed a change at a moment it had nothing spare and everything else suffered.
The most effective structural decision is to reduce how much changes at once.
Phasing by function means financials go live first, then operational modules, then the more specialised pieces. Each cutover is smaller, the organisation learns the platform on the least risky part, and problems found in phase one inform phase two.
Phasing by entity or site means one part of the business goes first and becomes the template. Configuration is tested against real operations before being applied more widely, and the team running it becomes considerably more capable before the harder entities arrive.
Both have a cost, which is longer total elapsed time and a period running two systems in parallel. That parallel period is the part businesses consistently underestimate, since it means duplicate entry in some areas and reconciliation between the two.
The trade is generally worth it where the scope is broad or the organisation's capacity to absorb change is limited. Our piece on comparing implementation approaches covers that choice properly.
An obvious point that is regularly ignored under commercial pressure.
Every business has a rhythm, and going live during the peak means the system is unfamiliar precisely when there is least capacity to absorb unfamiliarity. Retailers should not cut over in November. Accounting practices should not cut over during tax season.
The financial year boundary is the cleanest point for a financials cutover, because it avoids splitting a year across two systems. It is also the most contested window, which means booking it early.
Payroll carries its own constraint, since the end of the payroll year removes the year to date migration almost entirely.
Where those conflict, phasing payroll separately from the wider programme is usually better than compromising either.
Data problems cause the most visible disruption and they are the most preventable, because they can be found before anything depends on them.
Start migration early, in parallel with discovery rather than after build. The first trial load always reveals something, and finding it in week six leaves room to respond.
Plan for several trial loads rather than one. The first establishes whether the extract and mapping work at all. The second tests the corrections and usually surfaces a second layer. The third should be close to production quality.
Cleanse before migrating rather than after. Data that arrives dirty is harder to fix in the new system than in the old one, and users encountering a new system full of familiar rubbish conclude the project did not deliver.
And bring less than instinct suggests. Open balances plus a limited period of history covers most genuine needs, with the old system retained in read only form for lookups.
The step that converts a load from completed to trusted, and the one most often treated as a formality.
The partner can confirm records arrived and no errors were returned. Only your business can confirm the data is correct, because correctness requires knowing what the answer should be.
Practically, somebody from finance reconciles the balances, somebody from sales checks a sample of customers, somebody from operations checks items and stock. Against the source, in total for balances and record by record for a sample.
Opening balances deserve particular attention, since the trial balance, receivables and payables by document, inventory quantity and value, and the fixed asset register are what your first management accounts and first audit rest on.
Assign these by name in the plan and book the time, because reconciliation expected to happen in gaps does not happen thoroughly.
User acceptance testing fails in a predictable way, and preventing that failure is most of what prevents post go live disruption.
The failure is that people are asked to test, given no time, click through a few screens, report that it seems fine, and the real problems surface afterwards.
What works is specific scenarios rather than exploration. Take an actual complicated order, an actual awkward purchase, an actual month end, and run each end to end.
The interesting failures are at the joins between processes rather than within them, which is why end to end scenarios find things that step by step testing does not.
And book the time formally, because testing squeezed around a full workload finds the obvious faults and misses the ones that matter.
A productivity dip after go live is normal and its depth is largely determined by training.
Train by role rather than generically, close to go live rather than weeks ahead, on your configured system with your own data rather than a demonstration account, and hands on rather than by demonstration.
Several short sessions beat one long one, since attention degrades and the time between sessions lets people try things and return with questions.
Identify a few people per team who learn early and become the person others ask. Most post go live questions are small, and a colleague answers them faster than any support process.
And prepare documentation for your configuration rather than relying on generic help, because generic help does not describe your forms, your fields or your approval rules.
The switch itself should be documented rather than improvised, because nothing is improvised well at two in the morning.
Every task, its owner, its expected duration, its dependencies and its start time. Final data loads, opening balances, reconciliation, system switching and verification.
Defined go or no go criteria, agreed in advance in writing, so the decision is made against a standard rather than against how tired everyone is.
A rollback position, documented even though it will probably not be used, because the value is in having thought it through and in the confidence that provides.
And people genuinely available rather than nominally contactable, since cutover weekends run long and the person you need is always the one who went away.
Parallel running means operating both systems for a period and comparing, and it is the strongest available control against a bad cutover.
It is genuinely expensive, since it means duplicate work for the period, and it is not justified everywhere.
Where it is clearly justified is payroll, because the consequence of a wrong pay run is immediate and personal, and because a payroll has enough interacting rules that configuration differences are likely. One or two complete cycles compared line by line is the standard.
Where it is usually not justified is the full operational scope, because running two order to cash processes in parallel is close to impossible operationally.
The sensible position is parallel running for the areas where the consequence of error is highest and the comparison is practical, and thorough testing elsewhere.
The period immediately after go live is where disruption is either contained or amplified, and it is frequently under resourced because the project budget has been spent.
Support needs to be immediate and visible. The gap between somebody hitting a problem and getting help determines whether they persist with the system or invent a workaround, and workarounds invented now become permanent.
Over resource it deliberately for a fortnight. Support that is slightly excessive for two weeks costs far less than the workarounds that grow in its absence.
Expect the productivity dip and plan around it rather than being surprised. Where the business has committed to normal output during the first fortnight, the pressure produces exactly the shortcuts you are trying to avoid.
And fix the small annoyances fast, because they carry disproportionate weight in how people judge the system.
Not all post migration problems announce themselves, and the quiet ones do the most damage.
Integrations that stopped working are frequently invisible for a while, because nothing errors visibly and the backlog builds. Checking them explicitly in the first weeks is worth the effort.
Scheduled processes that are not running produce the same pattern. A failing job is silent, so nobody reports it.
And silent abandonment, where people stop using part of the system because they found a workaround, is invisible unless you look. People do not report that they solved a problem their own way.
Going and watching how work actually gets done, in the first weeks, finds more than any status report.
A substantial proportion of what gets experienced as disruption is actually surprise, and surprise is preventable.
Tell people what is changing for them specifically, well before it does. Not the project status, but what their Tuesday will look like afterwards.
Be honest about what will be harder as well as what will be better, because every change has both and acknowledging the cost buys credibility.
Tell customers and suppliers where the change affects them. An invoice that looks different, a portal that moves, a payment reference that changes. A short note prevents a wave of queries.
And keep updating during the first weeks, since silence during a difficult period is read as things going badly.
A simple decision that removes a category of anxiety.
Retaining the old system in read only form for a defined period supports lookups, satisfies retention obligations and provides a reference if a discrepancy is found later.
It has costs, including licensing, infrastructure and the fact that somebody has to be able to use it, and those are usually small relative to the reassurance.
It also means you can migrate less history, since anything older than the migration window remains available where it always was.
The one discipline required is that it must be genuinely read only, because a business that keeps transacting in the old system has not migrated.
Migration disruption is manageable rather than inevitable, and the controls that manage it are consistent. Phase to bound the change, time it against your own calendar, start data work early and reconcile properly, test with real scenarios, train close to go live, plan the cutover in detail, and resource the first fortnight generously.
The businesses that find migration difficult are almost always the ones that compressed one of those, and the compression usually happened because a date was fixed before the plan was.
Our guide to the implementation journey covers each phase from the client's side, and planning the data migration covers the workstream that causes the most disruption.
Our approach to NetSuite implementation sets out how we structure projects to keep the change bounded.
If you are deferring a migration because of the disruption risk, get in touch and we can talk through how it would actually be structured.
