Moving your ERP from on-premises to the cloud
The question is rarely whether cloud is better in the abstract. It is whether the specific constraints of running your ERP on your own infrastructure have started to cost you more than moving would.
Six things usually signal that they have: a server refresh you do not want to fund, an upgrade quote that reads like a re-implementation, customisations nobody understands, reporting that has migrated into spreadsheets, licensing that stops people seeing their own numbers, and no practical access for people who are not at a desk.
One of those is not a reason to move. Three or four together usually is.
Work down the list
Which of these is true of you?
Tick the ones that apply. Nothing is stored and nothing is sent anywhere. One of these on its own is not a reason to move. Three or four together usually is.
What actually changes
Not a feature list. The differences people notice once the project is over.
Infrastructure stops being your problem
Hosting, backup, disaster recovery and the server refresh cycle move to the vendor. For most organisations that removes a capital cycle and a category of risk rather than saving money outright.
Updates arrive on a cadence instead of as projects
No more upgrade projects with their own budgets and business cases.
Access is no longer a function of where someone is sitting
Site, home, a customer's premises, a phone.
Reporting becomes something your team can do
The measure of success is whether your finance team can build and change a report without raising a job. If they cannot, nothing has really changed.
Consolidation runs from the system
For multi-entity groups this is often the single largest practical difference.
What is genuinely harder
Honesty here converts better than reassurance, and anyone who has been through a system change before will be looking for it.
Update timing, environment configuration, and direct database access. For organisations with a capable internal IT function that is a real adjustment, and for some it is the reason not to move.
Anything reading or writing straight into your ERP database, including reporting tools pointed at the back end, has to be redesigned. These are frequently built by IT rather than by the ERP partner, which is why they are the last thing anyone thinks to look for and the first thing to break.
Some of it should not, and the exercise of finding out which is worth doing regardless.
At data sign-off and at testing. Both land on finance, and both need planning for rather than absorbing.
Capital spending on infrastructure and periodic upgrade projects becomes an operating subscription. Whether that is better depends on your position, and it is worth modelling over five years rather than comparing year one.
What to do first
Two exercises that will tell you more than a demonstration will.
Licence, maintenance, infrastructure, hosting, external IT, upgrade projects annualised, and the staff time going into manual work and spreadsheet reporting. Most organisations have never totalled it, and it is the number missing from most ERP business cases. It is also the number that decides whether the answer is yes.
Customisations, integrations and reports, with who uses each and whether anyone still understands it. The volume is the single largest variable in what a migration costs, and most organisations find a meaningful proportion of it does not need to move at all.
Both are free tools in our ERP Migration Toolkit, alongside a requirements template, a demo question bank, business case templates and a go-live checklist. All of them are written to be useful whichever system you choose.
Avanza Solutions is a MYOB Acumatica implementation partner based in New Zealand and part of Verde Group. The tools in our migration toolkit are written to be useful whichever system you choose, including staying on the one you have.
The ones people ask first
When the constraints of running it yourself start costing more than moving would. The usual signals are a server refresh you do not want to fund, an upgrade quote that reads like a re-implementation, customisations nobody understands, reporting that has moved into spreadsheets, licensing that stops people seeing their own numbers, and no practical access for people away from a desk.
One of these is not a reason. Three or four together usually is.
Not necessarily, and it is the wrong question. The cost profile changes shape rather than simply reducing: capital spending on infrastructure and periodic upgrade projects becomes an operating subscription.
Whether the total is lower depends on your infrastructure position, your upgrade history and how much staff time your current setup consumes. Model it over five years rather than comparing year one.
They sort into four groups: retired because nothing depends on them any more, replaced by standard functionality that did not exist when they were built, redesigned because the implementation method cannot survive the move, and rebuilt where they encode something genuinely specific to your business.
Anything connecting directly to your database always needs redesigning.
You give up some control over update timing, environment configuration and direct database access. Direct database integrations have to be redesigned. Some customisation will not come across in its current form.
For an organisation with a capable internal IT function these are real trade-offs, and for some they are a reason not to move.
It is the right moment to ask the question, because you are about to commit capital either way. Work out what the full replacement costs, including the operating system and database licensing, backup and the internal time to build and maintain it, then compare that with a five year subscription position.
Doing the two decisions together is cheaper than doing them six months apart.