Part of the Replacing a consolidation or planning system: the complete guide series.
The biggest argument in any consolidation system migration is how much history travels with it. Groups arriving from a structured system - SAP BPC, SAP BFC, Oracle HFM, Cognos Controller - face a real choice. Groups arriving from spreadsheets have no system history to migrate; that decision is covered separately at moving group consolidation off Excel. For everyone else, the answer sits between the two defaults that both get it wrong.
Why the implementer's answer and the auditor's answer are both wrong
The implementer's instinct is to migrate nothing. Close the books in the old system, open clean in the new one, and treat the cutover as a fresh start. The auditor's instinct is to migrate everything: every period, every journal, every intercompany balance back to inception. Both positions are defensible in isolation and unworkable in practice. Bringing nothing leaves you unable to produce audited comparatives in the new system for the first reporting period. Bringing everything turns a system implementation into a data archaeology project that will cost more than the licence and take longer than the project team has been told to expect. The correct scope sits between them, and it is determined by three tests: what the comparatives need, what the auditors must be able to re-derive, and what the new group chart of accounts can actually carry.
What do the comparatives actually require?
Comparatives require one full prior year at the grain you report externally, and an opening balance that agrees to the old system's closing balance on the day of cutover. That is the minimum that satisfies an auditor reviewing your first set of statutory accounts produced in the new system. The grain matters: if you report by legal entity and segment, you need both dimensions for the comparative year. If your prior system held data at a higher level of aggregation, you cannot manufacture the missing grain in migration - that becomes a disclosure issue, not a data issue. Get the opening balance reconciliation signed off in writing before cutover; it is the single document that closes the argument about whether the new system started correctly.
Balances or transactions - which do you actually need?
This is the question that determines the size of the migration project. Migrating closing balances for each period is a contained, testable exercise. Migrating the underlying transactions that produced those balances is an order of magnitude larger. For consolidation purposes, period-end balances are almost always sufficient: the consolidated result is a function of reported entity balances and group eliminations, not of individual transactions. Transactions matter only where your new system will be asked to re-run eliminations or re-derive a result that the old system already calculated. If you are migrating the answer rather than the working, balances are enough. Agree this in writing with your auditors before scoping the migration - their sign-off on a balance-only approach saves a large amount of downstream argument.
What does history cost when the chart of accounts changes?
Every year of history carried back must be re-mapped to the new group chart of accounts. If the new chart is materially different - consolidated line counts change, cost centres are restructured, legal entity reporting hierarchies shift - then each historical period requires its own mapping exercise, tested and reconciled. This is the part that implementers underestimate and the part that breaks timelines. The complexity is covered in detail at consolidating entities with different charts of accounts. The practical implication for history scoping is direct: the further back you carry data, the more mapping versions you manage. Limit historical years to what the three tests require, and the mapping problem shrinks proportionately.
What about ownership history and FX - the part groups forget?
Ownership percentages and functional currency assignments are not always treated as data in consolidation migrations, but they are some of the most consequential. If the new system cannot see the ownership structure that existed in a prior period, it cannot correctly calculate minority interest for that period. If it cannot see the functional currency in effect when a balance was first recognised, it cannot correctly retranslate. Groups that migrate balances without migrating the ownership and FX history that underpins them discover the problem when they try to run a prior-period comparative and the minority or translation line does not agree to the filed accounts. Correcting this after go-live - a restatement of comparative data in a live system - is significantly more painful than building it into the migration scope from the start.
Journals and manual adjustments - data or workarounds?
Every consolidation system accumulates manual journals over time. Before migrating them, each one should be classified: is this an adjustment that reflects a real economic or structural fact, or is it a workaround for a limitation of the old system? Intercompany elimination journals that the old system could not automate are a common example of the second type. If the new system handles the elimination natively, the journal is not data - it is a patch that the new system makes redundant. Migrating it would produce a double elimination. Work through the journal population with someone who knows why each entry was posted. Migrate the economic fact; leave the workaround in the archive.
What does the old system's archive have to do for the auditors?
The archive of the old system must be retrievable, readable, and provably unchanged. That is a smaller ask than a migration. Auditors need to be able to access a prior-period report, trace a balance to its inputs, and confirm that the data has not been altered since the period was closed. A read-only extract, held in a format the auditors can open without a live licence, and with a documented chain of custody, satisfies this requirement. It does not need to be a running system. It does not need to produce new output. Treat archive as an infrastructure and governance question, and scope it separately from the migration.
Benchmark your current state before scoping any of this
Before any migration scope is written, you need an honest picture of what the current consolidation function actually holds and how mature it is. The Finance Value Score covers consolidation maturity as one of its six areas, and the output includes a view of the gap between your current state and the level-5 frontier across the whole office of the CFO. That context matters for migration scoping: a group sitting at level 2 on consolidation will have different data quality assumptions baked into its history than a group at level 4. Scope the migration after you have read the current state, not before.
This article is part of the replacing finance systems series.
Common questions
How much history do we need to bring across when moving to a new consolidation system?
The minimum is one full prior year at the grain you report externally, plus an opening balance that reconciles to the old system's closing balance on the day of cutover. This satisfies the comparative requirement for your first statutory accounts in the new system. Anything beyond this should be justified by a specific audit or reporting requirement, not migrated as a default.
Do we need to migrate transactions or just balances for consolidation history?
For consolidation purposes, period-end balances are almost always sufficient. The consolidated result is derived from reported entity balances and group eliminations, not from the underlying transactions. Migrating transactions is only necessary if the new system must re-run a calculation that the old system already completed. Get auditor sign-off on a balance-only approach before scoping begins.
What do we leave in the old system when we move consolidation platforms?
History that sits outside the three tests - comparatives, audit re-derivation, and chart capacity - belongs in the archive of the old system, not in the migration. The archive must be retrievable, readable in a format that does not require a live licence, and provably unchanged since the periods were closed. That is a governance task, not a migration task.
Why does a change in the chart of accounts affect how much history we can migrate?
Every historical period carried into the new system must be re-mapped to the new group chart of accounts. If the chart has changed materially, each period requires its own mapping exercise, tested and reconciled independently. The further back you carry data, the more mapping versions you must manage and validate. Limiting historical periods to the minimum required by the three tests directly reduces the mapping workload.
What happens if we forget to migrate ownership and FX history in a consolidation migration?
Without historical ownership percentages, the new system cannot correctly calculate minority interest for prior periods. Without the functional currencies in effect when balances were first recognised, it cannot correctly retranslate. Both gaps surface when comparative reports are run and produce figures that do not agree to filed accounts. Correcting them after go-live requires a restatement of comparative data in a live system, which is significantly more disruptive than including ownership and FX history in the original migration scope.