The short answer
Migrating from on-premise to AWS starts with automated discovery and dependency mapping, because the connections nobody documented are what break cutovers. Workloads are replicated continuously with AWS Application Migration Service, cut over in dependency-ordered waves, then right-sized against real utilisation. The operating model has to change too — capacity planning becomes cost management.
Key takeaways
- Dependency mapping matters more than server inventory
- Continuous replication turns cutover into a switch, not a copy
- Hardware refresh cycles disappear; cost management replaces them
- Network latency to remaining on-premise systems is the usual surprise
Part of our guide to AWS migration: a practical guide to getting it right.
Moving out of your own data centre is the most common migration and the one where the surprises cluster. Not because the technology is difficult, but because a data centre accumulates two decades of undocumented connections and nobody has a complete picture.
Discovery is about dependencies, not servers
An inventory of machines is easy to produce and not very useful. What you need is the traffic map: which systems talk to which, on what ports, how often, and whether the dependency is synchronous.
AWS Application Discovery Service, or an equivalent agent-based scan, will build most of this from observed network flow over two to four weeks. Two to four weeks matters — a shorter window misses month-end batch jobs, quarterly reporting and anything that only runs occasionally. Those are exactly the workloads that break after a cutover nobody thought would affect them.
Replication, not copying
AWS Application Migration Service replicates servers continuously into a staging area while the source keeps running. That changes the character of cutover completely: instead of copying terabytes during an outage window, you are switching to a replica that is already seconds behind.
Databases are the exception worth planning for. AWS DMS handles continuous replication with change data capture, but schema conversion, sequence values and any application-level assumptions about connection strings need testing well before the window.
The network is the constraint
The single most common surprise is latency to whatever stays on-premise. A workload that made two hundred small database calls per page was fine when both sides sat in the same rack. Split across a Direct Connect link with a few milliseconds of latency, the same page becomes unusable.
This is why dependency mapping matters more than server inventory: it tells you which systems must move together in the same wave. Splitting a chatty pair across the boundary is the classic way to make a technically successful migration feel like a failure.
Habits that stop working
Capacity planning becomes cost management. On-premise, over-provisioning was prudent — hardware was bought in three-year cycles and running out was worse than paying for headroom. In AWS the same instinct bills hourly, forever. This is the hardest cultural shift, and it is why the optimisation phase needs an owner.
Snowflake servers become a liability. A machine configured by hand over years cannot be rebuilt reliably. Migration is the natural moment to bring configuration into code, even for workloads you are only rehosting.
Backup and DR need rethinking, not lifting. Tape rotation and a standby rack do not translate. Define recovery objectives explicitly, implement them with automation, and run a real failover before sign-off. An untested DR plan is a document, not a capability.
A realistic sequence
- Two to four weeks of discovery with agents in place.
- Landing zone build in parallel — accounts, networking, identity, guardrails.
- Pilot wave: something low-risk, end to end, including a practised rollback.
- Dependency-ordered waves, each with a validation gate.
- Decommission on-premise only after a full business cycle has run in AWS.
That last point gets rushed under pressure to stop paying for two environments. Resist it until at least one month-end close has run cleanly in the new environment.
