How Long Does Cloud Migration Take? Phases, Waves and Timelines

A cloud migration takes anywhere from a few weeks to well over a year. Moving one application or a SaaS tool can finish in weeks. A data-centre exit is planned as a series of waves: AWS guidance puts the preparation stage of a large migration at 1–3 months and recommends keeping each wave within 6–10 weeks.

Key takeaways

• Duration is driven by scope (servers, applications, data), dependencies and the migration strategy per application, not by the cloud provider.
• AWS treats 300 or more servers as a large migration and puts the initialize stage before bulk migration at 1–3 months.
• AWS recommends keeping each migration wave within 6–10 weeks and overlapping waves to shorten the programme.
• Data transfer is simple arithmetic: 10 TB over a 1 Gbps link at 80% use takes about 28 hours; 100 TB takes about 12 days.
• Rehosting is the fastest path; refactoring belongs outside the migration waves because it can stretch any schedule.
• Budget time after cutover too: hypercare, cost tuning and decommissioning the old estate are part of the timeline.

How long does a cloud migration take, by project size?

Size sets the order of magnitude. The table below shows how scope translates into the work that fills the calendar. Treat it as a planning frame, then replace the durations with your own once discovery is done.

The 300-server threshold and the 1–3 month initialize stage come from the AWS Prescriptive Guidance for large migrations and its phase description. AWS states that the implement stage that follows "varies by project scope and strategy", which is the honest answer for any estimate made before discovery.

What are the phases of a cloud migration and how long does each take?

Most programmes follow the same three phases: assess, mobilize, and migrate and modernize. Only part of that is moving servers.

Assess: build the business case

You inventory applications and infrastructure, check organisational readiness and agree why you are moving. For a small estate this is a short workshop and a discovery scan. For a large one it includes a business case, a cost model and a first portfolio view. Our guide to what a cloud migration assessment covers lists the inputs.

Mobilize: prepare people and platform

Here you build the landing zone (accounts, network, identity, security baseline), run a deeper portfolio assessment and set the operating model. A pilot migration of a few representative workloads usually happens here. It tests the tooling and gives you real numbers for the rest of the plan.

Migrate and modernize: move in waves

AWS splits this phase into two stages. In the initialize stage (1–3 months for large migrations) you write runbooks and check that the landing zone and team can handle the scale. In the implement stage you migrate in batches called waves, measure each one and speed up the next.

How do migration waves set the overall timeline?

Waves are the main lever. The total length of the migrate phase is roughly the number of waves multiplied by the wave length, minus whatever you gain by running waves in parallel.

The AWS wave planning guidance says there is no predefined wave duration, but recommends keeping waves within 6 to 10 weeks. Work that needs more time, such as rewriting an application component, is better handled outside the waves. The same guidance describes what fills a wave:

• Design: confirm and approve the target design for each application.
• Cutover planning: write the runbook, including rollback.
• Pre-migration: provision accounts, set up tooling, start data replication.
• Cutover: stop the source, do the final sync, run business tests, hand over to operations.
• Hypercare: a support period after go-live; AWS gives "3 days" as an example.
• Wave closure: review metrics and lessons, then feed them into the next wave.

Overlapping waves is how large programmes shorten the calendar. AWS notes that deployment, validation and data sync fill the first half of a wave and cutover the second half, so the team that prepared wave 1 can start on wave 2 while wave 1 cuts over.

How long does the data transfer take?

Bandwidth is the one factor you can calculate on day one. Transfer time equals data volume divided by usable throughput. A 1 Gbps link that you can use at 80% moves roughly 0.36 TB per hour.

These are raw figures before compression, deduplication and protocol overhead, and they assume the link is not shared with production traffic. Two practical points follow. First, start bulk replication early in the wave and only sync changes at cutover, so the downtime window covers the delta, not the full copy. Second, check offline options early if the numbers look bad. AWS has closed Snowball Edge to new customers and points them to AWS DataSync, AWS Data Transfer Terminal or partner solutions instead, according to the AWS Snowball FAQ.

What makes a cloud migration take longer than planned?

Delays almost always come from things that were unknown when the estimate was made. The common ones:

• Hidden dependencies. Two systems that need low latency between them have to move together. Discovery tools show connections but not which ones are hard dependencies, so plan interviews with application owners.
• Strategy changes mid-wave. A rehost that turns into a refactor resets that application's schedule. Decide the strategy per application before the wave starts, using the 7 Rs of migration.
• Legacy software. Old operating systems, unsupported middleware and licences tied to hardware need workarounds or replacement.
• Business calendar. Month-end close, peak seasons and release freezes block cutover dates. Map them before you build the wave plan.
• Testing gaps. Without agreed acceptance tests, cutovers slip while teams debate whether the system works. Our cloud migration testing strategy covers what to test and when.
• Scope creep. Servers get added while you migrate. AWS recommends one source of truth for scope and a change-control step for every addition.

How can you shorten the timeline without adding risk?

• Migrate first, modernise second. AWS recommends this order for large migrations. Rehosting gets you out of the data centre; refactoring then happens on your own schedule.
• Run a pilot wave. Two or three representative applications give you real throughput and real problems before you commit to dates.
• Automate the repeatable parts. Replication agents, landing zone templates and runbooks turn each wave into a repeatable pattern, which AWS calls a migration factory.
• Retire before you move. Every server you decommission instead of migrating takes work out of the plan.
• Bring in experienced help for the first waves. A partner that has run the pattern before shortens the initialize stage, when runbooks and tooling are built.

What happens after cutover?

The migration is not finished when traffic switches. Plan for hypercare, rightsizing once you see real usage, tagging and cost reporting, and decommissioning the old hardware and contracts. Cost surprises are common when sizing is copied from on-premises servers, so read our cloud migration cost breakdown before you set the budget.

A real example: SilverRail's Nordic migration

SilverRail Technologies moved its Nordic branch onto AWS to merge it with its global organisation on one platform. Opsio ran the work in the same three phases described above: an assessment with a business case and target architecture, a mobilize phase with a pilot test migration, and a migrate phase. Data was moved with native PostgreSQL tools, and cutovers ran in tight service windows to limit customer impact. The SilverRail case study describes each phase.

How Opsio helps

Opsio is an AWS Advanced Tier partner with the AWS Migration Competency. We run the assessment, build the wave plan and landing zone, and carry out the cutovers through our AWS migration service. After go-live the same team can run the estate 24/7 under a managed service agreement.

Frequently asked questions

How long does cloud migration take for a small business?

A small business moving email, file storage and a few applications usually plans in weeks rather than months. The work is mostly identity setup, data copy and user communication. Add time if you have an old on-premises application that needs a replacement or a database that cannot be offline for long.

How long does an AWS migration take?

The provider matters less than the scope. For large AWS migrations (300 or more servers), AWS puts the initialize stage at 1–3 months and recommends waves of 6–10 weeks. The total depends on how many waves you need and how many you can run in parallel.

How long does it take to migrate a database to the cloud?

The copy itself is set by data volume and bandwidth: about 28 hours for 10 TB over a 1 Gbps link at 80% use. With ongoing replication, the downtime at cutover covers only the final changes. Engine changes, for example Oracle to PostgreSQL, add conversion and testing time.

Can you migrate in phases and keep some systems on-premises?

Yes. Most organisations run a hybrid estate for a period. Group systems with hard dependencies so they move together, and keep the rest on-premises until their wave. Network links between the two sides must be sized for the traffic that crosses them.

What is the biggest cause of migration delays?

Unknown dependencies and scope changes. A previously unseen dependency found close to cutover forces a wave to be re-planned. Good discovery data, application-owner interviews and a single scope list prevent most of these.

Related reading: How long is a PenTest valid for.