"We'll just take the new version when it comes." I hear it from growing businesses all the time, and the instinct behind it is a good one. Cloud ERP isn't the on-premise software of fifteen years ago - updates arrive on a predictable cadence, the vendor does the heavy lifting, and most of the time it does just work. The trouble is the word "just". It's carrying more weight than it looks...
The reason why I decided to blog about it now is because there's an interesting change happening with Acumatica. Acumatica supports the Classic interface only in versions before 2026 R2 - so 2026 R1 is the last release that carries it, and after that the modern UI is simply the UI. For most businesses that's good news; the modern interface is the better one (although there's plenty of bugs/issues for Acumatica to iron out!), and the vendor's reasoning (maintaining two interfaces forever slows everything down) is hard to argue with. What it means in practice is a change every single user feels on the screen they use every day, and a re-check of anything you've had built on top of the standard system - a small project, not the invisible plumbing people tend to assume.
Where the cost actually sits
When an upgrade hurts, it's almost never the standard software that did the damage. The vendor's core product is solid and well-tested. The cost lives in three places, and they're the same three places every time.
Your customisations. Every bespoke field, custom report and tailored workflow is something you own, and something you re-test at every version. This is the part I care about most, because it's the part YOU as the end-user/client can control. The leaner your customisation footprint, the cheaper every future upgrade. The real cost of a customisation isn't building it once, it's re-validating it at every upgrade, forever, often without remembering why it was added in the first place. A surprising amount of bespoke work is really just a habit carried over from an older system rather than a genuine need, and an upgrade is the natural moment to ask whether you still need it at all.
Your data. An upgrade is a free excuse to notice the master-data mess you've been quietly tolerating. Things like duplicate customer records, items with three different naming conventions, the fields nobody fills in. None of it blocks the upgrade. All of it makes everything afterwards harder. Tidying it while you've got the bonnet open is far cheaper than tidying it under pressure later. I recently saw a client on Acumatica that upgraded to 26R1. They use RingCentral and there's a feature that allows you to call a customer by clicking the phone icon next to a contact's phone number. The issue? They hadn't been taking the time & care to maintain well formatted phone numbers, so this nice streamlined enhancement cannot be used until they tackle their master data. It seems like a small thing, but it can quickly become a 'death by a thousand cuts' if the business doesn't keep on top of master data management.
Your people. A new version only pays for itself if people actually use the new capabilities, and that doesn't happen on its own. The people who do the job every day decide, without ever saying so out loud, whether they'll engage with the new system before they're forced to - and the long-tenured ones, the ones who've seen two of these before, are the slowest to be convinced this one's different. Adoption is something you plan: a concrete reason to engage, a window to test in, a way of making "I've checked it" something people are seen to do. Hope for it instead and you'll discover it went missing the week after go-live, when it's a queue at someone's desk rather than a line on a test plan.
How to approach it
Treat an upgrade like a small implementation, because that's what it is. Scope it. Stand up a sandbox and actually test in it with people running their own day-to-day tasks, not having a vague "play" with the new screens. Give the people who'll live with the system a real reason and a real window to look before the deadline does the persuading. And go through the bespoke work deliberately, deciding customisation by customisation what's worth carrying forward and what was a habit you can finally let go of.
That last part is the whole of my philosophy in one sentence. A growing business doesn't need an enterprise change-management department to handle an ERP upgrade. It needs to keep the system simple enough that upgrades stay boring. BORING upgrades are the goal. They're a sign the underlying setup is lean, well-understood, and not quietly accumulating debt that someone pays back, with interest, the next time the vendor moves the platform forward.
The businesses that find upgrades painful are usually the ones who treated the last three as patches. The ones who find them boring did the unglamorous work of keeping things simple in between. Keeping it that simple and making the next upgrade a non-event is the kind of work I do.
