Codalyst Tech
Software Development10 min read

Cloud Migration for SMBs: What to Move, What to Leave, and What It Actually Costs

Cloud migration does not save money by default. Done without a clear strategy, your AWS bill can exceed what you paid your old hosting provider in three months. Here is an honest cost and timeline guide for SMBs.

Cloud Migration for SMBs: What to Move, What to Leave, and What It Actually Costs

Cloud migration promises lower infrastructure costs, better reliability, and simpler scaling. The reality is more complicated. Some workloads are genuinely cheaper and more reliable in the cloud. Others cost more to run in the cloud than on-premises, and the migration itself can consume more budget than years of avoided infrastructure purchases.

The decision is not "should we be in the cloud" but "which of our systems should be in the cloud, and is this the right time?"

The Business Case: When Cloud Migration Makes Sense

Cloud migration has a clear financial case in specific scenarios.

You are spending significant time managing servers. If your team is patching operating systems, replacing failed hardware, managing backups, and handling capacity planning, you are spending engineering time on commodity work that cloud providers have automated. The hidden cost of on-premises infrastructure is the engineering time it consumes.

Your load is variable. A retailer whose traffic spikes 5x in November but runs at 20% capacity the rest of the year pays for peak capacity when running on-premises. In the cloud, that spike costs proportionally more but the baseline costs proportionally less.

You have compliance requirements that cloud providers now meet. AWS, Azure, and Google Cloud all hold SOC 2, ISO 27001, HIPAA, PCI-DSS, and other certifications. Using a certified cloud provider can be easier than certifying your own infrastructure, depending on your compliance situation.

Your team has cloud skills but not operations skills. A startup with strong developers and no dedicated operations team often runs more reliably in the cloud than on-premises, where someone needs to manage hardware and infrastructure full-time.

Cloud migration does not make sense when your workload is large, predictable, and constant. At sufficient scale with predictable demand, on-premises hardware is often cheaper than cloud compute on a per-hour basis. Netflix and Amazon both run significant workloads in their own data centres rather than exclusively in commercial cloud.

For most SMBs, some combination of cloud services is the right answer, with the specific mix depending on workload characteristics.

What to Move First

Not everything should migrate at once. The lowest-risk, highest-return migrations:

Email and productivity. If you are still running your own email server, move to Microsoft 365 or Google Workspace. The cost is $6 to $30 per user per month, and you eliminate the operational burden of email server management entirely. This migration is reversible and low-risk.

Development and staging environments. Developers need environments to build and test in. These environments do not need to run continuously and can be created and destroyed on demand. Running dev and staging in the cloud while keeping production on-premises is a common intermediate state that reduces cost and gives teams cloud experience before migrating production.

Backups and disaster recovery. Storing backups in cloud object storage (S3, Azure Blob Storage, Google Cloud Storage) is extremely cost-effective. Object storage costs $0.02 to $0.023 per GB per month, which is significantly cheaper than physical backup media for most volumes. This migration is one-directional and low-risk.

Static assets and CDN. Images, videos, and static files are an easy win: move them to object storage with a CDN in front. This typically reduces latency for users globally, reduces load on your application servers, and costs less than hosting on your own servers.

Applications with variable load. Customer-facing web applications with variable traffic patterns are natural cloud candidates. You pay for the compute you use rather than the compute you provision for peak.

What to Consider Carefully Before Moving

Databases with large data volumes. Database egress costs are one of the most significant hidden costs in cloud migrations. Moving data out of a cloud database costs money. A database serving large queries frequently can generate significant egress bills. Before migrating a large database, model the expected egress costs against the savings from not managing the database server yourself.

Applications with predictable, constant load. A batch processing system that runs at the same rate 24 hours a day, 7 days a week, costs more on-premises to build but often costs more in the cloud to run over time. Reserved and committed use discounts in cloud providers narrow this gap but do not eliminate it for all workloads.

Legacy applications that cannot be refactored. Lift-and-shift (moving an application to run on a cloud VM exactly as it ran on-premises) is technically simple but captures almost none of the cloud's operational benefits. A legacy application that cannot use managed database services, auto-scaling, or serverless compute will cost more in the cloud than on a managed server.

Highly regulated data. Some industries have data residency requirements that restrict which countries data can be stored in. Cloud providers have regions in most major countries, but confirm your compliance requirements before migration.

The Real Cost Structure

Cloud migration costs come in three categories: migration cost, ongoing cost, and hidden cost.

Migration cost: $10,000 to $150,000 depending on complexity.

A simple application (one or two servers, a database, a web application) costs $10,000 to $30,000 to migrate properly. This includes assessment, architecture design, implementation, testing, and cutover.

A complex enterprise migration (dozens of services, custom integrations, on-premises dependencies, regulatory requirements) costs $50,000 to $150,000 or more. These migrations take 6 to 18 months.

Most SMB migrations fall in the $15,000 to $50,000 range.

Ongoing cloud cost: variable.

Small web application with managed database and moderate traffic: $300 to $800 per month (AWS/Azure/GCP).

Mid-size SaaS application, production and staging environments, managed database with read replicas, CDN: $1,500 to $4,000 per month.

Large-scale application with significant data processing: $5,000 to $30,000 per month.

These costs are highly variable. A single misconfigured resource (a forgotten high-memory instance left running, an S3 bucket serving large files without a CDN, a data transfer pattern that generates unexpected egress) can significantly increase your bill.

Hidden costs.

Cloud spend optimisation is an ongoing task. Without active management, cloud bills tend to grow as services are added and old resources are not removed. Budget for a monthly review of cloud spend, or use a tool like AWS Cost Explorer or Azure Cost Management.

Data egress: moving data out of the cloud costs money at most providers. $0.08 to $0.09 per GB for AWS and Azure. For applications that serve large files or transfer significant data between services, this adds up.

Training: your team needs to know how to use cloud services safely. Misconfigured security groups, accidentally public S3 buckets, and oversized instances are all common and costly errors from teams new to cloud.

The Three-Phase Migration Approach

For SMBs, a staged migration reduces risk and distributes cost.

Phase 1: Non-production and low-risk services (months 1-2)

Migrate development environments, backups, and static assets. Build cloud operations experience with low-risk systems. Establish monitoring, access control, and cost alerting.

Phase 2: Secondary production systems (months 2-4)

Migrate less critical production systems, starting with stateless applications. Keep the database on-premises or migrate to a managed cloud database service with careful cost modelling.

Phase 3: Core production systems (months 4-6+)

Migrate the core application and database. This phase requires the most careful planning, testing, and a rehearsed cutover procedure with a rollback plan.

The staged approach means you are never migrating everything at once, and each phase gives you more cloud experience before tackling the next one.

Selecting a Cloud Provider

For most SMBs:

AWS if you have developers with existing AWS experience, need the widest service catalogue, or are in a market where AWS is the dominant choice for partners and integrations.

Azure if you are a Microsoft-heavy shop (Microsoft 365, Active Directory, Windows Server). Azure integration with existing Microsoft infrastructure is genuinely better than AWS or GCP.

Google Cloud if you are using Google Workspace, building ML or data-heavy applications (GCP's data and ML tooling is strong), or want generally competitive pricing.

All three are reliable and capable. The decision is primarily about your team's existing skills and your existing vendor relationships, not about which cloud is technically superior for most workloads.

For help scoping and executing a cloud migration, our web development team handles infrastructure migrations from assessment through to production cutover. Contact us to discuss your current infrastructure and migration goals.