How long does an AWS migration really take, and what to expect
The answer we hear most often when we ask how long a company expects its AWS migration to take is “two or three weeks”. The reality is almost always between 6 and 12 weeks — not because the work is hard, but because there are dependencies, approvals and tests that cannot be compressed without putting the operation at risk.
Why “two weeks” is almost never enough
An AWS migration is not moving files from one server to another. It means redesigning the target architecture, configuring the network (VPC, subnets, security groups), migrating data with continuous replication so no transactions are lost, validating that everything works in the new environment, and running a controlled cutover with a rollback plan in case something fails.
Each of those stages has its own timeline, and many of them depend on the company’s own team providing access, context or approvals that are not always available exactly when they are needed.
The real phases of a migration
Migration readiness assessment — 1 to 2 weeks
An inventory of what you have: servers, databases, dependencies between systems, average traffic, current SLAs. This is the phase that surfaces the surprises — the server nobody can explain but that “cannot be turned off”, the database with five dependent applications nobody documented, the software license that does not transfer to the cloud.
Target architecture design — 1 week
Deciding what goes where: which EC2 instances, what sizes, in which subnets, how the components connect, what provides high availability. Whoever makes technical decisions at the company has to approve this design before work continues. Without that approval, anything built may have to be redone.
Migration in waves — 2 to 6 weeks
Systems move one at a time, starting with the least critical — development environments or secondary systems — and ending with production. For databases we use AWS DMS with continuous replication: the source keeps running while the replica in AWS stays in sync, which brings the cutover window down to minutes instead of hours. The number of waves depends on complexity: a company with 3 applications may need 2 waves, one with 15 systems may need 6.
Cutover and validation — 1 week
The moment of the actual switch. The cutover runs inside an agreed maintenance window — typically a weekend or overnight — everything is validated on AWS, and the source environment stays available for 48 to 72 hours as a fallback. If something fails, you roll back. If everything works, the source is decommissioned.
Post-migration — 2 weeks
Intensive monitoring, alert tuning, the first cost optimizations, documentation and technical handover. This phase matters as much as the migration itself: many problems only appear during the first week of real production traffic on AWS.
What stretches a migration
In practice, these are the factors that cause most delays:
- Incomplete documentation: if nobody knows exactly what is running or how the systems connect, the assessment can take twice as long as planned.
- Third-party dependencies: vendors that need to update IPs in their firewalls, integrations with external systems that require acceptance testing, SSL certificates that have to be coordinated.
- Slow internal approvals: if every technical decision needs committee sign-off, the cycles stretch. Naming one clear technical decision-maker from the start speeds the project up significantly.
- Very large datasets: moving terabytes with continuous replication takes time. With databases over 1 TB, the initial sync period has to be planned well in advance.
How to prepare before you start
The smoothest migrations we have run had these three things ready before day one:
- An up-to-date inventory of systems, databases and dependencies — a spreadsheet is enough.
- A designated technical decision-maker with authority to approve architecture and maintenance windows without escalating to a committee.
- Clarity on the maintenance windows available — when downtime is possible without hurting the business.
Is downtime unavoidable?
For most web applications and relational databases, downtime can be cut to minutes using continuous replication with AWS DMS. The source keeps running while the replica in AWS updates in real time, and the cutover is just pointing DNS or the connection string at the new environment.
The cases where downtime is harder to avoid: legacy applications that cannot change their connection without a restart, large NoSQL databases with no native replication tooling, or tightly coupled architectures where everything has to move together. There, the strategy is to shrink the window with more careful preparation, not to eliminate it.
Considering a move to AWS?
We run a migration readiness assessment that takes 1 to 2 weeks. What you get is an inventory of your systems, a target architecture and a realistic timeline — before you commit resources.
Request a migration readiness assessment →