ERP Migration Without Stopping the Business

An ERP migration for an SME usually gets framed as a selection problem. Which system, which implementation partner, which modules. Companies spend months on that decision and comparatively little on the question that actually determines the outcome: how do you move from the old system to the new one while continuing to invoice, ship and pay people.

Most ERP migration projects that go badly do not go badly because the wrong product was chosen. They go badly at cutover, and the damage is operational rather than technical. Orders that cannot be fulfilled for a week are a business problem, not an IT problem, and by the time it is visible the money is spent.

The decision that shapes everything else: big bang or phased

Big bang means the old system stops on Friday and the new one starts on Monday. It is faster, cheaper in direct cost, and conceptually simpler. It also concentrates every risk into a single weekend, and the fallback if things go wrong is usually "work harder".

Phased means running the two systems alongside each other, moving one function or one site at a time. It takes longer, costs more, and requires you to keep data synchronised between two systems during the overlap, which is genuinely difficult and is where most of the added cost sits.

The honest rule: big bang is defensible when you can afford to be degraded for a few days and you have a rehearsed rollback. If a week of disrupted order processing would threaten the business, buy the phased approach and treat the extra cost as insurance, not waste.

What makes the decision hard is that the phased approach is the one your implementation partner is least keen to quote, because the dual-running period is where their effort is hardest to estimate. Ask about it explicitly, using the kind of question set in eight questions to ask a software vendor.

Your data is worse than you think

The single most reliable predictor of a difficult migration is the state of the data in the outgoing system, and almost every company underestimates this.

After a decade of use, a typical SME ERP contains duplicate customer records, products that exist under two codes, addresses in inconsistent formats, historical transactions referencing entities that no longer exist, and fields repurposed for things they were never meant to hold. None of that stops the old system working, because the people using it know the workarounds.

A new system will not know them.

Do a data audit before you commit to a timeline, not after. You are looking for how many records actually need cleaning, who decides what the correct value is when two records disagree, and which historical data you genuinely need to migrate rather than archive. That last question saves more time than anything else on this list: most companies migrate far more history than they will ever use, because nobody wanted to be the person who said delete it.

Sequence the work around the business calendar

An obvious point that gets ignored under delivery pressure: do not cut over during your busiest trading period, at financial year end, or while your most knowledgeable operations person is on holiday.

Work backwards from the business calendar and let it constrain the plan. A migration that lands two months later in a quiet period is cheaper than one that lands on schedule in peak season and disrupts it.

Build in a period after cutover where the pace of other change drops. The new system will surface problems in week three that nobody anticipated in testing, and you need capacity to fix them rather than a team already committed to the next initiative.

Keep the old system readable

Whatever else you do, keep the outgoing system available in a read-only form for longer than you think necessary, ideally a full financial year.

You will need it. Somebody will ask a question about a transaction from before the cutover that the new system cannot answer, and an auditor may ask a harder version of that question later. Decommissioning early to save a licence fee is a false economy that becomes apparent at the worst possible time.

What this has in common with every other modernisation

The pattern here is the same one behind the real cost of the system you keep postponing: the risk is rarely in the technology, and almost always in the organisational knowledge wrapped around it. The old ERP works because people have built workarounds for its deficiencies over years. A migration replaces the system instantly and the accumulated knowledge slowly, and the gap between those two is the project’s actual risk.

We have run this kind of restructuring where the constraint was legacy requirements meeting modern engineering, in the Humanity Schedule work for TCP Software. The technical piece was tractable. The part that needed real attention was sequencing the change so delivery never stopped.

Frequently asked questions

How long should an SME ERP migration take?

It ranges too widely to give a useful number, and any supplier quoting a duration before seeing your data is guessing. The more useful framing: the selection phase is the short part, the data preparation is the long part, and the stabilisation period after cutover is the part most often omitted from the plan entirely.

Should we customise the new ERP to match our current processes?

Usually less than you want to. Heavy customisation recreates the constraint you are trying to escape and makes every future upgrade harder. Reserve customisation for the processes that genuinely differentiate your business and adapt to the standard behaviour everywhere else.

Can we migrate without dedicated internal people?

Not well. You need at least one person who understands how the business actually operates, with enough authority to decide what a correct data record looks like. Implementation partners can supply capacity and method, but they cannot supply that judgement, and projects where nobody internal owns it tend to stall at exactly the data-cleaning stage described above.

If you are scoping an ERP migration and want a second opinion on the sequencing before you commit to a date, book a 30-minute technical audit conversation.