Every migration programme eventually produces a spreadsheet with one row per application and a column headed "strategy". Too often that column fills up with the same word, because one answer is easier to plan, staff and report than many. In some programmes the word is "rehost", because the date is close. In others it is "refactor", because someone promised the board a cloud-native future.
Neither is a strategy. A strategy is a decision about each workload, made with the same method every time, that can produce different answers for different workloads. A sensible estate migration usually uses every treatment available: some applications are switched off, some stay where they are, some move as-is, some change a little, a few change a lot, and some are replaced with a product.
This part explains the treatments, why discovery has to come before any of them, and why the order of the waves matters as much as the treatment of each workload. It also includes an interactive worksheet you can use on your own estate.
Bushbuck Brands is fictional, and its systems and figures are illustrative. Bushbuck rehosted 46 applications in its first wave (Part 2). About 94 applications remain in its Johannesburg co-location facility, and the contract ends in June 2027. This part is about deciding what happens to each of them.
Seven treatments, several vocabularies
Migration frameworks name the options differently, and the count varies. AWS's prescriptive guidance uses seven "Rs": retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. Microsoft's Cloud Adoption Framework lists eight, splitting refactor (changing code) from rearchitect (changing the architecture), adding rebuild, and calling repurchase "replace". Google Cloud names six, including rehost ("lift and shift"), replatform ("lift and optimize") and refactor ("move and improve").
The vocabulary differs; the decisions do not. Here they are in plain terms.
| Treatment | Meaning | Use when |
|---|---|---|
| Retire | Remove the workload | It has no sufficient business value |
| Retain | Keep it where it is for now | Migration value is low or a constraint remains |
| Rehost | Move with minimal change | Speed and migration risk dominate |
| Relocate | Move a compatible platform or estate | The provider can host the same platform with little application change |
| Replatform | Adopt selected managed capabilities | Moderate change produces clear operational value |
| Refactor | Redesign material parts | Strategic value justifies deeper change |
| Repurchase | Replace with SaaS or another product | A commodity capability can be bought more effectively |
A few points that the table does not make on its own:
- Retire is the most underused treatment. Every estate contains applications that a handful of people use, that duplicate something else, or that nobody can explain. Retiring them removes licences, integrations, support work and attack surface at once. Part 7 returns to this.
- Retain is a decision, not a failure. Bushbuck's finance ERP is due for a major upgrade in 2028. Moving it to the cloud in 2027 and then upgrading it a year later would mean migrating it twice. It stays where it is, with a recorded constraint and a review date. Retain does not mean "leave in the co-location facility forever": Bushbuck's retained systems need a new home when the contract ends, which for most of them is a smaller, cheaper hosting arrangement.
- Relocate is specific. It means moving a whole platform, typically a virtualised estate, onto a provider-hosted service that runs the same platform, so that applications move without being touched. It depends entirely on what you run and what the provider offers. Bushbuck had no matching platform, so it did not apply.
- Repurchase is a comparison, not a reflex. Bushbuck's intranet moved into the Microsoft 365 subscription it was already paying for. That was easy. Replacing a core system with SaaS is a procurement and business-change project, not a migration task.
An inventory is not discovery
A treatment can only be as good as what is known about the workload. Most programmes start with an inventory: a list of servers, operating systems, sizes and owners, often produced by a scanning tool. That is necessary, and it is nowhere near enough.
Discovery means understanding each workload well enough to choose its treatment and its timing:
- Dependencies. What does it call, and what calls it? Which database, file share, identity service, scheduled job, integration or partner connection does it rely on?
- Transaction flows. How does a real business transaction, an order or a delivery, pass through it and its neighbours?
- Data ownership. Who owns the data it holds, and what classification and retention apply?
- Business criticality. What happens to the business, and to customers, if it is unavailable for an hour, a day or a week?
- Runtime demand. What is its real load profile: daily, monthly and seasonal?
- Release constraints. When can it change? Is there a vendor, a code freeze, a regulatory window or a peak season to avoid?
- Retirement plans. Is it already due to be replaced?
At Bushbuck, the inventory said there were 94 applications left. Discovery found that 11 of them shared a single pricing database, that two "applications" were the same reporting tool installed twice for different regions, and that the scanner integration in each distribution centre needed a local server because the handheld devices could not tolerate a round trip to a cloud region during a load-shedding-related network failure. None of that was in the inventory.
The workload treatment worksheet
The worksheet below applies the same method to each workload. For every row, set the business value and tick what is true. It suggests a treatment and explains why. The rules are deliberately simple and visible: the point is consistency, not an oracle. Override the suggestion when you know better, but record who owns the next decision and when it is due. You can download the result as a CSV file for your own planning.
The example rows are Bushbuck's. The warehouse management system and the trade ordering portal both come out as rehost, for different reasons: the first because its vendor limits change, the second because the date wins over its strategic value, with a refactor decision dated for 2027. Nightly route planning comes out as replatform, which Part 4 explores. The leave application is retired, the intranet repurchased, and the finance ERP retained because of its 2028 upgrade.
Try it
Workload treatment worksheet
One row per workload. Set its business value, tick what is true, and read the suggested treatment and why. The rules are simple on purpose; override the suggestion when you know better, but write down who owns the next decision and when it is due. The example rows are illustrative.
1 Retire · 1 Retain · 2 Rehost · 1 Replatform · 1 Repurchase
Relocate (moving a whole virtualised estate to a provider-hosted service that runs the same platform) is never suggested automatically: it depends on your platform and the provider's offer, so choose it by hand when it applies. Every rehost should carry an exit ticket: why it was rehosted, what waste was accepted, and the date of its first optimisation review.
Bushbuck ran its remaining 94 applications through the worksheet in a series of workshops with each business area, and then reviewed every suggestion by hand. The illustrative result: 15 retire, 11 retain, 9 repurchase, 33 rehost, 20 replatform and 6 refactor. Together with four duplicate reporting tools retired from the first wave after their 90-day reviews, that made 19 applications retired across the programme. Relocate did not appear at all, which is a perfectly normal outcome.
The workshops changed more decisions than the rules did. In several cases a business owner, asked "would anyone notice if this disappeared?", answered honestly that they would not. That conversation is worth more than any scoring model.
Sequence by dependency, not by server count
Once each workload has a treatment, the next question is the order. Programmes often plan waves by convenience: a fixed number of servers per weekend, or one business unit at a time. That is how workloads get stranded.
A stranded workload is one that has moved before the things it depends on, or has left behind the things that depend on it. It works, technically, but every request now crosses the WAN between the cloud and the old facility. It is slower than before, generates data-transfer charges on every call, and is harder to support than either end on its own.
Bushbuck learned this in wave 1. The trade ordering portal was moved early to meet the date. Its pricing database, shared with ten other applications, stayed in co-location. Every page the retailers loaded now waited on a round trip across the WAN.
For the remaining waves, Bushbuck grouped applications by dependency rather than by count:
- Wave 2, foundations: identity and directory services, and the integration layer that connects everything else.
- Wave 3, core services: the EDI order API used by supermarket chains, and the shared pricing database, which also brought the stranded portal's dependency across.
- Later waves: the applications that depend on those, grouped so that each group moves together with what it needs.
Dependency groups should also follow business recovery needs. Systems that must be recovered together in an outage should generally move together, so that a recovery test after the move tests a real configuration rather than a temporary split. The architecture concept of planned intermediate states, which the proposal-writing series calls bridge states, applies directly: each wave is a bridge state, and each one should be workable on its own, not just a step towards the end.
Consistency means the same method
One migration programme can, and usually should, use every treatment. Consistency does not mean forcing the same technical answer on every workload. It means using the same decision method for each one: the same questions, the same evidence, the same recorded owner and review date.
That also makes the programme defensible. When the financial director asks why the warehouse system was rehosted while the portal is being refactored, the answer is in the worksheet: different value, different constraints, same method.
Common mistakes
- One treatment for everything. A programme that rehosts or refactors everything has not made a decision about anything.
- Treating the inventory as discovery. Dependencies, flows, ownership and constraints are what decide treatment and timing.
- Planning waves by server count. Group by dependency and recovery needs, or strand workloads across the WAN.
- Forgetting to retire. Every application not migrated is one less to pay for, secure and support.
- Assuming retain means "do nothing". A retained workload needs a recorded constraint, a review date and, if its building is going away, somewhere to go.
- Letting the tool decide. Scoring rules support a conversation with the business owner; they do not replace it.
A decision you can defend
We will move Bushbuck's EDI order API and the shared pricing database together in wave 3, after identity and the integration layer in wave 2, because the trade ordering portal and ten other applications depend on that database and the portal is currently stranded across the WAN. We accept that wave 3 is larger than a server-count plan would make it. We will review the sequence if discovery finds a further dependency, and we will confirm the portal's page response times after cutover.
What to take from this part
The Rs are decisions, not slogans. Frameworks count them differently; the choices underneath are the same.
Discovery comes before treatment. Dependencies, flows, ownership, criticality, demand and constraints, not just a server list.
Use every treatment, with one method. Consistency is in the questions, not the answers.
Sequence by dependency. Moving a front end before its database creates a stranded workload.
Next in the series: Serverless is not automatically cheaper.
How CloudNala can help
We help organisations run discovery that goes beyond the inventory, facilitate treatment workshops with business owners, and plan migration waves around dependency groups and recovery needs. The aim is a treatment and an owner for every workload, recorded consistently, before the first server moves.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Request a Cloud Review or write to us at consult@cloudnala.co.za