A cloud migration takes 4 to 8 weeks for a single, low-complexity application, 8 to 16 weeks for a medium-complexity migration, and 4 to 9 months for a legacy application with several integrations — multi-system enterprise programs run 9 to 18 months, usually in phases. The number that matters isn't company size: it's how many systems talk to the one you're moving, and how well those dependencies are documented before you start.

How long does a cloud migration take?

A rough cloud migration timeline by scope:

Scope Typical timeline Main drivers of delay
Single application, minimal integrations, tolerant of a maintenance window 4–8 weeks Undocumented dependencies; no one on the team with hands-on cloud experience
Medium complexity: one primary application, a database, supporting services, proper testing 8–16 weeks Data migration and testing; zero-downtime requirements that need a designed cutover strategy
Legacy application with several downstream integrations and compliance requirements 4–9 months Integrations discovered mid-project; compliance and data residency reviews; an unstable source system
Multi-system enterprise migration (ERP, data warehouse, several line-of-business apps) 9–18 months, usually phased Cross-system dependencies; coordinating cutover windows across stakeholders; building the skills to operate the result

These ranges assume the inventory work below is done before the clock starts. Every week spent discovering an undocumented dependency mid-project adds roughly two weeks to the plan — first to understand it, then to test around it. That's the single biggest driver of migrations that blow past their original estimate. To adjust these ranges for your own readiness gaps, try the cloud migration timeline estimator.

What does an enterprise cloud migration timeline look like?

For a multi-system enterprise migration — ERP, data warehouse, several line-of-business applications — expect 9 to 18 months, delivered in phases rather than as a single cutover. Each phase is effectively its own migration with its own timeline from the table above, so the total is driven by how many systems depend on each other and how many cutover windows the business can tolerate.

The other enterprise-specific driver is operations after the move: the timeline should include the time for your team to own the new environment, not just the time to move workloads into it — more on that below.

How long does it take to migrate a legacy application to the cloud?

A legacy application with several downstream integrations and compliance requirements typically takes 4 to 9 months. The range is wide because legacy systems are where undocumented dependencies hide — each one found mid-project adds about two weeks.

Two things shorten it: a complete dependency inventory before scoping, and documented compliance and data residency requirements (in Argentina, Law 25.326 has data localization implications for sensitive data). One thing lengthens it dramatically: migrating a system that is already unstable. Stabilize first, migrate second.

What's the right time to consider migrating to the cloud?

The right time is when you have a clear cost case, someone on the team who can own a cloud environment afterward, and a documented inventory of what you're moving. The wrong time is when the main reason is a vendor pitch or a system in crisis.

Cloud migrations that fail rarely fail because of technical complexity. They fail because the organization wasn't ready — not technically, but operationally. The infrastructure moves; the processes, skills, and governance don't follow.

The result is a cloud environment that costs more than the on-premise system it replaced, is harder to operate, and is maintained by people learning on production.

This is avoidable. Here's a practical framework for assessing readiness before committing.

Signs the timing is right

You have a clear cost case. On-premise hardware is due for refresh, license costs are climbing, or traffic peaks require capacity you can't provision quickly. Cloud economics make sense when your current alternative is capital investment with a 3–5 year horizon.

Your team has someone who understands cloud architecture. Migrating is one problem. Owning a cloud environment after migration is a different one. If nobody on your team has hands-on AWS, GCP, or Azure experience, budget for training or a managed service before you start — not as an afterthought.

The application can tolerate a migration window. Not every workload can migrate without downtime. If yours can't, you need a specific zero-downtime strategy — blue-green deployment, active-active, or phased cutover — designed before you start, not improvised during the project.

You've documented what you're migrating. Servers, dependencies, data volumes, backup requirements, compliance constraints. Companies that skip this discover new dependencies every week of the project.

Signs the timing is wrong

You're migrating because a vendor told you to. "Cloud-first" is a valid architecture principle. "Cloud because your ERP vendor pitched it at the renewal meeting" is not a migration strategy. Understand the specific workload benefits before committing budget.

Your current system is in crisis. Migrating a system that's already unstable doubles your risk surface. Stabilize first, migrate second. Using the migration as an opportunity to "fix everything" is how migrations become 18-month projects.

You have no runbook for the current environment. If your team doesn't have documented procedures for the on-premise system, they won't spontaneously produce them during a migration. The gap becomes visible — and expensive — after the cutover.

The timeline is under 8 weeks. A realistic timeline for a medium-complexity migration — one primary application, a database, supporting services, and proper testing — is 8–16 weeks. Compressing this significantly increases the probability of a production incident during cutover, and incidents during cutover are the kind that generate post-mortems and executive escalations.

A minimal readiness checklist

Before starting any migration engagement:

The question worth asking before starting

If the migration succeeds technically but your team can't operate the result independently in 90 days, was it a success?

The answer to that question determines whether you need a migration project or a migration project plus a capability-building program. Both are valid — but conflating them creates unrealistic timelines and unhappy stakeholders.

Evaluating a migration and want to pressure-test your readiness? We're available for a scoping conversation.