Moving to the cloud does not save money by default. Done without a clear strategy, your AWS or Azure bill can exceed what you were paying your previous hosting provider within three months. The mistake is not choosing cloud — it is treating migration as the goal rather than treating cost efficiency, reliability, or scalability as the goal and choosing migration as one tool among several to achieve it.
This is what a realistic cloud migration looks like for a small or mid-sized business, including the numbers that rarely get published upfront.
Why cloud migration cost estimates are almost always wrong
The estimates businesses receive at the start of a cloud migration project fail for three consistent reasons.
First, they only price the infrastructure. They count compute instances, storage, and egress bandwidth. They do not count the engineering time required to migrate applications, refactor where needed, test thoroughly, handle data migration, train your team, and work through the surprises that arise when you move a system that has been running in one environment for years into a completely different one.
Second, they underestimate cloud consumption costs. AWS, Azure, and GCP charge for compute by the second, storage by the gigabyte-month, and egress bandwidth by the gigabyte transferred. These costs are predictable in a test environment and unpredictable in production until you have at least 60 days of real usage data. A workload that runs fine at $300 per month in testing will sometimes run at $1,200 per month in production because actual usage is higher, because caching is configured differently, or because egress charges were not accounted for in the initial estimate.
Third, they do not account for the dual-run period. During migration, you run your old environment and your new environment simultaneously. This overlap period lasts longer than planned in almost every project. Budget for two to four months of paying for both.
What to move and what to leave
Not everything benefits from cloud infrastructure, and migrating everything is rarely the right decision.
Move first. Applications and workloads with variable or growing demand benefit most. If your usage spikes significantly at certain times — seasonal retail, payroll processing, batch analytics, end-of-quarter reporting — cloud infrastructure lets you scale up for the spike and scale down immediately after, paying only for what you use. If you deploy new software regularly, cloud infrastructure with a CI/CD pipeline is far more manageable than updating servers manually.
Web applications, customer-facing APIs, data processing pipelines, and machine learning workloads are natural candidates. These are the applications where cloud infrastructure's flexibility translates directly into measurable operational benefit.
Leave for now. Legacy systems that are stable, that have been running for years without problems, and that do not need to scale are often better left where they are. The cost and risk of migration — especially for applications that predate modern APIs and require significant refactoring to run in a cloud environment — may not have a clear business justification.
Database migration deserves particular caution. A production database that has been tuned for a specific on-premises environment can behave very differently in a cloud setting. Migrating a database is not a lift-and-shift operation. It requires careful benchmarking, query profiling, configuration tuning, and extensive validation before you trust it in production. A lot of what makes database migration hard is inherited from past architectural decisions — our guide on the real cost of technical debt explains why those decisions compound over time.
The four migration approaches and what they actually cost
Cloud migration professionals describe migration strategies using several frameworks. For most SMBs, four approaches are practically relevant.
Lift and shift. You move your application from your server to a cloud virtual machine without changing the application code. It runs in the cloud exactly as it ran on-premises. This is the fastest approach and the cheapest to execute initially. It is also the approach that delivers the fewest benefits — you get the cloud's operational management model but not its elasticity, its managed services, or its cost efficiency at scale.
Engineer time to execute: two to eight weeks per application.
Ongoing cloud cost: typically 30 to 60 percent higher than a well-designed cloud deployment, because you are running over-provisioned virtual machines rather than right-sized infrastructure.
Replatform. You make targeted modifications to take advantage of managed services — switching from a self-managed database to a managed RDS instance, switching to a managed message queue instead of running your own, using a managed container service rather than maintaining your own infrastructure. The application logic does not change. The infrastructure does.
Engineer time: four to twelve weeks per application.
Ongoing cloud cost: typically 20 to 40 percent less than lift and shift, because managed services carry lower operational overhead and are priced for actual consumption.
Refactor. You redesign the application to use cloud-native architecture — breaking a monolith into services, adopting serverless compute, redesigning around cloud storage primitives. This delivers the highest long-term cost efficiency and scalability, and requires the most upfront engineering investment.
Engineer time: three to nine months per significant application.
Ongoing cloud cost: can be 50 to 70 percent less than on-premises for workloads with variable demand, and potentially more expensive than on-premises for workloads with constant, predictable demand — so the trade-off depends heavily on your usage pattern.
Retire. You identify applications that are redundant or no longer necessary and decommission them as part of the migration. This costs nothing in ongoing cloud spend and frees budget for the applications that are worth investing in. Most businesses find 10 to 20 percent of their applications fall into this category once they are properly audited.
For growing SaaS businesses making these decisions from scratch, our guide on SaaS MVP development covers the architectural trade-offs in more depth.
Real cost breakdown for a typical SMB migration
A typical small or mid-sized business migration — involving five to fifteen applications, one or two databases, and a team of five to twenty engineers — looks something like this in terms of budget:
Discovery and assessment: two to four weeks, $5,000 to $15,000. This is where you audit what you have, map dependencies, decide what to move and how, and produce the migration plan. This phase is consistently underinvested. Every dollar saved here is paid back several times over in execution surprises.
Infrastructure setup: one to two weeks, $3,000 to $8,000. Setting up your cloud account structure, networking, IAM permissions, logging, and monitoring before any application migration begins.
Application migration: two to sixteen weeks per application, $8,000 to $40,000 depending on complexity and approach. A simple lift and shift of a stateless web application sits at the low end. A refactor of a monolithic application with significant data dependencies sits at the high end.
Database migration: two to eight weeks, $5,000 to $20,000. Schema migration, data migration, validation, performance testing, and cutover planning. Managing the cutover window to minimise downtime is where most of this cost lives.
Testing and validation: two to six weeks, $5,000 to $15,000. Load testing, security scanning, disaster recovery testing, and application behaviour validation in the new environment.
Training and handover: one to two weeks, $2,000 to $5,000.
Total for a mid-sized migration: $50,000 to $150,000 in one-time engineering cost, plus ongoing monthly cloud spend that varies based on workloads and the architecture decisions made during the migration.
What drives the timeline
The honest answer is that cloud migration timelines are primarily driven by how much technical debt exists in the systems being migrated.
Clean, well-documented applications with clear dependencies and good test coverage migrate in a fraction of the time of legacy systems with undocumented dependencies, global state, hardcoded configurations, and no tests. The cloud provider choice — AWS, Azure, GCP — affects the timeline less than the quality of the starting codebase.
After that, the three biggest timeline drivers are:
The decision process. Every application has configuration decisions that require business input — what is the acceptable downtime window for this service? Which environments need to be replicated exactly? What is the disaster recovery requirement? Every time a business stakeholder needs to make a decision and is not available, the project waits.
Data migration complexity. Migrating data without downtime, with validation, and with a credible rollback plan is harder than most initial estimates assume. Over-optimism here is the single most common cause of missed migration deadlines.
The dual-run period. Running old and new environments simultaneously while validating the new one adds to timeline and cost. Trying to eliminate this phase to save money increases risk significantly. If validation fails after you have decommissioned the old environment, you have no fallback.
DevOps as a prerequisite, not an afterthought
A cloud migration without proper DevOps tooling is significantly riskier than one with it. Automated deployment pipelines, environment parity between staging and production, monitoring, and alerting are not nice-to-haves during a migration — they are what give you confidence that the new environment is behaving correctly before you shut down the old one.
Teams that try to migrate before they have a proper CI/CD pipeline tend to find that the migration surfaces infrastructure problems that were hidden in the old environment, and they have no systematic way to identify and address them. Our DevOps for startups guide explains the minimum setup that makes cloud infrastructure manageable.
How to approach it practically
For most SMBs, the highest-ROI starting point is not a full migration. It is migrating one or two of your highest-demand or most problematic applications first, validating the process and the results, and then extending from there.
This approach lets you learn from a smaller scope, build internal familiarity with the cloud environment before the stakes are high, and produce real ROI evidence before committing to a larger programme. It also gives you a realistic baseline for the true costs and timelines involved, rather than working from estimates that were produced without full information.
The most valuable step before any migration commitment is an architecture review that tells you what you have, what the migration options are for each component, and what the realistic cost and timeline looks like based on your actual systems — not a generic template.
Our cloud migration team works with SMBs through exactly this process. We start with a discovery engagement, help you build a migration plan that is honest about the trade-offs, and can deliver the migration on a fixed-price or time-and-materials basis depending on what fits your situation. Talk to us before you sign anything else. A clear picture of what you are actually getting into is worth more than the cheapest quote at the start.