Eighty-odd episodes of this podcast and almost every one has pointed the same direction. Outgrow the spreadsheets. Get off the paper. Upgrade the system. Migrate to the cloud. Choose your first ERP.
This week we went the other way.
Because there are businesses out there sitting on a legacy tier 1 ERP — a gargantuan thing costing them serious money in licensing every year and serious money again in support — that they do not need. And we talk endlessly about how you only do these projects once a decade, so make the most of the fifteen years of progress you've missed. That argument works just as well in reverse. Fifteen years stuck on something enormous. Go and look at what the smaller systems do now.
I'm going to keep calling it a downgrade, by the way. There's a lot of marketing designed to blur this — realignment, fit reassessment, right-sizing, de-scoping. All of it exists so nobody has to say the quiet part. And the quiet part matters, because this isn't a case of moving to something newer that happens to be smaller. The whole point is that you're deliberately buying less.
It's more common than we thought
Emily's honest reaction when Nirav first suggested this topic was that she'd never come across it and didn't know how common it was. Then she spent a few months at trade shows and talking to implementation partners, and it turns out it's everywhere.
Nirav calls it a growing epidemic. These tier 1 systems were sold fifteen, twenty, thirty years ago, and at the time they were often the right call. Multi-language. Multi-entity inventory visibility. Several taxation methodologies in a single instance. Those were genuinely hard problems in 2005 and only the big platforms solved them.
Software got better. More power fits in smaller packages now. And a lot of companies are sitting there paying a six-figure annual maintenance bill on a perpetual licence they bought decades ago, scratching their heads.
The tiers, and what they actually mean
I went digging in Panorama Consulting's 2026 ERP Report before we recorded, because "tier 1" and "tier 2" get thrown around constantly by people who've never defined them. Panorama split it three ways, and the thing to notice is that the split is based on your revenue, not on the quality of the software.
Tier 1 — enterprises above $750m annual revenue. Complex either operationally or in entity structure and consolidation. SAP S/4HANA, Oracle Fusion Cloud, Infor CloudSuite.
Upper tier 2 — $250m to $750m. May span multiple industries and business units. IFS Cloud, Sage X3, Epicor Kinetic, Dynamics 365 Finance, Dynamics 365 Supply Chain Management.
Lower tier 2 — $10m to $250m. Usually one industry, single entity. NetSuite, SYSPRO, Acumatica.
Take the bands with a pinch of salt — plenty else factors in. But it's a useful frame, and if you're a £60m manufacturer running S/4HANA it's worth knowing you're on software built for companies ten times your size.
The argument the episode turns on
Nirav's response to that list was the best thing said all episode, and it's this: the third-party ISV market shakes the whole taxonomy up.
Say you're looking at Acumatica and you need proper multi-entity functionality, and that's the reason you're being pushed towards IFS or Epicor. There's a very good third-party solution for multi-entity in the Acumatica ecosystem. If that's the only real gap, and the rest of the product fits you out of the box, why are you looking at tier 1 at all?
That marketplace didn't exist twenty years ago. It does now. So Nirav's challenge to anyone listening was to go and find a lower tier 2 product that can't do 90 to 95% of what tier 1 does once you've added the right ISV. Nine times out of ten, he reckons, you'll conclude tier 2 is where you should land.
The alternative is what happens today. You go to a vendor's website, you find the one thing it doesn't do, you Google, you find SAP does it — and you buy the one thing you need bundled with seventeen things you'll never touch.
Emily added the necessary correction, and she's right. This isn't "buy Acumatica plus five add-ons and it'll work." The basics are all there already. You might need one, maybe two, to add depth in one specific area. That's a different proposition entirely.
Can you actually feed it?
Here's the bit I care most about.
We always look at fit from one direction: what does the software do, and does that match what we need? Almost nobody looks the other way. What does the software need from us?
A tier 1 system in the business it was designed for has departments feeding it. People whose actual job is entering and maintaining records, keeping master data current, keeping it complete. If you're a business that would genuinely be better off on Acumatica, that team is three people and they've all got other jobs. You do not have the resource to feed it. And an ERP you can't feed gives you the entire cost and a fraction of the benefit.
Nirav's response was fair, and it sharpened the point rather than blunting it. Data maintenance never stops — that's true whatever system you're on, and there's no such thing as set-and-forget. What changes is what the data is for. The newer systems let you take that data and do something with it: spot the gaps, find the blind spots, see where a division is quietly dying. The archaic data-entry role gets replaced by something closer to a data analyst.
His line, and we've been saying versions of it since episode one: data that sits on a shelf is like anything else in a grocery store. It expires. It has to be live and it has to be actionable almost from the moment you record it.
The folklore problem
Now the part that still winds me up.
During our NAV to Acumatica migration I sat in discovery sessions listening to people list things our old system couldn't do. And it did them. Standard functionality, one click deep in a setup screen. Nobody had looked.
It's easy to blame end users for not being curious enough, and I'll admit there's some of that. But it's not mostly their fault, because ERP training almost never comes from the vendor's own material. It's handed down, person to person, as staff turn over. And what gets handed down is the limitations. Someone was told the wrong thing in 2014 by someone who'd learned it wrong in 2011, and by now it's simply a thing everybody knows.
Nobody ever invents a feature that doesn't exist. Everybody remembers a constraint that got fixed three versions ago.
Emily's version of this was a QAD site where everyone hated the system, nobody trusted the data, and everything had migrated into Excel. There was nothing wrong with QAD. One of them even had a family member who was a QAD consultant, which prompted the reasonable question: isn't this supposed to be good? It was. It had just been over-customised and then abandoned.
Nirav's addition: 80% of spreadsheets contain errors, and once confidence goes, Excel becomes the crutch forever. Sometimes the barrier is genuinely the system — too many clicks, a VPN, an on-premise login that's painful from anywhere but a desk. Either way the ERP starts ageing out of the business.
And I hit it again last week with a customer barely a year into Acumatica. I suggested automating their sales order acknowledgements on a schedule — rather than printing to screen, typing in addresses and clicking send, let it fire every day at five. The response was that they can't, because the email function only sends to one recipient. It doesn't. You can put as many as you like in To, CC and BCC, and pick PDF, HTML or Excel. Somebody had just told them otherwise, and one year in, that's already settled fact.
That folklore compounds. It travels up the chain as "our people need all these things and our system can't do them", and someone looks at a tier 1 feature list and concludes the answer is a bigger ERP.
Do the utilisation audit
So here's the homework, and it takes an afternoon.
Get the list of features and modules you're licensed for. Go through it line by line and mark each one. Am I using this? Do I know what it does?
Two things happen. You'll stumble across things you didn't know you had — that's the folklore, in numbers. And you'll get an honest utilisation picture: I pay for this every year and I have never once opened it.
Then split what's left into three. Things we use. Things where, if we'd known, we could have binned a pile of manual workarounds. And things to kill.
Take that list to a tier 2 product and go through it again. It does that, that, that. It doesn't do this one — is there an ISV? Because nobody on earth uses 100% of every module. Even on the smallest Acumatica manufacturing edition, if you're not using engineering change orders you are still paying for them. The goal isn't zero waste. It's less of it.
Nirav's related warning: watch the five-year module plan. Customers get sold what year five looks like, get excited, and buy it in year one. Ask what you need to run the business next year, and be pleased that the rest is there when you grow into it.
If you do it, do it properly
Two caveats, and they're the ones I'd put in bold on the project plan.
It is still a full ERP migration. Do not think that because you're going somewhere smaller you can do it with fewer people. You'll end up with the same people doing more, and if you genuinely run it light, you're risking the go-live.
And you still don't get to skip discovery. "It'll be simpler, we won't need as much" is how these go wrong. You still need proper master data management, proper cleansing, proper decisions about what comes with you and what belongs in a read-only archive for retention. Slimmer doesn't mean better on its own. It's still a reset, and you should use it as one.
Also worth knowing: going down your own publisher's range isn't the shortcut it looks like. F&O to Business Central, JD Edwards to NetSuite — logical place to start, but Nirav's experience is that there's no clean path. Different database structures, different architectures, different strengths. His example is Dynamics GP, sunsetting in 2029, where the assumption is everyone slides across to Business Central. GP was strong in projects; BC is getting there but isn't a one-for-one. And I've watched businesses assume that even on-prem to cloud within the same product is a non-event, then discover they've lost direct SQL access and every Power BI and Jet report they own is broken.
So — should you?
It's not clear cut, and I'm not going to pretend it is.
But go and measure your utilisation. Print the list, mark every line, and be honest about it. Then go and look at what's actually on offer, because I think a lot of people would be surprised how much is now standard in the smaller products — the same way you'd be surprised getting into a new car after fifteen years and finding the thing you paid extra to have fitted is now just how cars come.
Emily's closing point deserves the last word, because it's the one nobody puts in a business case. With the big names, you are a very small fish in a very large ocean. She has genuinely struggled to get Oracle to process a renewal and take more of her money. With the smaller players you can go to a trade show, turn up at an event, and end up talking to someone reasonably senior who acts like your problem is a problem. You won't find that on a feature comparison. It still matters.
Bigger doesn't always equal better. It's how you use it.
Full episode is out now on Spotify, Apple Podcasts and YouTube. And if it turns out you do need to move, Nirav's team at AdCirrus do exactly this — he still hasn't paid me to say that, four seasons in.
