ERP Migration in Finance
An ERP or system change in the finance function is the replacement of the existing bookkeeping or ERP system with a new one. What decides the outcome is not the technical questions but the chart of accounts, data quality and whether the new presentation can be reconciled to the old.
What is being replaced
The term covers two quite different undertakings. One is replacing a pure bookkeeping package with a system that brings accounting, controlling and reporting together. The other is replacing a full ERP system, in which finance is only one module among several. The effort differs considerably; the critical points are the same.
Typical triggers
The existing system falls out of support. An investor requires group standards, often alongside an IFRS conversion. After an acquisition two systems run side by side – the normal case in post-merger integration. Or spreadsheet structures that grew up next to the accounts no longer carry the complexity. In each case the decision is rarely free; the question is how the change is led.
Why it is not an IT project
Technology is rarely the bottleneck. The decisions a system change turns on are technical in the accounting sense: what does the future chart of accounts look like, on what logic are costs allocated, how will accruals be posted in future? Leave those questions to IT and you get a system that works technically and says nothing commercially.
The reconciliation
The most important point of the whole exercise. Where the chart of accounts or the allocation logic changes, the new presentation must remain reconcilable to the old – otherwise every prior-year comparison is worthless. It barely shows in day-to-day operations and hits fully later: in the next financial due diligence, in a bank meeting, in an investor report. A documented reconciliation therefore belongs in the mandatory scope, not the optional one.
Master data
What exists is what gets migrated – errors included. Duplicate suppliers, outdated addresses, inconsistent item numbers, unreconciled balances: whatever is not cleaned before the migration is harder to correct afterwards than before. Data cleansing is the single most underestimated block of work.
The trial close
Before go-live, at least one full monthly close should be run in the new system and reconciled to the result in the old one. The first real close is the wrong moment to discover migration errors, because a deadline towards shareholders or banks is already running.
Keeping the lights on
During the changeover the monthly close has to continue, on the agreed date and at the usual quality. This is where projects most often fail: the team is ground between day-to-day work and the project, and both suffer. Without additional capacity, either the migration stretches or the closes slip.
A realistic timeframe
For a mid-sized company, six to twelve months from requirements to stable operation is normal. The sequence that holds: requirements and chart of accounts, then data cleansing and migration rules, then the trial close, then go-live – and only after that the fine work on reporting.
The right moment for automation, incidentally, is after the changeover rather than during it: purchase-to-pay automation and a measured automation rate presuppose stable processes.
Who runs the project
A migration is peak load alongside the day job and ends afterwards. How a fixed-term mandate for it is scoped is set out under Interim CFO; for ongoing external financial leadership, see External CFO.