Table of contents
A simple lift-and-shift migration of one or two applications typically costs ₹8L–₹20L. Replatforming — moving to the cloud while adopting managed services along the way — runs ₹20L–₹50L. A full re-architecture into cloud-native patterns can run ₹50L to over ₹1 crore, and enterprise-scale migrations spanning many applications and legacy systems commonly exceed that. The strategy you choose changes both the cost and the risk profile — a cheaper migration isn't automatically the better choice.
This guide breaks down what drives cloud migration cost, compares the common migration strategies, and covers the costs that typically don't appear in an initial migration quote.
- Simple lift-and-shift
- ₹8L – ₹20L
- Replatforming
- ₹20L – ₹50L
- Full re-architecture (cloud-native)
- ₹50L – ₹1Cr+
- Enterprise, multi-application migration
- ₹1Cr+
Indicative ranges — data volume, downtime tolerance and legacy system complexity move a project between bands more than application count alone.
Migration strategies compared
The well-known industry framework for describing migration approaches groups them roughly as: rehost, replatform, refactor, repurchase, retire, or retain. In practice, most SME and mid-market migrations fall into three practical bands.
| Strategy | What it means | Speed vs. long-term benefit |
|---|---|---|
| Lift-and-shift (rehost) | Move existing servers/applications to cloud VMs with minimal change | Fast, lower risk — but doesn't capture cloud-native cost or scaling benefits |
| Replatforming | Move to cloud while adopting some managed services (managed database, managed queues) without a full rewrite | Moderate effort, meaningfully better cost and operational efficiency |
| Refactor / re-architect | Redesign the application around cloud-native patterns (containers, serverless, managed services throughout) | Highest effort, best long-term cost, scalability and maintainability |
What actually drives migration cost
Data volume and transfer
Moving large volumes of data — especially across regions or providers — takes real time and, depending on volume, real transfer cost. This is frequently underestimated in initial planning, particularly for data-heavy applications like analytics platforms or media-heavy products.
Downtime tolerance
A migration that can tolerate a scheduled maintenance window is considerably cheaper to execute than one requiring near-zero downtime, which needs parallel-running infrastructure, careful cutover orchestration, and rollback planning — real engineering effort, not just a longer timeline.
Number of applications and their interdependencies
Migrating one self-contained application is straightforward. Migrating a dozen interdependent applications means sequencing the migration so dependencies don't break mid-process — often the single biggest driver of cost in enterprise migrations.
Legacy system complexity
Older systems built on outdated frameworks, with undocumented dependencies or custom infrastructure quirks, take considerably more discovery and testing effort than a modern, well-documented application.
Compliance and data residency requirements
Regulated data (financial, healthcare, or data subject to residency requirements) constrains which regions and services you can actually use, and may require additional security review before and after migration — see our corporate bank API integration guide for the kind of security rigor that applies when payment or financial data is involved.
Team expertise
A team experienced with the target cloud platform executes faster and makes fewer costly mistakes than one learning it during the migration — this is one of the more common reasons actual migration cost exceeds initial estimates.
Timeline
| Migration type | Typical timeline |
|---|---|
| Simple lift-and-shift (1–2 applications) | 4–8 weeks |
| Replatforming | 8–16 weeks |
| Full re-architecture | 4–9 months |
| Enterprise, multi-application migration | 9–18 months |
Dual-running cost is easy to forget
During migration, many teams run old and new infrastructure in parallel to validate the migration before fully cutting over — meaning you pay for both environments simultaneously for a period. Budget this explicitly; it's routinely missed in initial cost estimates and can meaningfully affect total project cost for longer migrations.
Hidden costs
- Data transfer costs, especially for large volumes or cross-region moves
- Dual-running infrastructure cost during the cutover period
- Licensing changes — some software licensing terms change or cost more in cloud environments
- Team retraining or hiring for the target cloud platform
- Monitoring and observability tooling, often not included in the base migration scope
- Security review and remediation, especially for regulated data
- Post-migration optimization — a completed migration is rarely instantly cost-optimized
AWS vs. Azure: a scoping note, not a recommendation
Provider choice matters less for cost than migration strategy and execution quality — both AWS and Azure (the two most common defaults we see) offer comparable core services, and the right choice usually depends on your team's existing expertise, specific managed-service needs, and any existing enterprise agreements, not a general "which is cheaper" answer. Treat provider selection as its own scoping conversation rather than assuming it dominates the cost equation.
A related question that comes up in almost every migration scoping conversation: does the target architecture need Kubernetes, or would a simpler managed platform serve the same workload with less operational overhead? See our Kubernetes for startups guide for an honest answer, since adding orchestration complexity during a migration you don't yet need is a common way migrations run over budget.
For migrations that involve deeper application changes — not just infrastructure relocation — the cost and team-composition patterns in our custom software development cost guide apply directly, since a re-architecture-level migration is, functionally, a software development project with cloud infrastructure as one component.
Planning a cloud migration?
Talk to our engineering team about migration strategy, realistic timeline and cost before you commit to an approach.
Frequently asked questions
How much does cloud migration cost?+
A simple lift-and-shift typically costs ₹8L–₹20L. Replatforming runs ₹20L–₹50L. A full re-architecture into cloud-native patterns can run ₹50L to over ₹1 crore, and enterprise-scale, multi-application migrations commonly exceed that.
What's the difference between lift-and-shift and replatforming?+
Lift-and-shift moves existing infrastructure to the cloud with minimal change — fast but doesn't capture cloud-native efficiency benefits. Replatforming adopts some managed cloud services along the way, offering meaningfully better cost and operational efficiency for moderate additional effort.
What drives cloud migration cost the most?+
Data volume, downtime tolerance, number of interdependent applications, legacy system complexity, and team expertise with the target platform — not the cloud provider you choose.
What hidden costs should I budget for in a cloud migration?+
Data transfer costs, dual-running infrastructure during cutover, licensing changes, team retraining, monitoring tooling, security review, and post-migration cost optimization — all commonly missing from initial quotes.
How long does a cloud migration take?+
A simple lift-and-shift takes 4–8 weeks. Replatforming takes 8–16 weeks. A full re-architecture takes 4–9 months, and enterprise multi-application migrations typically take 9–18 months.
Should I choose AWS or Azure for my migration?+
Provider choice matters less for cost than migration strategy and execution quality. The right choice usually depends on your team's existing expertise and specific managed-service needs rather than a general cost difference between providers.
Is it cheaper to lift-and-shift or fully re-architect?+
Lift-and-shift is cheaper upfront but doesn't capture long-term cost and scaling benefits. Re-architecting costs more initially but pays off for systems you plan to run and scale for years. For systems nearing end-of-life, lift-and-shift is often the right call precisely because it avoids over-investing.
Written by
CodeSurge AI Engineering Team
The CodeSurge AI team designs and builds AI systems, SaaS products and enterprise integrations for clients in India, the UAE and beyond — this section shares the architecture patterns, cost drivers and implementation tradeoffs we work through on real projects.