Business Challenge
The discovery report lands: 340 servers, a data centre lease expiring in fourteen months, and a column headed Migration strategy. Somebody has filled it in. Nearly every row says rehost.
Nobody sat down and chose rehost 300 times. Rehost is what the column defaults to when the alternative is a conversation nobody has the data for. Retiring an application means finding an owner willing to say it is finished. Replatforming means understanding what it does. Rehost requires neither. It is the only strategy that is never wrong enough to stop the programme — and that is precisely the problem, because the servers it swallows arrive in the new account with their costs intact and their reason for existing unexamined.
AWS names seven: retire, retain, rehost, relocate, repurchase, replatform and refactor. For large migrations AWS explicitly narrows the field, recommending rehost, replatform, relocate and retire — and advising against refactoring during the migration at all, because modernising while moving is the most complex option and hard to manage across a large estate. Its guidance is to move first and modernise afterwards.
That leaves four realistic choices, and the interesting split is not between the three that move an application. It is between the three that move it and the one that does not.
Retirement usually gets argued as a judgement call. It is not: AWS gives numbers. Applications averaging under 5% CPU and memory are what it calls zombie applications. Those between 5% and 20% over a 90-day period are idle. Both are named retirement candidates, and both are measurable from the same utilisation data the discovery tooling is already collecting for sizing.
The same guidance adds a second signal that costs nothing to check: no inbound connection to the application in the last 90 days. An estate of 340 servers will have a meaningful number that satisfy both, and every one of them is currently marked rehost.
Almost every write-up of the 7 Rs points at AWS Application Discovery Service for the dependency and utilisation data the decision depends on. As of 7 November 2025 it stopped accepting new customers. Existing projects continue; new ones start on AWS Transform, which AWS positions as carrying the same discovery and assessment capability with agent-based and agentless collectors, dependency mapping and wave planning.
It is a small detail with a large consequence for a plan written this year: a runbook that opens with “deploy the ADS agent” cannot be followed by a team starting now.
The comforting story is that anything moved wrongly can be cleaned up later. It rarely is. After cutover the application has an EC2 instance, an EBS volume, a backup policy, a patch schedule and a line in a CMDB. It looks exactly like the applications that matter. The evidence that it was idle lived in the on-premises discovery data, and that data set is usually retired along with the data centre.
The window in which retirement is cheap and provable is the migration itself. It does not reopen.
Architecture
Sequence the decision, do not assign it
The failure in the 340-row spreadsheet is not that rehost is wrong. It is that a strategy was written next to every application before any evidence existed to choose one. The strategies are not seven equal options to be picked from a dropdown; they are the output of two questions asked in order.
First: does this application need to exist at all? That is answered with utilisation data and connection data, not with opinion. Applications under the zombie and idle thresholds go into a retirement candidate list before any target architecture is discussed. Everything else proceeds.
Second, and only then: what shape should it take on the other side? Rehost, relocate, replatform or repurchase — a question about the target, asked only about applications that survived the first question.
Reversing that order is what produces an inventory of rehosts. Once a target has been written down, retirement stops looking like a decision and starts looking like a change request against a plan.
Proving a retirement rather than asserting one
Low utilisation makes an application a candidate. It does not make it safe to switch off, because a server can be almost idle and still be the thing one nightly job depends on. AWS's guidance here is a sequence, and the useful part is that each step is cheap and reversible.
Dependency data comes first: inbound and outbound connections observed on the server, not the architecture diagram. AWS is blunt about why — diagrams and institutional knowledge are “easily outdated or incomplete”, and dependencies form without anyone recording them, often during an incident. Most of what shows up will be monitoring agents and bastion hosts and can be dismissed; what matters is any connection from an application that is itself in scope to migrate.
Then the controlled stop, which is the step that turns an argument into an observation. Block the traffic with a host firewall, pause the virtual machine, or stop the service, and watch what breaks. It simulates retirement without performing it, and the firewall rule comes back out if something screams. The duration has to suit the workload: a week proves nothing about a job that runs monthly.
If the controlled stop is inconclusive and the lease is still expiring, there is a middle path AWS names explicitly — rehost it, then snapshot the EBS volumes and terminate the instance. The application is switched off but recoverable for as long as the snapshot is kept, which lets the retirement question stay open past the cutover date instead of being resolved by the deadline. Test the restore before terminating anything.
The patterns underneath the estate
Assigning strategies one application at a time is also what makes the exercise feel impossible at 340 rows. AWS's own figure is that typically twenty to fifty percent of an enterprise application portfolio consists of repeated patterns — the same three-tier Windows application, the same SQL Server pair, the same static site — which a migration factory approach can move as a class rather than individually.
That reframes the work. The task is not 340 decisions. It is a retirement pass over the whole estate, a handful of patterns covering a third of what remains, and genuine case-by-case attention for the rest.
Why This Architecture Holds Up
It puts the cheapest decision first. Retiring an application removes every downstream cost at once: no instance, no volume, no licence, no backup, no patching, no runbook and no one carrying a pager for it. No amount of right-sizing after the fact matches simply not moving it. AWS makes the operational version of the same point — retiring servers early in a migration means the teams who patch and support them have fewer to carry while the migration is running.
It replaces opinion with two measurements. Utilisation thresholds and observed connections are both available from the same discovery pass that sizes the target instances. Nothing extra needs to be bought or built; the data is already being collected to answer a different question.
It is reversible at every step. A retirement candidate can rejoin a later wave. A controlled stop can be undone with a firewall rule. A terminated instance can be rebuilt from a snapshot. The only irreversible step is the last one, and by then it has been tested three times.
And it survives the deadline. Migration programmes are usually driven by a lease or a contract, which is exactly the pressure that turns every ambiguous decision into a rehost. Starting retirement early is what stops the deadline from making the decision, because the applications that could not be resolved in time are a small remainder rather than the whole estate.
Key Architecture Decisions
| Situation | Strategy | Because |
|---|---|---|
| Under 5% CPU and memory, no inbound connections for 90 days | Retire, after a controlled stop | AWS's own zombie threshold. Removes every downstream cost at once rather than relocating it. |
| 5–20% utilisation over 90 days, owner unreachable | Retirement candidate, not a decision yet | Idle by AWS's definition. Cheap to investigate now, impossible to revisit after cutover. |
| Specialised hardware, data residency, or a SaaS version due next year | Retain | Deliberately not moving is a strategy. Rehosting it anyway buys a second migration later. |
| Whole VMware estate, lease expiring, no appetite to touch applications | Relocate | Moves the platform rather than each application. Fastest path, architecture unchanged. |
| Application survives triage, target should look like the source | Rehost | The correct default once it has earned the place. Optimising is easier after the move. |
| Self-managed database or an OS at end of support | Replatform | Managed service or a supported OS at cutover, without redesigning the application. |
| Commodity function with a credible SaaS equivalent | Repurchase | Removes the infrastructure entirely. Budget for data migration and identity integration. |
| Monolith blocking delivery, mainframe at its limits | Refactor — but after the migration | AWS advises against refactoring during a large migration. Move it, then modernise. |
Closing Thought
The 7 Rs are usually taught as a menu, which makes the interesting question “which R is this?”. In practice the estate answers that question for you most of the time: an application that survives triage and has no reason to change shape is a rehost, and there is nothing wrong with that.
The question worth defending is the one asked before the menu. Not which R, but does this need to move at all — asked while the utilisation data still exists, while the source environment is still running, and while switching something off is a firewall rule rather than a project.
A migration is the last time anyone will look closely at every application in the estate. Spending that attention on choosing between four flavours of “move it”, and none of it on whether to move it, is how a data centre's dead weight gets a second decade — this time billed hourly.
Migration — discovery and dependency mapping before wave planning. What the agentless and agent-based collectors actually see, why an application's dependency graph is the thing that decides wave order rather than its size or owner, and how a wave plan built from a CMDB rather than from observed traffic fails on the first cutover weekend.
Comments