How much does it cost to migrate a small SaaS to Kubernetes?

The short answer: for a 10–30 person SaaS team moving from a single-VM or PaaS setup to Kubernetes, expect $40k–$150k all-in for the migration itself, plus $1.5k–$8k/month in new infrastructure costs (often higher than what you were paying). The actual number depends almost entirely on how much production-grade tooling you set up around the cluster, not the cluster itself.

This post breaks down what those numbers contain, what people forget to budget for, and the two specific scenarios most small SaaS teams actually fall into. By the end you should be able to sanity-check a vendor or consulting quote against a realistic baseline.

What we mean by “small SaaS”

The numbers here apply to teams with these rough characteristics:

• 10–30 engineers total, 1–5 of whom touch infrastructure.
• One main product, maybe a handful of services (web app, API, async workers, a database, a cache).
• Monthly cloud bill currently in the $1k–$10k range.
• Running on something like Heroku, Render, a single EC2 box, or a small docker-compose setup on a VM.
• No dedicated platform team. DevOps is “the engineer who knows how AWS works.”

If you’re smaller than this, you probably don’t need Kubernetes yet. If you’re bigger, the costs scale up but the structure stays the same.

The four cost buckets

Every migration cost falls into one of four buckets. We’ll go through them in the order they hurt most.

1. Engineering time (usually the largest cost)

Even if a consultant does most of the work, your engineers are involved — reviewing PRs, answering questions about the existing system, learning the new one. A realistic time budget for a 10–30 person team migration:

• Lead engineer (full-time on migration): 8–14 weeks at 100%.
• Two supporting engineers (review, learning, dual-running): 4–8 weeks at 25%.
• The rest of the team: a few hours each, scattered — mostly learning the new deploy flow.

At a $150k loaded cost per senior engineer, that’s roughly $30k–$55k of engineering time even if external help is doing the heavy lifting. If you’re doing it without external help, it can easily double, because your engineers are learning Kubernetes while they migrate to it.

2. New cloud infrastructure

Kubernetes itself is free. Running it isn’t. The bill grows for three reasons:

• Control plane. Managed Kubernetes (EKS, AKS, GKE) charges $0.10/hour per cluster — about $73/month per cluster. You typically want at least two (prod, non-prod), so $150/month minimum.
• Worker nodes. Even an idle cluster needs nodes. A reasonable starter setup is 2–3 small nodes per cluster, plus headroom. For a small SaaS, expect $300–$1,500/month just in compute, before traffic.
• Load balancers, NAT gateways, networking. Often the surprise. Each LoadBalancer service spins up a cloud load balancer ($18–$25/month). NAT gateway data egress is the silent killer ($45/month base plus per-GB charges).
• Container registry, image storage, secrets. Modest but real — $20–$100/month.

3. Consulting or contractor cost (if you hire help)

If you bring in outside help, the spread is wide:

• Bare-bones migration consulting — get containers running on managed Kubernetes, basic Helm charts, manual deploy: $15k–$30k for 4–6 weeks.
• Production-grade migration — IaC, CI/CD pipeline, monitoring, secrets management, multi-environment, runbooks: $40k–$100k for 8–14 weeks.
• Full platform engagement — everything above plus GitOps (ArgoCD/Flux), preview environments per PR, custom developer tooling, training: $80k–$200k.

The variance is mostly about how much of the “platform-grade” work is in scope, not about who’s doing it. A consultant charging $80k for what you thought was a $20k job isn’t necessarily ripping you off — you may not have realised what production-grade meant.

4. Hidden costs people forget

The line items that don’t show up on the initial budget:

• Observability stack. Datadog or New Relic for a small Kubernetes deployment can easily be $500–$2,000/month. Self-hosted Grafana/Loki/Mimir is cheaper but takes engineering time to maintain.
• Container image build time. If your CI doesn’t cache images well, builds get slow and you start paying for bigger CI runners. Plan on $200–$1,000/month in CI uplift.
• Engineer training. Your developers now need to read pod logs, understand readiness probes, know what a 503 from an ingress means. Plan a week of stumbling for everyone who touches deploys.
• Dual-running. You’ll run old and new systems in parallel for 2–6 weeks. Both bills land at the same time.
• Backups, DR, secret rotation. Often deferred from the initial scope. They’re “phase 2.” They get expensive when you need them and you don’t have them.
• The hire you’ll need. Most small teams that move to Kubernetes eventually hire (or retain) someone whose job partly is platform work. That’s not a migration cost — it’s a permanent cost shift.

Worked example 1: 10-person SaaS, basic migration

Imagine a 10-person Rails-on-Heroku SaaS. Single app, one Postgres database, ~$1,500/month Heroku bill. They want to leave Heroku — their pricing has crept and they’re hitting platform limits. They’re moving to AWS on EKS, keeping things simple.

Scope: get the app on EKS, RDS for Postgres, ElastiCache for Redis, GitHub Actions for CI/CD, basic Prometheus + Grafana via the AWS-managed Grafana service. No GitOps, no preview environments. One prod cluster, one staging cluster.

Timeline: 7 weeks.

Costs:

• External help (consultant): $25,000 (fixed scope)
• Lead engineer time: 5 weeks at 100% — ~$15,000 loaded cost
• Two supporting engineers: 3 weeks at 25% — ~$4,500 loaded cost
• Dual-running cloud bill: $2,500 (one month overlap)
• Initial training: ~$1,000 (books, a course)
• Migration total: ~$48,000

Ongoing cost after migration:

• EKS clusters (2): ~$150/month
• Worker nodes: ~$450/month
• RDS Postgres: ~$200/month
• ElastiCache: ~$80/month
• Load balancers, NAT, egress: ~$200/month
• Container registry, monitoring: ~$100/month
• Total: ~$1,180/month — lower than Heroku, but only just

Worked example 2: 30-person SaaS, production-grade migration

A 30-person team with three services (web, API, background workers), Postgres, Redis, and an external SaaS for search. Currently on a couple of EC2 instances built up over years, $4,000/month cloud bill. They want a proper platform: IaC, GitOps, preview environments per PR, real observability, and a runbook for the on-call rotation they’re about to start.

Scope: Everything in example 1, plus ArgoCD for GitOps, preview environments via PR-triggered namespace creation, OpenTelemetry-based observability with Prometheus + Loki + Grafana (self-hosted in cluster), Vault for secrets, automated TLS via cert-manager, runbooks, and a documented on-call rotation. Multi-region DR planning included, multi-region execution deferred.

Timeline: 12 weeks.

Costs:

• External help (consultant): $80,000 (fixed scope, includes training)
• Lead engineer: 12 weeks at 100% — ~$36,000 loaded cost
• Two supporting engineers: 6 weeks at 30% — ~$11,000 loaded cost
• Dual-running cloud bill: ~$8,000 (six-week overlap)
• Tooling licenses (initial year, mostly free tiers): ~$2,000
• Training (team workshops, books, courses): ~$3,000
• Migration total: ~$140,000

Ongoing cost after migration:

• EKS clusters (2): ~$150/month
• Worker nodes (larger pool, observability, preview envs): ~$1,800/month
• RDS Postgres: ~$600/month (sized for production)
• ElastiCache: ~$200/month
• Load balancers, NAT, egress, S3: ~$400/month
• Self-hosted observability storage (S3, EBS): ~$150/month
• Container registry, image scanning, misc: ~$200/month
• Total: ~$3,500/month — ~$500/month less than before, but with much more headroom and the platform foundations.

What changes the price the most

The biggest swing factors, in roughly the order they affect the bill:

1. Whether the migration is “lift and shift” or “cloud-native rebuild.” Lift-and-shift is cheaper but defers most of the value. Cloud-native rebuild is the bigger ticket but is what most teams actually need.
2. How many environments you build for. One cluster vs. dev/staging/prod vs. ephemeral preview environments per PR — each step roughly doubles the platform scope.
3. How much observability you want from day one. A team that’s fine with CloudWatch logs and basic dashboards pays a fraction of what a team that wants distributed tracing, log aggregation, and SLO dashboards will.
4. GitOps or no GitOps. ArgoCD/Flux adds 1–2 weeks of work but pays for itself the first time something goes wrong.
5. Whether your app is Kubernetes-friendly today. Stateful apps, in-memory session state, hardcoded local file paths, no health endpoints — each of these adds days.
6. Whether you’re also doing a database migration. If you’re moving from a managed Postgres provider to RDS at the same time, you’ve added a serious project to the project.

The line items most teams cut and shouldn’t

• Documentation. Always the first thing to go. Always the first thing your team needs when the consultant leaves. Insist on it.
• Runbooks for the top 5 failure modes. Not theoretical — the actual ones you’ll see. “Pod stuck in CrashLoopBackOff.” “Ingress returning 502.” “Out of memory on database.” If they aren’t written down, the on-call person learns them at 3 a.m.
• A working backup and restore drill. Backups are easy. Restores are where the gap is. Drill it once before the consultant rolls off.
• The follow-up engagement. Three months in, something will be off. Budget for a 1–2 day check-in. It’s the cheapest insurance you’ll buy.

When NOT to migrate to Kubernetes

Some teams are better served by not doing this at all. Specifically:

• You have fewer than ~5 engineers and a simple stack. Kubernetes is overhead you don’t need yet. A modern PaaS (Render, Fly, Railway) or even a couple of well-managed EC2 instances will serve you fine.
• Your main pain is cost. Kubernetes rarely cuts costs at small scale. If your bill is high, a cloud cost audit will likely save more money than a migration.
• You don’t have anyone who’ll own the platform after the consultant leaves. Kubernetes punishes neglected platforms harder than other systems do.
• You’re moving because everyone else moved. The grass-is-greener migration is the most expensive one.

Cheaper alternatives to evaluate first

• Modern container-friendly PaaS. Fly.io, Render, Railway, Heroku still — these get you containers and basic platform features without you owning the platform.
• Managed container services without full Kubernetes. AWS App Runner, Google Cloud Run, Azure Container Apps. You get container deploys without managing a cluster.
• ECS over EKS on AWS. If you’re committed to AWS and want containers, ECS is a fraction of the operational complexity of EKS. People underrate this.
• Stay where you are and fix the actual pain. If your problem is “deploys are scary,” the answer is a CI pipeline and IaC — not Kubernetes. We see this confusion a lot.

How to sanity-check a quote

If a consultant or contractor sends you a quote, run it through these questions:

• What specifically is in scope? “Migrate to Kubernetes” is not a scope. “Two clusters, GitHub Actions CI/CD pipeline, Helm charts for each service, Prometheus+Grafana, ArgoCD, documented runbooks for the top 5 failure modes” is a scope.
• Is the price fixed or T&M? Fixed is almost always better at this stage. A consultant unwilling to fix a price hasn’t actually scoped the work.
• What’s explicitly excluded? The honest list is gold. “Excludes database migration, excludes existing application refactoring, excludes multi-region setup.”
• What does handover look like? “A demo and a Slack invitation” is not handover. “Documented architecture, runbooks, a recorded walkthrough, and a follow-up day 30 days later” is.
• What does your team need to do? If the answer is “nothing,” the consultant is either lying or about to build something your team can’t maintain.

Closing thought

For a 10–30 person SaaS, a good Kubernetes migration is a $40k–$150k project, not a weekend. The variance is almost entirely about how much real production tooling you put in around the cluster — CI/CD, observability, GitOps, runbooks. The cluster itself is the cheap part.

The biggest budgeting mistake is treating the cluster as the project. The cluster takes a week. The platform around it takes the rest of the time, and it’s where the value is.