Moving a 15-year-old ERP to the cloud without missing a month-end close

Why ERP projects overrun

The failure pattern is consistent and it is almost never the platform. A fifteen-year-old ERP is a record of fifteen years of decisions, written as code rather than prose. Customisations added for one plant, one tax rule, one customer, are invisible in the functional specification written for the new system, and they surface when a report returns a number nobody recognises.

Integrations are the second ambush. Most estates have interfaces nobody owns: a nightly file drop into a warehouse system, a payroll extract, a bank statement import. Each is discovered when it breaks, which after cutover means during a close.

The third is the chart of accounts, which is a history of the business: accounts that exist only because of an acquisition in 2014 or an auditor's preference in 2016. A cloud ERP expects a cleaner structure, so old values have to map to new ones, including to the dimensions the new reporting depends on.

Then there is availability. The people who understand the general ledger best cannot be released in the week before a close. A plan that needs the controller for three consecutive days in the last week of the month is not a plan; it is a request to postpone.

The sequence that works

Data cleansing comes first, before configuration. Customer, supplier, item and employee records get deduplicated, owners assigned and stale records retired. It is the phase most often compressed to protect a go-live date announced before anyone looked at the data. Compressing it moves the cost into the parallel run.

Second is the integration inventory. Every interface in and out of the legacy system gets named, mapped and given an owner. Put the count in the steering pack: it predicts effort better than the user count does.

Third is a decision on every customisation, and there are only three answers: retire it, rebuild it, or adopt the vendor's standard process instead. Rebuilding is the default and the expensive one. Vendor frameworks such as SAP Activate and the migration guidance for Microsoft Dynamics 365 put fit-to-standard analysis ahead of development.

Fourth is a parallel run covering at least one complete close, and fifth is cutover. The table below holds the project to that order.

What actually has to be tested

Four test sets carry the cutover prediction, and none of them is the system test script. The first is integrations: every interface runs with production-like volumes and bad input, not a hundred happy-path records. The second is interfaces to the systems finance uses, including the bank, the tax engine and the consolidation tool.

The third is reports, and this is the largest set. Every report that leaves the ERP and lands in front of a human is run against the same period in both systems and reconciled. Rebuilding the report catalogue in the target platform rather than reproducing it is a legitimate scope decision, but it has to be explicit, because someone is making decisions from a report that is about to disappear.

The fourth is period-end itself: the close checklist, allocations, currency revaluation, intercompany elimination, and the approval workflow that gates a journal entry. Testing these in isolation proves each step works; only the parallel close proves the sequence does.

Tax and statutory reporting deserves its own line rather than a paragraph inside the report test. The rules change on their own timetable, they are jurisdiction-specific, and in many countries the group has to file from the new system whether or not the migration went well. Public companies carry a further layer: the controls around those systems sit inside the scope of internal control over financial reporting.

Where the money actually goes

The subscription is the line everyone budgets, and it is the smallest of the new ones. Analyst work on enterprise application spending has long shown that services and internal effort outweigh licence cost, and that ratio turns a licence comparison into a business case. Partner fees, internal project time, dual running and retraining are the real structure.

Dual running is the cost that surprises. Running both systems in parallel for a close means two teams, two reconciliations and two bills, and in that window the new subscription is already being invoiced. Check the legacy licence for a partial-year termination right before signing.

Internal time is the cost that is never recorded. Key users pulled into testing, a data owner cleaning suppliers, an analyst reconciling two ledgers: none of it appears as a project line because it is absorbed into payroll. Track it anyway. It is the reason the day job slips, and a slipping day job is the symptom that gets a project cancelled.

Retraining scales with the number of process changes, not the number of users. A standard process adopted from the vendor's catalogue changes more habits than a rebuild of the existing screen, so budget change effort against process change and staff it with the people who already run it.

The contract clauses worth insisting on

Milestone acceptance beats time and materials for the buyer, and it is worth the premium. Tying payment to signed phase exits, with the criteria in the statement of work, moves the risk of a slow start onto the partner.

Ask for the named delivery team in the contract, not in a slide. Named individuals, defined roles, a stated change process when someone leaves, and the same names at the steering committee. Platform vendors publish success frameworks that define the roles needed on both sides, a useful checklist when comparing partner proposals.

Two clauses protect the exit. First, an independent data extract in an open format, delivered on request and at the end, so leaving does not mean abandoning your own master data and history. Second, explicit handover obligations covering documentation, configuration export and knowledge transfer, with the final payment tied to them.

Finally, a defined go/no-go gate: a scheduled date, a named decision maker, a written list of what must be true, and a fallback chosen in advance. The fallback is not always delay. Opening the new system for a limited scope and closing the remainder next quarter is a real option, and it is available only if it was designed before the gate.