Originally published on Start at Zero on Substack.
I have sat in a lot of ERP kickoff meetings, and there is a moment in almost every one of them when someone leans back and asks, “Can we just bring everything over?” I understand the instinct. What they usually mean is every vendor record from the last twenty years, every job code including the ones nobody has touched since the last reorganization, every one-off report, and every spreadsheet that quietly keeps a department running. The idea is that you move it all across and sort it out later. In my experience, later never comes, and what you end up with is a new system that behaves exactly like the old one, with a nicer login screen and a much bigger bill.
Where the real cost of migration sits
I want to be clear about where the money actually goes, because it is not where most people expect. Moving data from one system to another is the cheap part. The tools to do it already exist and they work reasonably well. The expensive part is the people who know what the data means sitting down to decide what is right, reconcile what does not match, and fix it. Those are usually the same people running payroll, closing the books, and answering the phones, so every hour they give to conversion is an hour taken away from the job the public is counting on them to do. You can almost always migrate everything if you insist on it. The real question I put to leaders is whether they want their best people spending months carrying old problems from one place to another.
Start cleaning before you sign anything
My view is that if your data is a mess, the best time to start cleaning it was a year ago, and the second best time is before you sign a contract. You do not need a vendor to begin. You can pick the data that has to be right on day one, things like employees, positions, pay rates, vendors, the chart of accounts, open purchase orders, and balances, and start looking for duplicates, inactive records, and fields that mean different things to different departments. Then comes the part that takes real work, which is getting everyone to agree on a single source of truth.
I see the same pattern over and over. Finance thinks a position is one thing, HR thinks it is another, and the budget office keeps a third version in a spreadsheet nobody else has seen. Until those groups agree, any data you load into the new system is just one opinion among several, and the system will faithfully reproduce whichever opinion happened to win the conversion. That is why I would put the effort into the agreement first and let the cleanup follow from it, rather than the other way around.
Convert what has to reconcile, and archive the rest
Not every record deserves a place in the new system, and the rule I use is simple enough to say in one breath: convert what has to reconcile and archive the rest. Open balances, active employees, current vendors, and live contracts need to come over and tie out. Ten years of closed transactions probably do not. Those older records still have to be kept, searchable, and retained under your records schedule, but they do not need to be loaded, mapped, and tested inside the new ERP, and that is exactly where I have watched a lot of conversion budgets quietly disappear.
Old habits turn into expensive requirements
Data is only half the mess, and process is the other half. When an agency asks its people what they need from a new system, the answer is usually a detailed description of the current system. That is natural, because it is what they know, but it means the requirements document turns into a portrait of old workarounds, and the new system ends up being judged on how well it reproduces them.
Modern cloud software gives you far less room to tailor things than the on-premise systems most agencies are leaving behind. I think that is mostly a good thing, but it becomes a trap when you try to force old processes into it. Every time I hear “we have always done it this way,” I ask why. Sometimes there is a law, a policy, or a union agreement behind it, and those you should keep. More often, the honest answer is that the old system could not do it any other way, and staff built a workaround that eventually hardened into a habit.
Use the project to simplify payroll
Payroll is the clearest example I know of complexity that builds up over time. Over the years many agencies collect pay cycles, pay options, and special cases, and while each one made sense when it was added, together they make every upgrade, every test cycle, and every audit harder than it needs to be. A new system is a good reason to look at that whole pile again and decide which pieces still earn their place. The catch is that changes to pay land on real households and real monthly budgets, so simplification goes far better when people have time to plan for it. The agencies I have seen announce those changes early spend much less time handling grievances after go-live.
Discovery will miss things, and that is fine
Some teams respond to all of this by trying to document everything up front, with months of discovery sessions where every edge case is mapped and every exception is written down. It is a reasonable instinct, but it is an impossible goal, and something will surface in testing that nobody mentioned. When it does, I would resist the urge to build it automatically. I would ask what it costs to support, what it costs to drop, and who gets to decide, because a forgotten process is a decision to be made, not an emergency to be rushed.
Change management is part of the project
None of this works if people feel it is being done to them. Data cleanup and process redesign ask staff to give up things they know for things they have not seen yet, usually while they are still doing their regular jobs. I plan for that the same way I plan for conversion, with dedicated time, named owners, and a schedule people can actually see, rather than hoping it takes care of itself in the last month before go-live.
What I would ask before going to market
If you are writing an RFP or getting ready to, there are three questions I would put to your team first. I would ask which data has to reconcile on day one and who gets to decide what correct means. I would ask which of your current processes exist only because the old system forced them on you. And I would ask what complexity you are willing to delete, and when you plan to tell people.
That is what Start at Zero looks like in practice. The goal is a fresh start you have chosen deliberately, not a fresh copy of the old mess. Answering those three questions honestly before the RFP goes out will shape your requirements, your conversion plan, and your timeline far more than any feature list a vendor brings to the demo, and it gives your team a shared answer to point to when someone asks, a year from now, why a particular report or pay option did not come over.
If you are in the middle of an ERP or AI decision and want a second set of eyes before you commit, I am happy to talk. You can book a free 30-minute decision review with me at startatzero.averoadvisors.com.
Planning your next move? Write to us.