Almost every finance and IT leader who spent last year keeping an on-premise ERP reachable from four hundred kitchens has arrived in January with the same item on the plan: move it to the cloud. The budget conversation is easier than it has ever been. The decision underneath it is not, because "move to the cloud" describes three fundamentally different projects with different costs, different timelines and different answers to the only question that matters in the long run — who ends up owning your accumulated process debt, and when do you pay for it. Getting the pattern right is worth more than getting the vendor right.
The three patterns, defined so they actually differ
Rehost. The same software, the same version, the same configuration, running on infrastructure somebody else owns. Nothing about the application changes. This is a data centre exit, not a transformation, and it should be described as one. Replatform. The same product line, moved to the vendor's managed or hosted edition. Your configuration largely survives; your release calendar does not. You gain a maintained platform and inherit an upgrade cadence you no longer control. Rebuild. A new implementation on a software-as-a-service product. New data model, new process decisions, new integrations, and a programme measured in quarters rather than weekends. There is a fourth pattern that organisations perform without naming it: keep the transactional core where it is and move everything adjacent — expenses, procurement, planning, reporting, analytics — to cloud services around it. Done deliberately this is a sound strategy. Done by accident, it produces a hollow core surrounded by fourteen integrations that nobody owns.
| Pattern | What changes | What still needs an owner |
|---|---|---|
| Rehost | Infrastructure location; the application largely remains | Existing process, customisation and integration debt |
| Replatform | Managed edition and upgrade arrangements | Regression testing and release obligations |
| Rebuild | Data model, processes and integrations | Business decisions, retained history and changed workflows |
| Adjacent services | Selected functions around the transactional core | Each boundary and integration |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
The test that decides the pattern
Forget infrastructure for a moment. Ask one question: can you justify your customisations to somebody who did not build them? Run the inventory. List every modification, every custom report, every interface, every bolt-on. Against each, name the business owner and pull the usage data for the last twelve months. The pattern that follows is consistent across almost every estate I have seen: roughly a fifth of the modifications are genuinely load-bearing and encode something real about how the business competes or complies. Another third are dead — nobody has run them in a year. The remainder are habits, built because someone senior in 2014 wanted a screen to look a particular way. If you cannot do that inventory, you cannot rebuild, because you will either lose something that matters or faithfully reproduce all of it in a new system and arrive with the same problem on a subscription. If you can do it, the choice usually becomes obvious. A high proportion of load-bearing customisation argues for replatform. A high proportion of dead and habitual customisation is the strongest available case for rebuild, because the value is in discarding it.
What each pattern actually buys
Be precise about the benefit, because the business case is where these projects acquire their fictions. Rehosting buys resilience, remote accessibility and an exit from the hardware refresh cycle. It does not meaningfully reduce cost. Compute was never the expensive part; licences, maintenance, integration and people are. A rehost that is sold internally as a saving will be judged a failure in year two. Replatforming buys a maintained platform and a supported upgrade path, and it imposes discipline that most organisations need. The cost is control over timing. Two to four releases a year arrive whether or not your team has capacity, and regression testing becomes a standing obligation rather than a project activity. Budget test automation from the start, or you will pass the first upgrade, struggle through the second and fail the third. Rebuilding buys a clean data model, current functionality, and the chance to retire a decade of accumulated exception handling. It costs eighteen to thirty months, a material amount of senior attention, and the goodwill of everyone whose workflow changes. It is the right answer more often than conservative IT functions admit and far less often than software vendors suggest.
The part everyone underestimates: history
The technical work in every one of these patterns concentrates in data, and the decision that drives the effort is how much history moves. The defensible rule is to migrate open items and balances, not transactional history. Bring across trial balance, open receivables and payables, open orders, inventory positions, fixed asset registers, and enough master data to transact. Leave the ten years of posted detail in a queryable archive — a read-only copy of the old database, or an extract into a reporting store — with a documented retention period and a named owner. The objection arrives immediately: we need comparatives, and the auditors will ask. They will, and an archive answers them. What the auditors do not require is that five-year-old journal detail be live in a new system, carrying a data model it was never designed for. Every programme that insists on full history migration adds months, and a meaningful share of them fail their first month-end because of it.
Pick a pattern per module, not per company
The most common strategic error is treating this as one decision. Finance, procurement and inventory may rebuild cleanly. Payroll may be immovable for statutory reasons. Manufacturing execution may be tied to equipment on the floor. A mature answer looks like a map — module by module, pattern by pattern, with the integration points named and an owner for each — not a single arrow pointing at a logo. That map is also the honest way to explain the timeline. A split estate is not a failure of ambition; it is the shape almost every successful programme actually takes.
Practical Guidance for Migration Pattern Assessment
- Inventory customisations with a named owner and twelve months of usage data. Nothing else in the assessment matters as much, and it takes about three weeks.
- Write the benefit sentence before choosing the pattern. If the sentence is "reduce cost", rehosting will not deliver it and you should know that now.
- Decide the history rule early: balances and open items migrate, detail goes to a queryable archive. Put the retention period in writing.
- Cost the upgrade cadence, not just the migration. Regression testing two to four times a year is a permanent operating cost; fund the automation with the project.
- Map the pattern per module and name the integration owners. A split estate planned is cheap; a split estate discovered is expensive.
- Confirm which edition is available in the jurisdiction you need before shortlisting. Availability, not capability, eliminates more options here than anything else.
- Make sure you hold the tenancy, the subscription and the configuration exports. If the partner holds them, you have outsourced your exit.
- Reserve a quarter of the budget for process work, not software. The organisations that get value from a rebuild spend it on decisions, not configuration.
The Regional Angle
Three regional realities bind the pattern choice more tightly here than the vendor's decision tree suggests. The first is that availability decides the option set. Regulated sectors in this region — banking, insurance, health, and anything serving government — are working to hosting rules that specify where data sits and, increasingly, who may administer it. Local infrastructure regions now exist and more have been announced, which is genuine progress, but the software-as-a-service edition of an ERP is not deployed in every region its vendor operates. It is entirely possible to be told that the platform is available locally and then discover that the specific edition, module or data residency commitment you need is served from Europe or Asia. Establish that before the shortlist, in writing from the vendor rather than the reseller, because it removes options faster than any technical assessment will. The second is that payroll is usually the module that cannot move, and it is worth understanding why before the programme promises otherwise. Gulf payroll is not a variation on a standard theme. It produces wage protection files in bank-specific formats, social insurance contribution submissions with their own calculation rules and file layouts for nationals, end-of-service gratuity accruals that depend on service length and termination reason, and nationalisation ratio reporting that has to reconcile with the labour authority's own record of your workforce. A cloud payroll product that does not produce the contribution file for the country you operate in is not a payroll product for that country, regardless of how well it handles everything else. Plan for payroll to stay where it is, or to move to a specialist local product, and design the interface deliberately rather than treating it as a gap to be closed later. The third is scope arithmetic. Groups in this region routinely operate eight, twenty or forty legal entities across mainland jurisdictions, free zones and neighbouring countries, many of which have been running inside a single old system on a single chart of accounts because that was what the original implementer could deliver. Subscription products are frequently priced and scoped by legal entity, and a rebuild forces every one of those entities to be modelled properly for the first time. That is a genuine benefit — it is also the reason regional rebuild programmes come in at two or three times the indicative price. Count the entities, count the currencies, count the statutory reporting obligations, and get the number in front of the board before anybody signs.
The objection worth taking seriously
The sharpest objection is that this taxonomy is consultant packaging. Real organisations do not sit down and choose between three clean patterns. They are pushed by an end-of-maintenance date, a vendor incentive that expires at quarter end, a licence audit, a hardware refresh they cannot fund, or an acquisition that has to be consolidated. The pattern gets decided by the vendor's roadmap and commercial terms, and the assessment is decoration applied afterwards to justify a choice that was already structurally determined. That is largely true, and anyone who has watched a maintenance deadline drive a five-year architecture decision knows it. What survives the objection is narrower but still worth the effort. Even when the direction is forced, the assessment determines how much you pay for it, how much control you keep, and what you throw away on the way. The organisations that migrate well under vendor pressure are the ones that already know which customisations are load-bearing, which history needs to move, and which modules cannot travel. They negotiate from a position of knowledge, and they spend the forced budget on the process work rather than on faithfully rebuilding 2014. The ones that migrate badly discover all of this during the programme, at consultancy day rates, in the middle of a year-end.
Common Questions
Is rehosting ever the right answer?
Yes — when the application has a defined remaining life, when a data centre contract or hardware refresh is forcing a decision, or when the organisation is mid-acquisition and genuinely should not be re-architecting. Just do not describe it as transformation or promise savings from it.
How long should a mid-market rebuild take?
For a single-country, moderate-complexity operation, nine to fifteen months to first go-live is realistic. Multi-entity, multi-country groups should plan in waves and expect the whole programme to run beyond two years.
What is the single most common cause of failure?
No empowered owner. Somebody has to be able to say no to a customisation request from a senior manager, and that authority has to be visible. Where it is absent, the new system converges on the old one within eighteen months.
What should we expect over the next twelve months?
Expect the major vendors to sharpen their commercial packaging for cloud moves this year — bundles combining licence conversion, migration credits and hosting, tied to end-of-maintenance dates — and read the fine print on what happens when the incentive period ends. Expect implementation partner capacity, not software availability, to become the binding constraint by mid-year, as everybody who deferred a decision in 2020 tries to start in the same quarter. Expect more regional data residency commitments to be announced than delivered. And expect the phrase "clean core" to do a great deal of work in vendor material, which is simply the industry rediscovering that the customisations were always the problem.
Migration Pattern Assessment — we inventory what you actually use, test which modules can move, and give you a pattern per module with the cost and cutover consequences written down before you commit.