Think back to your first ERP go-live. If you winced just now, this one's for you.
Every prospect conversation has the same person somewhere in the room. Arms folded, slightly checked-out, the thousand-yard stare of someone still processing something that happened a decade and a half ago. They know the current system is failing. Everyone hates it. And they have quietly, firmly decided that whatever happens next, they are not going through that again.
I understand the reflex completely. But it's built on a false premise, and it's worth pulling apart because the project that person is dreading doesn't really exist any more. Your second ERP migration isn't your first one repeated.
Paper-to-data versus data-to-data
Here's the bit people miss, and yes, the data guy is going to open with data thirty seconds in.
Your first ERP migration was brutal because it wasn't really a data migration at all — it was a translation. You took a business that ran on spreadsheets, a QuickBooks company file, an inventory list living in someone's Access database, and a physical spike with the paperwork still stabbed onto it, and you turned all of that into a single system with a schema. You were converting cabinets full of paper and tribal knowledge into structured data for the first time in the company's life. That is the hard version of this job.
The second time, you're moving data to data. It's a schema-to-schema shift — one structured system remapped into another. The information is already typed, already related, already sitting in tables. You're not inventing the model from a filing cabinet; you're translating one model into a better one. That is a smaller and much more predictable class of problem, and it's a reason round two is easier.
The tooling grew up
It helps enormously that migration tooling is now genuinely good - to the point where the ERP vendors treat it as a competitive weapon. Every publisher wants you to be able to land on their platform more easily than on anyone else's, so they pour effort into the import tools, the templates, the validation. We're not far off an AI "migration agent" doing the first pass for you; the direction of travel is obvious.
Migration isn't even a one-and-done event you brace for at the end of the project — you can reload the whole data set seven or eight times across the build until it's right, because the modern platforms turn it round fast. And the industry has stopped hoarding your data in proprietary formats. Open APIs, normal database tables, Delta Parquet — the data is yours, and everyone's competing to make it easy to move. Fifteen years ago that was a fight. Now it's a feature.
The people already know what they want
The most underrated asset in a second migration isn't in any tool. It's the people.
A while ago I watched someone reprint a work order. Twenty-one clicks and four typed fields to pull an existing document back up as a PDF on screen. Not frustrated — muscle memory. They'd done it that way for years and stopped noticing it was absurd. You will not find that on a project plan, and you certainly won't find it in a rehearsed demo, where it would have been set up as a single button. You find it by standing behind the people who run the system and, occasionally, timing them.
Gather the team that survived the first go-live and they will tell you, in extraordinary detail, what they want from the next system and what they never want to see again. They've researched it without anyone asking. They understand how their work lands on the next desk. That knowledge makes the second project faster and better as long as you actually go and ask for it.
Integrations and cloud: the hard bits that turned into checkboxes
Two more structural wins, quickly.
Integrations used to mean a developer and a custom build. If you were a small or mid-sized business in the 2000s and you wanted your ERP talking to an e-commerce platform or a warehouse system, it either didn't exist or it was out of reach. Today it's iPaaS connectors and REST APIs — Shopify, Amazon, a customer's oddball invoice portal — mapped and running in fifteen or twenty hours. A lot of what used to be integration is now just configuration.
And cloud can delete an entire workstream. Your first ERP came bundled with an infrastructure project: on-prem servers, a cooled server room, SQL licences, VPN clients, a backup regime, and a disaster-recovery plan nobody had tested. A modern SaaS ERP is a login. Testing is a sandbox you spin up, use and throw away. Upgrades are a patch your vendor applies. And the classic objection "but what if the internet goes down?" never survives contact with the honest question of how often your server used to be taken down for maintenance.
The four ways to hand the advantage back
None of this makes it easy. It's easier, which is a different word. It's still a full business change — change management, people, process — and I've watched teams give the whole advantage straight back. Four traps in particular:
Like-for-like customisations. You'll arrive with ten to fifteen years of tweaks, bespoke reports and little workarounds, and someone will demand every one of them rebuilt identically in the new system. Treat every customisation as guilty until proven necessary. Most of what needed custom code last time is now standard, a configuration, or a checkbox — and a good chunk of it has simply been automated out of sight. "Where's the create-receipt button?" It doesn't exist; it happens when the warehouse scans. That's not a feature missing, it's a feature you no longer have to press.
Complacency. "We've done this before, we can do it with half the team." No. You remember the easy bits and you've conveniently forgotten the hard ones. Measure twice, cut once — same as the first time, just with better instincts.
Second-system syndrome. Confidence is dangerous. Because the first one worked, it's tempting to cram barcoding, the CRM migration and "some AI" all into phase one. Don't. Phase one is core business processes. The nice-to-haves are phase two. Don't bite off more just because you're feeling clever.
Data hoarding. Your first migration finally got the business off the receipt spike and the filing cabinet. Don't recreate the mess by dragging fifteen years of dead history into the new system "just in case." You don't need every exited customer, every vendor you stopped using in 2014, every closed invoice. Bring what earns its place — a couple of years of active master data, open balances, trial balances — and put the rest in a read-only data warehouse. That way, when someone asks for a part you haven't sold in twelve years, you can look it up, see that it didn't earn its keep, and make a deliberate decision about whether you even want that business back. You cannot make that call if you've blindly reloaded everything.
What to do in the next 90 days
Begin with your own people, not a shopping list. Hold a proper town hall: is this still the right system as you move into growth, new product lines, new markets? Get it all on the table, then turn the moaning into evidence — time studies, a customisation and integration audit, one-to-one interviews. Who is each problem actually hurting, and what is it costing them? Some of it might be fixable by configuring what you already own, and that has to stay on the table. But if the symptoms are strong enough, you'll know.
Then zoom out. If you're running Dynamics GP, Microsoft is winding it down and the practical end of the road is around 2029, which sounds futuristic until you remember it's three years away. Any flavour of classic NAV is on borrowed time too. If your company does a three-to-five-year long-range plan, an ERP migration belongs in it as a line item with a number against it, so the investment is parked and ready rather than sprung on everyone in a panic.
The thing keeping you on a system everyone hates isn't the system. It's the scar tissue from the first migration. And round two is a different project — easier, better understood, and mostly a matter of not squandering everything you learned the first time.
We talk about this kind of thing every couple of weeks on The ABCs of ERP & Beyond — me and Nirav Shah from AdCirrus ERP, usually with Emily Browning (off this week). If you're staring down a second migration and want a hand, Nirav's team does exactly this for a living at adcirruserp.com; if you'd like me to talk your ear off about why you don't need 20 years of GL history in your new ERP, I'm here at petenicholson.co.uk.
