Discovery comes before strategy, not after
The most common migration failure isn’t a bad technology choice — it’s starting wave planning before discovery is actually complete. You cannot sequence waves, assess the 7 Rs (AWS’s name for the seven strategies: retire, retain, rehost, relocate, repurchase, replatform, refactor/re-architect — see About the migration strategies, AWS Prescriptive Guidance), or estimate risk for a workload you’ve only partially mapped.
Discovery needs to answer, per application:
- What talks to what — not just the obvious app-to-database edges, but the batch job that pulls from a shared file share at 2 AM, the reporting tool with a hard-coded JDBC connection string, the monitoring agent phoning home to an on-prem collector.
- What it depends on that isn’t a server — licensing servers, hardware dongles, on-prem Active Directory, a physical appliance (HSM, specialized network gear) with no cloud equivalent.
- Actual utilization, not provisioned capacity. The on-prem VM sized for a peak that happens twice a year is not the sizing input for its EC2 replacement — use real utilization data (CPU, memory, IOPS, network) over a representative period, ideally including the peak.
- Data gravity — how much data, how it moves, and what reads/writes it today. A 40 TB file share with daily deltas is a different migration problem than a 40 TB share that’s rewritten nightly.
Check which AWS tool you can actually use before you plan around one: AWS Application Discovery Service “is no longer open to new customers,” and AWS directs new customers to AWS Transform for equivalent capability (AWS Application Discovery Service, AWS docs). If you have an existing ADS footprint, its own documentation makes an important distinction worth carrying into any replacement: the agentless collector gathers configuration and utilization data but “cannot ‘look inside’ each of the VMs, and as such, cannot figure out what processes are running on each VM nor what network connections exist” — only the agent-based collector returns running processes, and only it exports time-series utilization rather than a latest snapshot. If your dependency map came from an agentless scan alone, it is a map of machines, not of calls.
Automated discovery tooling gets you the topology map. It does not get you the tribal knowledge — the person who knows “don’t touch that cron job, it feeds payroll” rarely shows up in a dependency scan. Budget real time for interviews with whoever currently operates each system.
The 7 Rs, assessed honestly
| R | What it means | Effort | When it’s actually right |
|---|---|---|---|
| Rehost (lift-and-shift) | Move the VM/workload as-is onto EC2 | Lowest | Default for most workloads under time pressure, or where the app has no active development investment to justify a rewrite |
| Replatform | Rehost with targeted swaps — self-managed DB to RDS, VM-hosted queue to SQS | Low-medium | When a managed service removes real operational burden (patching, backup, failover) without touching application code |
| Repurchase | Replace with a SaaS or different COTS product | Variable, often low engineering effort but real change-management effort | Aging COTS with a SaaS equivalent already in the market; often a business decision more than a technical one |
| Refactor/Re-architect | Redesign for cloud-native patterns | Highest | Workloads with real, ongoing scaling or agility needs the current architecture can’t meet — not “because cloud-native is best practice” |
| Relocate | Transfer many servers comprising one or more applications at once from an on-premises platform to a cloud version of the same platform, with no new hardware, no application rewrite and no change to existing operations. AWS also applies the term to moving instances or objects to a different VPC, Region or account | Low | Large hypervisor-based estates where you need off-prem fast and aren’t ready to touch the stack itself yet. Confirm the specific target platform is still offered and how it is now commercially delivered before planning around it — this is the one R whose available landing options have changed most |
| Retain | Leave it in the source environment, possibly to migrate later | None (for now) | Data-residency or compliance constraints, unresolved physical dependencies (specialised hardware with no cloud equivalent), recently-refreshed systems, workloads awaiting a vendor’s SaaS release, and mainframe/midrange/non-x86 Unix estates that need their own assessment |
| Retire | Decommission | None | Verify before you spend migration budget. AWS’s documented screening heuristics are usefully concrete: zombie applications averaging under 5% CPU and memory, idle applications averaging 5–20% over a 90-day period, and applications with no inbound connection for the last 90 days |
The honest part most migration decks skip: most workloads should be rehost or replatform, and that’s a correct decision, not a cop-out. This is also AWS’s own position, not a contrarian one. Its prescriptive guidance names “rehost, replatform, relocate, and retire” as the common strategies for large migrations and states that “refactor is not recommended for large migrations because it involves modernizing the application during the migration… Instead, we recommend rehosting, relocating, or replatforming the application and then modernizing the application after the migration is complete” (About the migration strategies, AWS Prescriptive Guidance). Refactoring everything first is how a 6-month migration becomes an 18-month one, with most of that extra time spent on applications that didn’t need the investment.
Retire is underused. Every discovery engagement turns up systems nobody remembers the purpose of. Confirming “nobody uses this, decommission it” is the cheapest possible migration outcome for that workload — cheaper than rehosting it and discovering the same thing a year later with an extra year of AWS spend attached. The utilization and connection data your discovery tool already collects is enough to produce the candidate list; the hard part is getting someone to sign off on the deletion.
Wave planning: sequence by dependency, not by convenience
A wave groups workloads migrated together, usually over a single cutover window. Sequence waves by dependency direction, not by which team is most enthusiastic or which app is easiest:
- Migrate shared/upstream dependencies before what depends on them — a shared auth service, a central database, a message broker — not after.
- Keep tightly coupled applications (synchronous, latency-sensitive calls between them) in the same wave. Splitting a chatty pair across waves means one half talks to the other across the migration boundary for the whole gap between waves — see the latency problem below.
- Put genuinely independent workloads in early waves to validate your migration tooling and runbook against lower-risk targets before you touch anything business-critical.
- Build in a stabilization period between waves — don’t start wave 3 the day wave 2 cuts over. You want the previous wave’s incidents to surface and get fixed while attention is still on them.
What actually breaks during migration
These are the failure modes that show up in practice, not in the planning deck:
- Licensing. Per-core or per-socket licensing (some commercial databases, some enterprise software) often doesn’t map cleanly to EC2’s vCPU model, and license servers pinned to on-prem MAC addresses or dongles can refuse to activate post-migration. Confirm license portability and activation mechanics before migration, not during the cutover window.
- Latency between migrated and un-migrated tiers. The classic mistake: migrate the app tier to AWS, leave the database on-prem (or vice versa) “temporarily,” and discover the app makes dozens of synchronous queries per page load across a WAN link whose round-trip is orders of magnitude worse than the LAN it was written against. The arithmetic is the whole problem: query count multiplied by added round-trip latency, and neither factor was in the plan. What was imperceptible on a LAN becomes a visibly slow application. If a tier split across the migration boundary is unavoidable for a phase, measure actual round-trip latency between sites beforehand and load-test the split configuration — don’t assume it’ll be fine.
- DNS and TTL. Cutover usually means repointing DNS. If the existing records have long TTLs (hours, sometimes days, inherited from a config nobody revisited), your “5-minute cutover window” doesn’t actually complete for your slowest-to-refresh clients until the old TTL expires. Lower TTLs well in advance of cutover — ideally days, not hours — so the actual cutover is fast when it matters.
- Data gravity. Large, actively-written datasets resist quick migration. A one-time bulk transfer (DataSync over the network, a physical transfer appliance, or a simple copy — confirm which offline transfer options are currently available, as the Snow family’s lineup has changed) captures a point in time; anything still writing to the source after that point needs a sync mechanism (continuous replication, CDC) bridging the gap until final cutover, or you lose data written during the gap.
- Hard-coded IPs. Despite everyone knowing better, hard-coded IP addresses in config files, firewall rules, allowlists, and application code are endemic in older estates. Discovery should explicitly grep for IP literals in configuration and code, not just rely on documented architecture — the documented architecture is usually out of date precisely where this problem lives.
Cutover and rollback: plan the rollback before you need it
Every cutover plan should include an explicit rollback trigger and procedure, written before the cutover window, not improvised during it. Define in advance:
- The specific, measurable condition that triggers a rollback decision (error rate threshold, specific functional test failing, a go/no-go checkpoint at a fixed time into the window) — not “we’ll know it if we see it.”
- Who has authority to call the rollback, and that they’re reachable and paying attention during the window.
- Whether rollback is actually possible at each stage — past a certain point (e.g., once production writes have gone to the new database and the old one has drifted), rollback stops being a revert and becomes its own migration. Know exactly where that point is before you cross it.
- A rehearsal. If you’ve never actually executed the rollback procedure, you don’t have a rollback procedure — you have a document describing one. Dry-run it in a non-production wave if at all possible.
How to decide a workload is not ready
Say no to migrating a workload in the current wave when any of these are true, and don’t let schedule pressure override the assessment:
- Dependencies on systems that haven’t been discovered or confirmed stable (you’re still finding new integration points during planning, not before it)
- No validated rollback path and the workload is business-critical enough that a failed cutover with no way back is unacceptable
- Licensing portability unconfirmed for commercial software with per-core/per-socket terms
- The team that operates it isn’t available during the planned cutover window — migrating a system nobody who understands it can supervise is how small issues become outages
- Latency-sensitive coupling to a system staying on-prem for multiple more waves, with no interim mitigation tested
None of these are permanent blockers — they’re reasons to move the workload to a later wave while the specific gap gets closed, which is a far better outcome than discovering the gap mid-cutover.