ERP Migrations Are Business Archaeology, Not Software Configuration

A few weeks back, someone posted a question in a supply chain forum I follow. They were a few months out from an ERP cutover and wanted to know what actually breaks after go-live that testing never catches, and whether that's avoidable with better test coverage or just the nature of production.

The most upvoted answer wasn't reassuring. Twelve months to shake out the bugs on a large implementation is a good outcome. Twenty-four to thirty-six is normal.

I answered too, because it's a question I've watched play out more times than I can count over twenty years of advisory and integration work. There are really two different failure modes hiding under "testing didn't catch it," and they behave completely differently.

A bug is when the system doesn't do what you intended it to do. Free shipping over $100 got configured as free shipping over $10. Someone finds that fast, usually inside the first billing cycle or the first month-end close, because it's loud and it's wrong against a rule everyone already agreed on.

A coverage gap is different. The system didn't get the rule wrong. Nobody surfaced the rule in the first place. The old system handled some edge case a certain way for a reason nobody wrote down, and the new system doesn't, because nobody ever asked it to. Nobody lied in discovery. Nobody forgot to test something they knew about. The knowledge just never made it into the room.

That's why the timeline splits the way it does. Bugs get sorted in the first few cycles, because they show up every time you run the process. Coverage gaps can take years, because you're waiting on the one order type that happens twice a year, handled by the one person who's done it that way since 2014 and has never once been asked why.

Which means the real lever isn't test coverage. It's discovery coverage. Good testing tells you the system does what you specified. It can't tell you whether you specified the right thing. That only comes from slowing down enough, before go-live, to find out how the process actually runs today, not what the SOP says, because nobody's opened that SOP since the day it was written.

Call it business archaeology. That's the actual job during a migration: not configuring software, but excavating years of decisions to figure out which ones still matter, before one of them turns into a coverage gap you discover two years in.

This is what discovery coverage actually looks like in practice, and nobody hands you a map of it. Ask around the building, "what workarounds do we have?", and you'll mostly get silence, because a workaround stops feeling like a workaround once enough time passes. It just feels like Tuesday.

You find the real ones by watching, not asking. Sit with the person who closes the books each month and watch what they actually touch, not what the documented close process says they touch. You'll usually find a spreadsheet in there somewhere, quietly doing work the official system was supposed to do, because at some point that system stopped being trusted and nobody ever formally replaced it.

Ask whoever touches the system daily what still runs on autopilot overnight. Every company I've worked with has at least one batch job nobody currently on staff remembers writing, exporting a file nobody currently on staff downloads. Somebody needed it once. Ask who owns it now, and watch how long the silence lasts.

Walk the physical process, not the flowchart of it. Ask each department head one question: what would break, today, if this system went down for eight hours? The answer is rarely the thing on the org chart. It's usually a side process everyone works around so routinely they've stopped noticing it's there.

Talk to whoever is closest to leaving, whether that's retirement or a resignation you already know about. The tribal knowledge walks out the door with them, and it's the cheapest excavation you'll ever do, because right now it still has a pulse.

Once you've found one of these, you still have to decide what to do with it, and that's a separate question from finding it in the first place. Here's the test I use, and it isn't mine originally. I picked it up from a conversation between two implementers who'd clearly both been burned before. For every workaround you uncover, ask:

Not whether it's in the requirements document. Not whether anyone has asked to change it. Who, specifically, notices the difference and says something. A customer. An auditor. A regulator. A report that someone downstream actually opens and acts on. This isn't a question you ask once at the start of the project. It's a question you run against every batch job, every spreadsheet, every oddly formatted report, one at a time, as you find it.

If nobody can name that person, after actually looking, what you're carrying forward is a habit the old system happened to enforce. Drop it. Keeping it doesn't preserve anything except the cost of building it again.

If you can name that person, you're not looking at a coverage gap waiting to happen. You're looking at a requirement, and it deserves the standard treatment: documented, owned, designed as a normal part of the process instead of patched in as a special case. A company shipping to one customer with a specific label format doesn't have a shipping workaround. It has a shipping standard for that account, and the new system should know that the same way it knows anything else it does by default.

That distinction matters more than it sounds like it should. A workaround gets rebuilt as a hack, brittle and undocumented, because everyone still thinks of it as an exception. A requirement gets rebuilt as infrastructure, because everyone agrees it's simply how the business works. Same underlying process, completely different level of care in how it survives the transition.

I watched a company spend three extra weeks and a meaningful chunk of budget replicating a reconciliation process nobody in the room could explain. "That's how we've always done it" felt safer than testing whether anyone would notice its absence. Nobody did. They found that out after the fact, the expensive way, once the new system had already been built to match the old habit.

The vendor will tell you the hard part is the configuration. It isn't. The hard part is finding what's buried and having the discipline to sort it honestly, one piece at a time, before you ever open the implementation guide. That part was always yours to run.

If you're heading into a system change and want a clear read on what your current setup is actually doing, and why, before you commit budget to replacing it, the QUILT Assessment is built for exactly that gap.