In our experience, ERP migrations rarely fail because the software could not do the job. They fail because the data going into it was not ready, and nobody found out until the first close.
The good news is that the failure modes are predictable. Here are the five we check for before configuration starts, in the order they cause the most damage.
Most charts of accounts in growing companies are archaeological. There is a layer from the original bookkeeper, a layer from the first financial controller, a layer added for a specific investor report, and a set of accounts created to work around a limitation in the old system.
The symptoms are recognisable: accounts nobody can define, near-duplicates like Consulting Income and Professional Services Revenue, dimensions encoded into account codes because the old system only supported two tracking categories, and a handful of accounts that exist purely to make one report balance.
Migrating that structure into a new system carries the mess forward and wastes the main advantage of moving — a multi-dimensional ledger where region, product and cost centre are dimensions rather than account codes.
Rebuild the chart of accounts before you migrate, not after. It is genuinely the highest-leverage work in the entire project.
If you have more than one entity, you have intercompany transactions: loans, management fees, shared service recharges, cost allocations. If those were posted inconsistently — one side booked, the other missed, or both booked at different FX rates — the balances will not eliminate.
This is the single most common cause of post-migration audit findings we see. The opening balance sheet does not reconcile at group level, and the difference has to be explained to an auditor who was not there when it accumulated.
Reconcile intercompany positions before cutover. If there are historical differences that cannot be resolved, document them, get them approved, and write them off deliberately — rather than migrating them and discovering them later.
Under AASB 121, different items translate at different rates: monetary balance sheet items at the closing rate, non-monetary items at historical rates, income and expenses at transaction-date rates or a reasonable average, with the resulting difference to a currency translation reserve.
Many groups translate everything at one month-end rate, because that is what the old system made easy. The migration will expose it, because the new system will calculate it properly and the comparatives will not agree.
Decide before cutover how you will handle the transition, and involve your auditor in that decision rather than presenting it to them afterwards. Proper multi-currency handling is one of the main reasons to move — but it is also the thing most likely to surface a historical problem.
If deferred revenue has been calculated in Excel and posted as a manual journal, the schedule and the ledger have almost certainly drifted. Contract amendments get applied to one and not the other. Cancellations get missed. Someone overwrites a formula.
Before migrating, reconcile the contract population to the deferred revenue balance. Every open contract should trace to a remaining performance obligation, and the total should equal the balance sheet. If it does not, you need to know why before that number becomes an opening balance in a system that will hold you to it.
This matters more than most teams expect, because automated revenue recognition only works if the starting position is correct.
This one is less technical and more consequential than it sounds. Ask three people what counts as ARR and you will often get three answers. Does it include professional services? Usage overages? Contracts in their notice period? What is the treatment for a customer mid-downgrade?
If those definitions are not agreed before the system is configured, they get baked into reports and the disagreement resurfaces at board level six months later, when someone notices two decks with different numbers.
Write the definitions down. Get the CFO to sign them. Then configure reporting against them.
Fix the chart of accounts. Reconcile intercompany. Resolve FX treatment with your auditor. Tie the revenue schedule to the contracts. Agree the metric definitions. Then configure the system.
Doing it in that order takes longer at the start and dramatically shorter overall, because the first close on the new platform behaves like a normal close rather than an investigation.
This preparation is most of what our implementation engagements actually consist of. The software configuration is the fast part. The data work is the project.
If you are planning a migration and want the problems surfaced before you commit to a cutover date, get in touch.