A new ERP doesn't fix a slow or unreliable close because migrations move configuration, history, and interface, but not the undocumented corrections that made the old system work. Inputs from other departments, unwritten business rules, and missing reconciliations carry forward unless they're codified and tested before the migration.
There's a pattern I've watched repeat across companies of every size.
The close is slow. Reports need a second look before anyone trusts them. Leadership asks a simple question and waits three days for the answer. Someone concludes the system is the problem, and a replacement project begins. Months later the new platform goes live, and the first close looks remarkably familiar. Different screens. Same exceptions.
The system changed. The inputs didn't.
What actually moves in a migration
A migration moves three things: the configuration, the history, and the interface. It doesn't move the knowledge that made the old system work.
That knowledge is the corrections. The accounts that always get reclassified. The customer billed through a partner. The prices that come through wrong and get fixed by hand. The report that only ties after one specific adjustment. None of it was ever part of the old system. It was part of the people around it.
So it doesn't migrate. It gets rediscovered, one exception at a time, during the first few closes on the new platform. And it gets rebuilt where it lived before: spreadsheets and memory.
Three things a new system can't fix
Inputs it doesn't control. A general ledger is only as accurate as what flows into it. If billing, operations, or another department sends data that needs correcting, the new system receives the same data the old one did.
Rules nobody wrote down. If the logic that turns raw data into reportable data exists only as habit, there's nothing to configure. The vendor can't implement a rule you can't state.
Proof that was never designed. If the old environment had no way to show a number ties to an independent source, the new one won't either, unless someone builds it on purpose.
A migration can make visibility worse, not better
Here's the part that rarely gets said out loud. A migration doesn't just fail to fix the problem. It can deepen it.
Your current system is more than a place where transactions live. It's a record of how the business has actually behaved for years. The patterns, the history, the ability to trace a number back to what happened and when: that context is built into the environment you're running now.
The moment you migrate, you risk breaking that thread. History gets truncated, remapped, or parked in an archive nobody opens. The traceability that let you answer "why does this number look like this" gets harder to reach, right at the moment everyone is under pressure to trust the new system. So you've added cost, left every process issue in place, and reduced the visibility you had before. That's not a lateral move. It's a step back.
Why the cleanup rarely happens
The implementation itself works against you here, and it's worth understanding the incentives.
The vendor's goal is to finish. Their incentive is to complete the implementation, hand it over, and move on. That's not a knock on them, it's how the engagement is structured. Meanwhile your team is already carrying the day-to-day close. They don't have spare capacity to drive the project, so they lean on the consultants. And the one piece that would actually protect the outcome, a real pre-implementation plan for how the data gets cleaned and translated into the new system, is the piece almost nobody spends enough time on.
I've watched this happen from the inside. The cleanup plan is treated as a phase to compress when the timeline slips. It's the first thing cut and the last thing missed, until the first close proves it mattered.
What to do before you buy
Find the corrections. List every manual adjustment your team makes between the source data and the final report, and who makes it.
Write the rules. Turn each correction into a stated rule: when this, then that. If the team can't agree on the rule, you've found a process problem, not a system problem.
Test the anchors. For each key number, ask what it ties to outside the file it came from. If the answer is nothing, that number can't be proven today, and it won't be provable after a migration either.
Only then evaluate systems. You'll know exactly what the new platform has to handle, and you may find that a governed layer on your current environment solves more than a replacement would.
The better sequence
Control the data you already have. Codify the rules. Build the proof. Then decide what, if anything, needs replacing.
And if you're already committed to a migration, the advice doesn't change, it gets more urgent. Diagnose before you cut over. Know what your numbers are, what they tie to, and which corrections have to come with you, while the old system is still there to check against. Going in blind is asking for trouble.
A Systems Diagnostic is a fixed-scope place to start. Start with a free 30-minute call.