How to migrate an application to Kubernetes comes down to 12 steps in a fixed order, from the first application to the runbooks after cutover. Each step ends in a test, so you finish when the tests pass and a rollback path exists, not when a date arrives.
Last reviewed 2026-11-14 by Manish Sharma.
Kubernetes is an open-source system that runs containers across a group of machines and restarts them when they fail. A container image is the packaged application with everything it needs to start, while a manifest is the file that tells Kubernetes what to run and how. The steps are provider-neutral and carry no prices and no tool vendors, and clusters may run on AWS, Azure or your own servers.
How to Migrate an Application to Kubernetes: 12 Steps at a Glance
The table lists each step with a suggested owner and the test that marks it finished. The owners are our recommendation, but your team may split them differently. Work through the 12 steps in order for one application before starting a second.
| Step | Suggested owner | Done when |
|---|---|---|
| 1. Pick the first application | IT head | The owner agrees in writing and a cutover window is named |
| 2. Map dependencies, configuration and state | Application lead | Nothing the application touches is missing from the map |
| 3. Build a small, patched image | Application team | The image builds from the repository on a clean machine |
| 4. Move configuration and secrets out | Application team | No password sits in the image or the repository |
| 5. Add health checks and run locally | Application team | The application starts, answers and stops cleanly in a container |
| 6. Push to a private registry | Platform lead | Kubernetes pulls a tagged image with no manual step |
| 7. Write manifests or packaging | Platform lead | A fresh test cluster runs the application from the repository alone |
| 8. Set requests and limits | Platform lead | Settings match measured use, with a review date |
| 9. Deploy to a test cluster | Platform lead | The exit test written beforehand passes |
| 10. Move data and storage | Data owner | A trial copy matches and the final copy fits the window |
| 11. Cut over with a rollback path | Business owner | Traffic runs on Kubernetes and the rollback steps are written |
| 12. Hand over with runbooks | Application lead | Each runbook has an owner and a review date |
Before You Migrate an Application to Kubernetes: Rehost or Rework First
The first decision is how much of the application changes before the move. Rehosting packages the application as it is and changes only what Kubernetes needs: configuration from outside, health checks and logs sent to standard output. Reworking splits or changes parts first, as the application keeps state on local disk, needs a fixed machine name or keeps sessions in memory.
Four questions decide it. Does the application restart cleanly? Where does it write files? How is it scaled today? Who still knows the code? If the application restarts cleanly and keeps no local state, rehost it, but a no to either points to reworking that part. To move an application to Kubernetes with the least change, rehost the parts that pass and rework only the parts that fail.
For whether an old application should change at all, read deciding whether an old application should change first. For the work clusters bring after go-live, see the upkeep clusters need once the application is live. The choice of platform model is a separate topic.
The application team does the work, while the business owner signs off the cutover.
A step ends when its done-when test passes, not when a date arrives.
Migrate an Application to Kubernetes, Steps 1 to 4: Choose, Map, Build and Configure
The first four steps decide what moves and package it. They need no cluster yet, because nothing here touches production.
Choose one that matters but is not business-critical.
List everything the application touches in one table.
Keep the build file in the repository.
Keep passwords out of the image and the repository.
Before the build starts, confirm that you can migrate an application to Kubernetes without waiting on a rewrite, as the rehost or rework answer sets the scope.
Step 1: Pick the First Application
Pick one application that matters but is not business-critical. It should have few dependencies, a clear owner and room to stop briefly during the switch. A first move on the payroll system or the main order system, however, teaches a team under the wrong pressure.
Done when the owner agrees in writing and a cutover window is named. Record why you picked this application, because that reasoning guides the second.
Step 2: Map Dependencies, Configuration and State
List every database, queue, file share, outside service and scheduled job the application uses. List every setting and where it lives, and every place the application writes data. Then fill one table.
| Item | Where it lives today | Where it lives after the move |
|---|---|---|
| Orders database | Database server in the data center | Stays put, reached from Kubernetes |
| Uploaded files | Local disk on the server | A shared storage volume |
| Nightly report job | Scheduler on the server | A scheduled Kubernetes job |
Done when nothing the application touches is missing from the table. A missing row here is the usual cause of a failed first test, because the test finds the dependency nobody listed.
Step 3: Build a Small, Patched Image
To containerize an application, write an image build file in the repository. Start from a small base image, run one process per container and rebuild each time the base image gets a patch. Package the result in the OCI image format, which runtimes such as containerd read.
Keep the build file next to the code, so reviewers see a change to either together. Scored image checks are a separate topic. Done when the image builds from the repository on a clean machine.
Step 4: Move Configuration and Secrets Out of the Image
Use the same image for test and production, and pass settings in from outside, so a change of environment never means a rebuild. Settings go in ConfigMaps or environment values. Passwords and keys, however, go in Kubernetes Secrets or a cloud secret store on AWS or Azure, and the team decides who can read them. Kubernetes stores a Secret unencrypted by default, so turn on encryption at rest and limit who can read it. The Kubernetes Secrets documentation explains the risks; it and the two other Kubernetes pages linked below were checked on 14 November 2026.
Done when no password sits in the image or the repository.
Turn on encryption at rest and limit who can read each Secret.
Migrate an Application to Kubernetes, Steps 5 to 8: Health Checks, Registry, Manifests and Sizing
Steps 5 to 8 make the image runnable, stored and sized. Run them on a laptop or build server and a test cluster instead of production. Each ends with something a second person can check.
Step 5: Add Health Checks and Run It Locally
Kubernetes asks three questions of a container. Readiness: is it ready for traffic? Liveness: is it stuck and in need of a restart? Startup: is it still starting slowly, so the other two checks should wait? Add an endpoint or command for each, then run the container with the real settings.
The Kubernetes probe guide lists the options. Done when the application starts, answers and stops cleanly in a container.
Step 6: Push to a Private Registry
Use one private registry that Kubernetes pulls from, and control who can push to it. Tag each image with a release, not “latest”, so a deployment points at one known build. To move containers to Kubernetes in a repeatable way, a release pipeline should build and push each image; see a release pipeline that builds and pushes each image.
Done when Kubernetes pulls a tagged image with no manual step.
Step 7: Write Manifests or Packaging
A Deployment runs the container, a Service gives it a stable address, and the settings from Step 4 then attach to both. Keep one set of files per environment, and keep them in the repository, where reviewers read them like code. Helm and Kustomize are open-source ways to keep one set of files across environments.
Done when a fresh test cluster runs the application from the repository alone.
Step 8: Set Requests and Limits From Measured Use
A request tells Kubernetes how much CPU and memory a container needs. A limit caps use: Kubernetes slows a container at its CPU cap and can kill one that passes its memory limit. Set requests from measured use on the current servers or the local run, not from a guess. The Kubernetes resource management page covers both, and see sizing workloads from measured use.
Review the settings after the first week of real load, because real traffic differs from a test. Done when settings match measured use, with a review date.
Migrate an Application to Kubernetes, Steps 9 to 12: Test Cluster, Data, Cutover and Runbooks
The last four steps put the application in a cluster, move its data and hand it over. They carry the risk, so each has a written test before it starts.
Step 9: Deploy to a Test Cluster
Use the same Kubernetes version and settings as production, and real test data. Restart a node and kill a pod on purpose, then watch recovery. Also check logs and alerts. The loop is: deploy, break on purpose, check recovery, fix, run the exit test.
Write the exit test before the run, not after. Done when that test passes.
Write the exit test before the first deploy, so the result cannot be bent to fit.
Step 10: Move Data and Storage
Decide per data store, because the options differ. It may stay where it is and the application connects to it, move to a cloud database service, or run inside Kubernetes on persistent volumes. Write a copy and sync plan, and time the final copy so it fits inside the cutover window.
Before you choose the target region, ask your firm’s compliance or legal owner where this data may live. Done when a trial copy matches and the final copy fits the window.
Step 11: Cut Over With a Rollback Path
Move traffic in stages, a small share first and then all of it, or switch once in a quiet window. Keep the old servers running until the owner signs off. Write the rollback trigger and the rollback steps before the day, and let the owner make the go or no-go call.
Done when traffic runs on Kubernetes and the team has written the rollback steps.
Step 12: Hand Over With Runbooks
Write a runbook for a failed deploy, a stuck pod, a full disk and a secret change. Give every runbook an owner, list the alerts that page someone, and book a review one month after go-live. Finally, choose the next application from what this one taught.
Done when each runbook has an owner and a review date.
Key Takeaway The move ends when the tests pass, a rollback path exists and each runbook has an owner.
Five Move Mistakes When You Migrate an Application to Kubernetes
Five mistakes recur in first moves, but each is cheap to catch early.
- State left on the container’s own disk, so a restart loses it.
- Secrets built into the image, where anyone with the image can read them.
- No readiness check, so traffic reaches a pod that is still starting.
- Requests guessed instead of measured, so containers starve or sit idle.
- Old servers switched off on cutover day, leaving no way back.
Key Takeaway The five mistakes above trace back to state, secrets, health checks, sizing and a missing way back.
What This Guide to Migrate an Application to Kubernetes Leaves Out
Some work, however, sits outside these steps. Running clusters after go-live, scored security checks and the choice of platform model are each a separate topic. The guide named above covers changing an application in general, and prices are out of scope.
For how Signisys works with client teams on this, see how Signisys plans and runs container platforms for client teams. Help fits when the first application, its dependencies or its data need an outside read.
Signisys provides these services: see our solution for modernizing and observing applications and DevOps support for moving and releasing applications. A working session reads your first application, its dependencies and its data against the 12 steps, with no promised result and no price. No charge, with a fixed scope.
Migrate an Application to Kubernetes: FAQ
How long should the old servers keep running after cutover?
Do we need to rewrite the application before we move it?
Who should own the application once it runs on Kubernetes?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.