Every ERP project ends up at the same fork in the road. Upgrade what you have, or migrate to something new. Most teams pick badly — not because they pick the wrong vendor, but because they never define the terms. They treat upgrade and migrate as the same kind of project at different scales, when in fact they're different operating models entirely.
This is the framing episode for our mini-series on the upgrade vs migrate question. Before any of the deeper-dive episodes that follow, the terms need to be straight.
What's actually the difference?
A real upgrade keeps the underlying architecture intact. Same product, same data model, same configurations, same customisations, just on a newer version. You're current on patches, you've picked up whatever new features the vendor has shipped in the last twelve months, and the work is mostly testing. SaaS products force you into this rhythm whether you like it or not — Acumatica's 26R1 to 26R2 is an upgrade. Business Central wave-to-wave is an upgrade.
A migration changes the architecture. Different data model, configurations redesigned from scratch, customisations rebuilt or abandoned, training restarted. NAV 2009 to Business Central is a migration. GP to Business Central is a migration. Sage 50 to Sage Intacct is a migration. The vendor will call all three of these upgrades because they're inside the same product family, but the underlying work is migration-sized. Calling it an upgrade doesn't make it one.
The test is simple. Do your existing configurations carry across as configurations, or do they need to be redesigned? If it's the latter, you're migrating. The customisations are the giveaway — if they don't survive the move, the architecture has changed enough that the rest is migration work too.
The cloud rebadge trick
There's a particular pattern worth calling out, because it's now the most common way "upgrade" gets misused.
A vendor takes their old on-premise product. They sign a hosting deal with a partner. They put up a new landing page. The product is now "in the cloud". Same UX, same database schema, same limitations, same patch cadence. You're paying a subscription forever instead of an annual maintenance fee, and the only thing that's changed on your end is you access it through a browser instead of a VPN.
That isn't an upgrade. That isn't even a migration in a useful sense. It's a billing model change dressed up as innovation. If the vendor is doing this, it tells you something about the product — they're investing in commercials, not engineering.
The flip side is also true. A vendor genuinely re-architecting for cloud — rebuilding the data model, redesigning the UX, restructuring the back end — is doing real engineering work, and moving onto that new version is a migration whether they call it one or not. Either way, the label on the box doesn't tell you what kind of project you're signing up for. The architecture does.
When the right answer is upgrade
Stay on the same product when three things are true. The product is genuinely built for what your business does, today, not what it did when you implemented. The new version is real engineering work, not a billing change. And your existing configurations and customisations carry across without needing to be redesigned.
If all three are true, an upgrade is the lowest-risk, lowest-cost, fastest-payoff option. You get the new features, you stay current on patches, you keep your team's accumulated knowledge of the system. The case writes itself.
The trap is assuming an upgrade is always the safer option just because it has the word "upgrade" in it. Sometimes the upgrade path delivers a system that's still wrong for your business — only now it's wrong on a five-year subscription instead of a paid-once licence. Safety is about outcomes, not vendor continuity.
When the right answer is migrate
Move to a different product when one or more of the following is true. The system you have isn't built for what you've become — your business has changed shape and the ERP hasn't kept up. The "upgrade" path is really a migration in disguise, and you're doing migration work either way. The vendor has stopped investing in real engineering and is selling you billing-model changes. Or the new system is going to do enough of what you do out of the box that you stop accumulating tech debt every quarter.
The honest version of this question is: if you were starting from scratch today, would you pick the same product? If the answer is no and the upgrade path is migration-sized anyway, the migration option is back on the table.
Doing the cost comparison properly
This is where most projects go wrong, and not in the way people expect.
The mistake isn't picking the more expensive option. The mistake is comparing the wrong numbers. There are three different cost numbers in play: the sticker price on the quote, the total cost of ownership over five years, and the cost of doing nothing for the same period. Most projects only ever look at one. Almost nobody compares all three.
Sticker price is the line item the partner sends you. Total cost of ownership adds the subscription, the integration spend, the change management, the internal time, the training, the inevitable scope creep, and the consulting hours over five years. The cost of doing nothing is harder to put on a quote, but it's real money — the redundant data entry your team does because the system can't, the EDI customer you can't take on because you don't have the middleware, the talent you can't hire because nobody wants to learn a 2009 codebase, the cybersecurity exposure that compounds every month you stay unpatched.
Compare all three. Honestly. The conclusion is often the opposite of the one the sticker price suggested.
The counter-intuitive bit, which is worth pushing back on the default assumption: migration is sometimes cheaper than upgrading. If the upgrade is really a migration in disguise, the work is the same either way — and you might as well do the comparison properly and see if there's a product that fits better out of the box. Plenty of businesses upgrade to the same vendor's new product purely because it felt safer, and pay more than they would have for a better-fitting alternative.
The cost nobody puts on the spreadsheet
The biggest cost in any ERP project isn't the licence and isn't the implementation. It's internal preparation — and it's the one number nobody puts on a quote.
If you go into the project with messy processes, ambiguous ownership, undocumented decisions and dirty data, you'll pay for that one of two ways. The partner bills you for figuring it out, or the project slips while you figure it out yourselves. Either way, it's the most expensive line item you didn't budget for.
This applies whether you're upgrading or migrating. The new system inherits your bad processes if you don't fix them first. An upgrade with messy data is still an upgrade with messy data. A migration with unclear ownership is still a migration with unclear ownership. The savings come from doing the work before the project starts, not from picking the right vendor.
What this means in practice
Upgrade and migrate are not the same kind of project, and most teams pick the wrong one because they treat them as if they are. Define the terms first. Ignore what the vendor calls it and look at what the architecture actually does. Compare three cost numbers, not one. And do the internal work before the project starts, not during it.
This is the first piece in a mini-series. The rest will go deeper — on how to assess whether your current system is genuinely fit for purpose, the technical signals that distinguish a real upgrade from a migration in disguise, and how to model total cost of ownership without kidding yourselves.
If you're staring at the question right now, the rule of thumb is this: the label on the project tells you almost nothing. The architecture, the configurations, and the five-year cost tell you everything.
This is from episode S4E12 of The ABCs of ERP & Beyond
