The short answer
An AWS or Azure cloud migration can take anywhere from a few weeks to well over a year. A standalone internal application with modest data and few dependencies may be ready to move in six to twelve weeks. A critical estate with shared identity, databases, legacy integrations, strict availability targets, and regulatory controls is usually a multi-wave programme measured in months.
The cloud provider is rarely the main determinant. AWS and Azure both offer migration, networking, security, data, and platform services that can support the same broad patterns. What changes the schedule is the amount of uncertainty in the estate, the condition of the target platform, and the organisation's ability to make decisions when the original plan meets production reality.
The useful question is not "How long does migration take?" It is: how long will it take to make each workload safe to move, execute the cutover, and operate it confidently afterwards?
That distinction changes how a programme is planned, funded, and governed.
Practical planning ranges
These are planning ranges rather than promises. They give leaders a way to discuss scope before a detailed assessment.
| Migration scope | Typical elapsed time | What determines the range |
|---|---|---|
| Standalone, low-risk application | 6-12 weeks | Dependencies, data volume, testing, target readiness |
| First migration wave of related workloads | 3-6 months | Discovery quality, shared services, networking, operational readiness |
| Business-critical platform | 6-12 months | Data replication, downtime tolerance, security controls, cutover rehearsal |
| Large estate or modernisation programme | 12-24+ months | Portfolio size, legacy constraints, replacement decisions, organisational change |
The early number on a roadmap is often too optimistic because it counts the visible infrastructure but not the work needed to make the destination usable. Before production systems move, teams need secure account or subscription structures, network connectivity, identity boundaries, logging, monitoring, backup, deployment pipelines, cost allocation, and clear ownership.
That is not ceremony. It prevents an organisation from creating a second, less controlled estate in the cloud. A well-designed cloud engineering foundation gives later migration waves reusable infrastructure, patterns, and controls instead of forcing each application team to invent its own.
Why schedules differ so widely
Two applications can have the same number of servers and completely different migration timelines.
An internal tool with one database and a planned maintenance window may be relatively direct. A customer-facing service with a legacy identity provider, on-premises data, scheduled batch jobs, third-party APIs, undocumented firewall rules, and strict service-level obligations is not. The server move may be quick; making the service safe to move is where the time goes.
Dependencies decide the migration wave
Applications seldom operate alone. They depend on DNS, certificates, databases, file stores, authentication services, integrations, message queues, network routes, and manual support processes. A single hidden dependency can force systems that appear unrelated into the same migration wave.
Microsoft's guidance for planning an Azure migration recommends grouping workloads around shared databases, APIs, identity services, and network connections. It also calls out the need to validate supporting infrastructure such as load balancers, DNS, and caching before a group is considered complete.
That is a useful principle on AWS too. Discovery is not a pre-project activity that can be rushed through to reach delivery. It is delivery work. The most reliable way to reduce the migration schedule is to surface constraints before a cutover date is announced.
Data movement has its own timeline
Data does not move at the same speed as servers. A programme may include transactional databases, files, event histories, analytics stores, backup archives, or regulated records. The size matters, but so do change rates, validation rules, network capacity, retention requirements, and the period during which source and target need to operate together.
For a small database that tolerates a maintenance window, a one-time transfer may work. For a customer-facing system, teams may need continuous replication, reconciliation, parallel running, and a clear point at which the cloud copy becomes authoritative. Those activities need test environments, business acceptance criteria, and a rollback path.
Azure's guidance distinguishes between private connectivity, VPN, public internet, and offline data transfer. Each choice affects lead time, security, throughput, and operating risk. The same principle applies regardless of provider: the question is not simply how quickly data can be copied. It is how long it takes to prove it is complete, consistent, recoverable, and usable.
The migration method changes the clock
The method selected for each workload has a direct effect on duration.
- Rehost moves servers or virtual machines with limited application change.
- Replatform retains the application but moves it onto managed databases, containers, or platform services.
- Refactor changes the application architecture to improve resilience, maintainability, or delivery speed.
- Replace or retire removes the workload, adopts a product, or decommissions it.
Rehosting can be an appropriate response to a data-centre exit, hardware refresh, or operational risk. It is not automatically the right destination. Moving an inefficient architecture into the cloud can transfer technical debt and cost without fixing either.
Replatforming or refactoring adds engineering time. It can also remove a more expensive constraint from the target state. The right choice depends on business urgency, the expected life of the application, its availability needs, and the cost of continuing to support the current design.
AWS notes that Migration Hub is no longer open to new customers, with newer capabilities available for migration planning and execution. That change is a useful reminder that tools evolve. A migration strategy should be built around workloads, operating outcomes, and repeatable practices rather than one provider dashboard.
A realistic delivery sequence
Strong programmes overlap their phases rather than finishing discovery across the entire portfolio before starting any delivery.
Weeks 1-6: assess the estate and define success
The objective is a usable view of the estate, not a perfect catalogue that delays action. For each candidate workload, identify the owner, business criticality, application and data dependencies, technical constraints, expected migration method, downtime tolerance, and recovery requirements.
This is also when the programme should agree what success means. It may mean retiring costly infrastructure, improving release speed, reducing operational risk, or enabling a product change that the current platform cannot support. A server count is not a business outcome.
Weeks 4-12: build the cloud foundation
The target environment should become a working platform, not a diagram. That means repeatable infrastructure, access controls, network segmentation, secrets management, observability, backups, deployment automation, and cost visibility.
Equally important is the operating model. Who approves access? Who owns a platform incident? How are application costs attributed? Who can authorise a rollback? If those questions remain unresolved, migration may appear to progress while operational risk accumulates.
Months 3-6: run a representative pilot wave
Start with a workload that is manageable but representative. An entirely isolated development server proves little about identity integration, data reconciliation, monitoring, support handover, or cutover communications.
The pilot should create reusable assets: infrastructure modules, migration runbooks, security patterns, test scripts, dashboards, rollback checklists, and stakeholder communications. The aim is to make the second and third waves more predictable than the first.
Months 6 onward: migrate in waves and stabilise
Once the team has a repeatable process, work settles into a delivery cadence: prepare, test, cut over, validate, learn, and repeat. The cutover itself may be a few hours, but preparation can take months for a critical service.
Stabilisation belongs in the schedule. Teams need time to validate performance, reconcile data, remove obsolete integrations, retire legacy infrastructure, and understand the cloud cost profile. A workload that is live in AWS or Azure but still relies on its former environment has not delivered the full benefit.
What makes migrations late
Most programmes do not slip because provisioning cloud infrastructure is slow. They slip because difficult decisions are left until the point when production systems must move.
Common causes include:
- Treating dependency discovery as optional
- Building the landing zone after the first production workload has moved
- Applying one migration method to every workload
- Leaving identity, network, and data constraints until cutover planning
- Excluding application owners, security, finance, or operations from wave decisions
- Scheduling a critical migration without rehearsing rollback
- Measuring progress by systems moved instead of business services safely retired
- Allowing a temporary hybrid state to become permanent without funding its operational cost
Microsoft's migration guidance is explicit about defining failure criteria, assigning rollback authority, automating recovery where possible, and testing the procedure before production. Those are practical controls, not an optional appendix to the plan.
AWS or Azure: does the choice change the timeline?
Usually, the provider changes the implementation details more than the core duration. Both platforms support the common building blocks: compute migration, database replication, private connectivity, managed services, security controls, infrastructure as code, and monitoring.
The fastest safe destination is normally the platform where the organisation already has mature identity, networking, governance, delivery practices, and operational skills. If teams already operate Azure subscriptions with a clear management model, Azure may be the lower-risk route. If AWS accounts, pipelines, and security patterns are already established, AWS may be the more direct path.
Platform choice should not be used to avoid architectural decisions. It should follow them. Cloud migration consultancy is most useful when it turns those decisions into a target architecture, migration sequence, governance boundaries, and delivery model that can withstand real production constraints.
Estimate by workload, not by a single end date
A credible estimate segments the portfolio. For each workload, assess business criticality, dependency complexity, data movement, target readiness, migration method, cutover model, and the readiness of the people who need to support it.
Then estimate in waves. Ten workloads are not necessarily ten times the work of one; later waves can reuse the platform and practices built by the first. But ten tightly coupled systems may be one large migration problem rather than ten smaller ones.
This also separates two conversations that are too often combined: the date by which a data centre or contract must be exited, and the sequence in which services can safely move. The former is a commercial constraint. The latter is an engineering and operational reality. Both must be visible in the programme plan.
For an example of a phased, production-sensitive migration, see Westpoint's Toyota North America case study, where enterprise identity modernisation and an Azure-to-AWS migration were delivered without disrupting critical operations.
The practical answer
Plan in weeks for a low-risk, standalone workload. Plan in months for an application wave with shared services and a ready cloud foundation. Plan a staged programme for a critical estate with complex data, integrations, or limited downtime.
The best migration schedule is not the shortest number on a steering-committee slide. It is the one that gives owners confidence, lets the team practise before moving critical services, and leaves the organisation with a platform it can operate, govern, and improve.
