Kubernetes migration assessment

For operators of legacy applications: J2EE, WebLogic, Docker Swarm, VM monoliths. Often a cutover leadership will only accept with a written risk brief.

Wrong fit for greenfield with no existing system, or if you only need a cluster workshop.

What you get

• Current-state review of the application and operations
• Target architecture sketch
• Cutover strategy
• Risks and effort estimate
• A brief leadership or IT can take into the decision

Five days

1. Day 1: Current state, dependencies, deploy path, who owns cutover
2. Day 2: Target architecture. What stays, what moves, what dies
3. Day 3: Cutover. Strangler, dual run, rollback
4. Day 4: Risks, effort, operating model after handover
5. Day 5: Decision brief and readout

What I inspect

The same order as the government migration: read the estate, sketch the target, cut over in phases, then hand over. Numbers from that project: zero downtime, rollout from one day to 20 minutes. The assessment delivers the brief, not the migration.

Sample finding

Example (anonymized): a Swarm cluster with 20+ tenants, deploys by hand. A big-bang cutover would have hit every instance at once. The brief was: tenant by tenant, automated rollouts, rollback per instance.

Afterwards

Current state, target, cutover, risks, effort. At the end, a brief you can take into internal discussions.

You can decide internally whether to run the migration, and with whom. You do not have to stay with me.

Questions I get

Background

• Lessons learned from the government project
• Case: government application
• Cloud and Kubernetes