Migrating to Kubernetes without stopping the business

Decide whether the migration is justified

A single application, deployed once a month on a server that handles the load, does not need an orchestrator. The benefit appears when several services must coexist, deploy independently, scale separately and survive the loss of a machine.

The real cost is not the cluster: it is the skill needed to operate it on a Sunday. If nobody on the team can read a scheduling event or diagnose a crash loop, the migration moves the risk rather than reducing it.

Start with the inventory of hidden dependencies

What breaks during a migration is almost never the application code. It is the implicit assumptions about the environment: a file written to the local disk, a job in the server crontab, mail sent through a local relay, an IP address allow-listed by a partner.

• Writes to local disk, which vanish when a container restarts.
• Scheduled jobs that must become declared resources, not duplicated ones.
• Sessions stored in memory, incompatible with several replicas.
• Outbound IP addresses filtered by partners, which change with the cluster.

Migrate by environment, not by service

First rebuild a complete staging environment on the new foundation, even an imperfect one. It reveals configuration differences far better than a service-by-service migration, where each piece seems to work in isolation.

Treat configuration as code: one source of truth, versioned, with explicit differences between environments. A change applied by hand on a cluster is debt that will be paid at the next deployment, when it gets overwritten.

Switch traffic progressively

The switchover is prepared as three independent levers: traffic, data and scheduled jobs. Switching them together turns a minor incident into a full outage; separating them lets you roll back just one.

1. Let both environments coexist, read-only, on the same data.
2. Switch part of the traffic and watch application errors, not only HTTP codes.
3. Switch the writes once the journeys are verified end to end.
4. Move the scheduled jobs last, after stopping the old ones.

Keep a real way back

A rollback only exists if it has been tested and if the data stays compatible. An irreversible schema migration applied too early removes that option, often without anyone noticing.

Keep the old environment in working order for a few weeks. It is not a lack of confidence: it is what lets you switch on a Tuesday morning rather than a Saturday at midnight.

A successful migration is measured by what did not happen: no customer call, no lost order, no Saturday spent putting the system back on its feet.