Should you containerize before migrating? Usually not first

“Should we containerize everything first?” is one of the most common, and most expensive, questions at the start of a cloud migration. The instinct is understandable: containers feel modern, and modern feels like the point of moving. But sequencing is the whole game here, and the default answer is not yet.

What containerizing is, in migration terms

Packaging an app into a Docker image and running it on an orchestrator is a replatform or refactor, not a rehost. It changes how the app is built, configured, deployed, and observed, which means it carries application-level risk on top of the infrastructure move.

Coupling the two (“we’ll containerize while we migrate”) means every cutover now depends on a new build pipeline, a new runtime, new failure modes, and a team learning Kubernetes under deadline pressure. When something breaks at 2 a.m., you can’t tell whether the cloud, the container, or the app is at fault, you changed all three at once. This is the classic mechanism by which a six-month migration becomes an eighteen-month one.

What it actually costs

The costs are concrete and routinely underestimated:

Cost	Realistic size
Containerizing one well-behaved app	1-4 weeks: Dockerfile, config externalization, CI pipeline, health checks, logging/metrics rewiring
Containerizing a stateful or snowflake app	Multiples of that, local file writes, in-memory sessions, and hand-edited config all have to be untangled first
Running Kubernetes as a platform	Cluster build, upgrades every few months, ingress/secrets/observability stack, realistically a large fraction of an engineer, forever
Team learning curve	Weeks to months before the team debugs the new stack as fast as the old one

None of this is wasted if the app earns it. The mistake is paying it for apps that don’t, and most portfolios are full of those.

The decision framework: score each app, not the portfolio

Containerization is a per-application decision. For each app, ask:

Signal	Containerize	Leave it (for now)
Deploy frequency	Multiple times a week	A few times a year
Scaling pattern	Spiky, horizontal, autoscaling pays off	Flat, predictable
Copies/environments to run	Many	One or two
Current state	Stateless, config in env vars	Stateful, snowflake config
Team experience	Already ships containers to production	New to Docker/K8s
Value of iteration speed	Competitive edge	Stable, rarely touched

Mostly left column: containerizing earns its keep, faster deploys, denser packing, environment parity. Mostly right column, which describes a lot of internal line-of-business software, containerizing is effort you won’t get back. A payroll app deployed twice a year gains nothing from a Dockerfile.

The recommended sequence: migrate, stabilize, then containerize

1. Migrate first. Rehost or lightly replatform to get off the old infrastructure and capture the immediate wins, managed databases, real backups, multi-AZ resilience. This is the fast, low-risk path in the migration roadmap.
2. Stabilize. Run the migrated estate for a month or two. You now have real cloud metrics: actual utilization, actual cost per app, actual scaling behaviour.
3. Containerize selectively. With deadline pressure off and data in hand, containerize the apps the framework flagged, and only those.

The sequencing has a quiet advantage beyond risk isolation: containers built after migration are built against the real cloud environment, its networking, its IAM, its managed services, instead of a guess made from the data centre. And each project gets judged on its own merits, so a delay in the container work never threatens the migration date.

The exceptions, when containerize-first is right

Sometimes containerizing first is the small step:

• The app is already stateless and cleanly packaged. Wrapping a twelve-factor service in a container is an afternoon, and the image becomes the cleanest possible unit to migrate.
• Your team already operates containers in production. No new-tooling risk; the container platform may genuinely be your fastest path.
• The current deployment is unreproducible. If nobody can rebuild the server from scratch, a lift-and-shift just relocates the mystery. Forcing the app into a container is the documentation, sometimes the cheaper path even up front.
• You’re building new services during the migration anyway. Greenfield work should be born containerized (or serverless); there’s no legacy to untangle.

If you do containerize: you still don’t need Kubernetes

The second expensive assumption is that containers imply Kubernetes. They don’t:

Runtime	Ops burden	Right when
ECS/Fargate (AWS), Cloud Run (GCP), Container Apps (Azure)	Low, provider runs the control plane and hosts	A handful of services; most SMB/mid-market estates
Managed Kubernetes (EKS, AKS, GKE)	Real, upgrades, add-ons, ingress, node management	Many services, multiple teams, need the ecosystem
Self-managed Kubernetes	Heavy	Almost never the right first move

For most teams arriving from on-prem, the serverless-container tier is the honest recommendation: the container’s benefits without adopting a distributed system as a hobby. And for spiky, event-driven workloads, serverless functions can beat containers entirely.

FAQ

Do I need Kubernetes to move to the cloud?

No. Plenty of well-run cloud estates are plain VMs and managed services with no Kubernetes anywhere. Even if you want containers, you don’t need Kubernetes to run them, ECS/Fargate, Cloud Run, and Azure Container Apps run containers with a fraction of the operational overhead. Adopt Kubernetes because you have the many-services, many-teams problem it solves, not because it’s expected.

Is it better to containerize before or after migrating?

After, in most cases. Migrating first gets you off the old infrastructure and capturing wins (managed databases, backups, resilience) in months; containerizing selectively afterwards is judged on its own merits, with real cloud metrics to inform it. Doing both at once is the classic way a six-month migration becomes an eighteen-month one.

What does containerizing an application actually cost?

Per app, expect 1-4 weeks of engineering for a well-behaved service, Dockerfile, config externalization, CI pipeline, health checks, log/metric rewiring, and materially more for stateful or snowflake apps. If you adopt Kubernetes, add the platform itself: cluster setup, upgrades, and ongoing operations that realistically consume a large fraction of an engineer, indefinitely.

When is containerizing before migration the right call?

When it’s a small step, not a project: the app is already stateless and twelve-factor-ish, your team already runs containers well in production, or the current deployment is so broken that lift-and-shift would only relocate the mess. In those cases the container is the cleaner unit to move.

---

The right sequence depends on your apps, your team, and your deadline, and both over- and under-investing here are expensive in different ways. For a straight answer on what to containerize, what to lift-and-shift, and in what order, talk to a Webisoft cloud engineer. We’ll tell you where containers pay off for your estate and where they’d just cost you a year.