A cloud ERP migration moves the system your business runs on from servers you own to infrastructure or software you rent. There are four realistic routes: rehost the existing ERP on cloud servers, replatform it onto managed services, replace it with a SaaS ERP, or rebuild it as a cloud-native application. Each has a different cost, risk and payoff, so the route is the first decision, not the last.
Most guides treat "moving to the cloud" as one thing. In practice, lifting a twenty-year-old ERP onto a cloud virtual machine and replacing it with a subscription product are different projects with different teams, timelines and failure modes. This guide helps you pick the right route for each part of your estate, then plan the data, integration, security and cut-over work that every route shares.
If your current ERP is old, heavily customised or no longer supported, the route decision overlaps with modernisation, and our legacy software modernization team can assess the system before you commit to a direction.
What are the options for moving an on-premise ERP to the cloud?
The options range from changing nothing but the hosting to replacing the system outright. AWS's Prescriptive Guidance names seven migration strategies, the "7 Rs": retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. For an ERP, four of them carry most decisions.
| Route | What changes | Best when | Main risk |
|---|---|---|---|
| Rehost (lift and shift) | Hosting only; same software, same database | The ERP still fits the business and you need to leave a data centre or ageing hardware | You keep every limitation of the old system, now with a cloud bill |
| Replatform | Hosting plus managed services, e.g. a managed database, newer OS | You want less infrastructure work without rewriting the application | Vendor support for the new platform; licence terms for cloud hosting |
| Repurchase (move to SaaS ERP) | The product itself | Your processes are close to what a standard suite supports | Re-implementing processes, migrating data, losing custom features |
| Refactor or rebuild | The application architecture | The ERP is a competitive asset or no package fits | Largest scope; needs strong product ownership |
Retire and retain matter too. Some modules (an old reporting tool, a duplicate fixed asset register) can be retired rather than moved, and some components, such as software that talks to plant machinery, may stay on premise for now. AWS's own guidance notes that refactoring is the most complex strategy and, for large migrations, recommends moving first and modernising afterwards where possible. That advice suits infrastructure-heavy estates; for an ERP whose processes no longer fit, moving it unchanged can simply postpone the real decision.
How do you choose the right route?
Choose by asking whether the problem is the hosting or the software. If users are broadly happy and the trigger is a hardware refresh or a data-centre exit, rehost or replatform. If the trigger is that the system no longer fits how you work, a hosting move will not fix it.
Decision rules
- The vendor still supports your version and offers a cloud-hosting licence: replatform is usually the lowest-risk move.
- The vendor has ended support or the system runs on an unsupported OS or database: treat rehosting as a stopgap only. Plan a replacement or rebuild.
- Over half of your critical processes are workarounds or customisations: compare SaaS against custom. Our guide to cloud vs on-premise ERP covers the hosting trade-offs in more depth.
- Your edge is in the process itself (pricing rules, production scheduling, service delivery): a rebuild on cloud infrastructure, phased by module, keeps that edge.
- The system talks to machines, scales or local devices: keep those components close to the hardware and move the rest.
What has to happen to the data?
Every route needs a data plan, but the depth differs. A rehost copies the database as it is. A SaaS move or rebuild needs a full migration: profiling, cleansing, mapping, trial loads and reconciliation.
For the replace and rebuild routes, follow a staged plan like the one in our ERP data migration guide. The cloud-specific additions are:
- Transfer method and time. Measure how long a full database copy takes over your connection before you set a cut-over window. Large databases may need a seeded copy plus incremental sync.
- Where the data will live. Confirm the cloud region and whether any customer, employee or financial data has residency or transfer rules in the countries where you operate (for example the UK, the UAE and individual US states have their own data protection laws). Take advice rather than assuming.
- History and archives. Decide whether closed years move to the new system, a read-only archive in the cloud, or stay on a retained on-premise server until their retention period ends.
- Attachments. Scanned invoices, delivery notes and contracts are often stored on file shares outside the ERP database and are easy to forget.
What happens to integrations?
Integrations are where cloud migrations usually overrun. Anything that connected to the old ERP over the local network (direct database queries, shared folders, scheduled file drops, printers, barcode scanners, EDI gateways) must be found, then redesigned for the cloud.
Build an integration inventory before you choose a date. For each connection, record:
| Field | Example |
|---|---|
| System and owner | Warehouse scanners, operations manager |
| Direction and trigger | ERP to scanners, every 5 minutes |
| Method today | Direct SQL read of the stock table |
| Method after migration | REST API call over VPN or an integration service |
| Failure impact | Pickers cannot see stock; orders stall |
| Test case | Pick 10 orders end to end in the test environment |
Direct database access is the item most likely to break. SaaS ERPs do not let you query their database, and even a rehosted ERP may sit behind a network boundary. Our guide to system integration approaches compares API, file, event and middleware patterns.
What security and access changes should you plan for?
Moving to the cloud shifts some security work to the provider but not the accountability. You still own user access, data classification, backup policy and audit.
Security checklist
- Single sign-on and multi-factor authentication for every ERP user, including admin accounts
- Role-based access reviewed before migration, not copied blindly from the old system
- Network design: which offices, warehouses and devices connect, and how (VPN, private link, internet with allow lists)
- Encryption in transit and at rest, and who holds the keys
- Backup schedule, retention and a tested restore, not just a backup job that reports success
- Logging of logins, privilege changes and sensitive transactions such as supplier bank detail edits
- A shared responsibility table that says, line by line, what the provider covers and what you cover
- Exit terms: how you get a full copy of your data out, in what format, and how quickly
How should the cut-over work?
Cut over at the start of an accounting period, after at least two full rehearsals. Freeze changes in the old system, take the final copy or final migration load, reconcile, switch integrations, then open the new system to users.
An illustrative cut-over sequence for a mid-sized distributor moving to a replatformed ERP:
- Two weeks before: final rehearsal with timings; sign-off on the run book.
- Friday after close of business: freeze transactions in the old system.
- Friday night: final database copy and integration endpoint switch.
- Saturday: finance and operations reconcile trial balance, stock and open orders.
- Sunday: go or no-go decision against the agreed criteria; rollback stays possible until this point.
- Monday: users work in the new environment with floor support; old system read-only.
Define go or no-go criteria in advance and write them down: trial balance agrees to the old system, stock quantities and values agree by location, open orders and open invoices are complete, every integration has passed its test case, and key users have completed a scripted check of their daily tasks. If any criterion fails, the decision is no-go and the rollback plan runs. Agreeing this before the weekend removes the temptation to go live on hope at two in the morning.
Keep the old environment intact and read-only for an agreed period. Rollback should be a rehearsed procedure, not a hope. The ERP go-live checklist covers the readiness criteria in detail.
When is a cloud migration not the right move?
Cloud is not automatically cheaper or better. Hold off, or move only part of the estate, if:
- The ERP is about to be replaced anyway; migrating twice wastes budget.
- Sites have poor or unreliable connectivity and the business cannot run offline.
- Software licence terms forbid or heavily penalise cloud hosting.
- Equipment integrations depend on local network timing.
- Nobody owns the cloud environment after go-live. A cloud server nobody patches is no safer than an on-premise one.
How to start your cloud ERP migration
Start with an inventory, not a vendor shortlist. Prepare:
- A list of ERP modules in use, with the number of users and the business owner for each.
- The integration inventory described above.
- Database size, version and the age of your hardware and OS.
- The trigger for moving and the date it bites (hardware end-of-life, support expiry, data-centre lease).
- A short requirements brief; our software requirements brief template gives you a structure.
If the right route turns out to be a replatform or a phased rebuild, we can help with both. When the answer is a package, our ERP implementation services cover configuration, data and cut-over. When you want to discuss the project, we start by building 2 to 3 key modules as a free pilot before the full project, so you can judge the approach on working software.