The first close after an ERP go-live tends to go like this. Someone on the finance team opens the new system to build the monthly board pack, the one that puts this year next to last year. They go check prior-year transactions because the chart of accounts changed and are reminded that only the trial balances are there. The new ERP started life more or less empty of the past.
Today, most ERP transitions leave the past behind. Advisors such as KPMG recommend migrating only active data into the new system, meaning open transactions, current master data, and general-ledger balances. Moving every year of history strains the new system and can consume 15 to 25% of the implementation budget on its own, so implementation teams exclude the older detail by design. The years of transactions your reports reach back into stay in the system you are retiring.
The trouble starts the first time you go to do something ordinary like prepare for budgeting.
You build the year-over-year comparison, and last year lives in one system while this year lives in another. You click into a variance because you want to see the transaction detail and invoices behind it, and the drill-down stops at go-live, because the transactions from before that date are not in the new ERP. You’re stuck between two systems and doing three times the work downloading from one, transforming to the new definitions, then manually pulling the numbers into a comparison to the new way of thinking. Any small thing causes this same rework of old to new as soon as your team needs to look behind a number. Together they turn a routine close or answering a simple question from the business into yet more hours of manual work, right when leadership is watching the new system most closely.
The old system retires on schedule
The real risk isn’t losing the old ERP. It’s losing continuity. Legacy systems are always retired, but the business still needs years of historical reporting, trend analysis, and audit support. Too often, organizations keep an old ERP running—not because they want another ERP, but because it’s the only place to access transaction history and get at reports that make sense. That’s an expensive way to preserve history.
Keep the reports,
do not rebuild them
Here is the plain version of the problem. The business runs the same as it always did, while the financial language describing it has changed. Last year sits in the old chart of accounts, this year sits in the new one, and someone in finance has to make the two agree, by hand, in a spreadsheet, every month until things settle.
Reporting-First Thinking separates historical reporting and access to historical transactions from the lifecycle of the ERP itself. Instead of tying years of financial history to a system that’s destined to be retired, it preserves the business definitions and GL transaction history that give that history meaning. The old ERP can be switched off without sacrificing trend analysis, historical comparisons, or confidence in the numbers.
A finance-owned reporting layer does not stop the old ERP from going dark on schedule. What it changes is where your history lives when that day comes. Adopted before the ERP transition, the reporting layer stays independent of the ERP, holds your historical context, and keeps that history reachable after the old system is retired, closing the retention gap. Your reports stay in Excel in the layouts leadership already uses, connected to transaction history that is instantly reachable, instead of rebuilding reports from scratch that are destined to be disconnected from the past. You change an account definition once and every report updates, rather than opening thirty files to fix the same thing thirty times. Access to history is not through the old ERP, it’s through the Excel report itself, with drill-down all the way to the accounts and transaction details behind any number.
The catch is timing, and it is the whole reason to decide early. If reporting is modernized and made adaptive to change while the old system is still live, when the legacy ERP is switched off, reporting and historical transactions behind these reports are still there. Leave it until later, and the same deadline that was always coming takes the history with it.
The question to ask before go-live
The call on what happens to your history gets made early in the project, often on a technical checklist, before finance realizes what it will cost them in the future. The useful question to raise while the configuration is still open is a simple one: after go-live, when I need last year’s number or the transaction behind it, where do I get it?
Our guide, Protecting Financial Reporting Continuity Through an ERP Transition, lays out the handful of ways teams keep their history reachable, what each one costs later, and a before, during, and after checklist you can work through with your implementation partner.
Download the guide → https://www.vividreports.com/erp-transition-guide/
