01
Cluster-to-Cluster Moves
A new cluster on the same provider, built to the target version and moved to in waves instead of an in-place upgrade.
Kubernetes Migration
Kubernetes Migration Services: Move Clusters, Platforms and Stateful Workloads on a Rehearsed Plan
Last reviewed by Tyler Eastridge
Kubernetes migration services move your workloads between clusters, regions, providers or Kubernetes versions, or from VMs or Docker Swarm onto Kubernetes, with the brokers and databases rehearsed before anything is cut over. Kubernetes 1.34 left upstream support on 27 October 2026, EKS standard support for it ends on 2 December 2026 and AKS support in November 2026, so the first deliverable is a written plan: what moves, in which order, and how each step is reversed. AceMQ engineers lead each engagement with partner Kubernetes specialists.
- phases, each ending in written sign-off
- 5
- to a reply on a quote request
- 1 hour
- AceMQ customers
- 160+
Is This You?
You probably need this if…
- 01
A cluster runs Kubernetes 1.34 or older, which upstream no longer patches
- 02
An EKS cluster has been enrolled in extended support by default and the charge is on the invoice
- 03
A new cluster is the safer upgrade path, but nobody has listed what has to move with it
- 04
Brokers, databases or caches run on persistent volumes that are tied to one provider, zone or storage class
- 05
Ingress NGINX, retired in March 2026, still sits in front of services that must be re-pointed anyway
- 06
Applications run on VMs or Docker Swarm and the platform team owns the move onto Kubernetes
Outcomes
Where you are now, and where you end up
Concrete state changes, not deliverable counts. This is what actually differs about your Kubernetes estate when the engagement closes.
Before
The move is described as "lift and shift", and nobody has listed the load balancers, storage classes, secrets, CRDs and DNS records the workloads depend on.
After
A written inventory of the Kubernetes resources a namespace needs from its cluster, with each item marked as moved, rebuilt or retired.
Before
Stateful workloads are the part nobody wants to touch, so they are left on the old cluster until the last day.
After
A data-movement method chosen per workload (replication, snapshot restore or application-level mirroring), rehearsed against a copy of production data.
Before
Cut-over means changing DNS on a Friday night and hoping.
After
Cut-over in waves, with traffic shifted in steps, health checks agreed beforehand and a rollback point written down for each wave.
Before
The old cluster runs on indefinitely, paying for extended support or a control plane nobody trusts.
After
A decommission checklist per wave: data verified, DNS and certificates moved, backups confirmed, then the source cluster retired.
Scope
What's covered
- 02
Provider-to-Provider Moves
EKS, AKS, GKE, OpenShift or self-managed Kubernetes to another of the same, across cloud providers, regions and accounts.
- 03
Stateful Workloads
RabbitMQ, Kafka, PostgreSQL and Redis moved with replication or snapshot restore, never with a copy of a live volume.
- 04
Ingress, DNS and Certificates
Controllers, Gateway API or Ingress resources, load balancers, certificate issuers and the order in which hostnames move.
- 05
Secrets, RBAC and Policy
Service accounts, role-based access control (RBAC) bindings, network policies, admission rules and the secret stores the cluster reads from.
- 06
VMs and Docker Swarm onto Kubernetes
The platform side of the move: namespaces, storage, ingress, observability and the runbook. Container images are taken as they are.
- 07
Version Migration and Upgrades
Upgrade paths across several minors, removed APIs found before the window, add-ons and node pools upgraded in the right order.
- 08
Validation and Rollback
Smoke tests, load checks, a parallel run for the critical paths and a rollback point for every wave.
The Engagement
How it actually runs
Every phase has a defined duration and a concrete artifact handed over at the end of it. You always know what stage you're in and what you've received.
- Phase 1Scoped per estate
Inventory and Decision
The entry point. We read what runs on the old platform, decide per workload whether it moves, is rebuilt or is retired, and set the order. You get the scope, the wave plan and a written quote before committing budget.
You receive
- Inventory of workloads, storage, ingress, secrets and CRDs
- Move, rebuild or retire decision per workload
- Wave plan and written quote
- Phase 2Agreed at inventory close
Target Platform
The target cluster designed before any workload moves: version, node pools, storage classes, ingress, network policy, identity and observability.
You receive
- Target architecture
- Storage and ingress design
- Landing-zone checklist
- Phase 3One stateless and one stateful workload
Rehearsal
One stateless service and one stateful service are moved end to end against a copy of production data. The rehearsal tests the design, corrects the estimate and writes the first rollback.
You receive
- Rehearsed workloads with timings recorded
- Data-movement method confirmed
- Revised wave plan
- Phase 4Per wave, set in the plan
Wave Cut-overs
Each wave runs beside the old cluster. Traffic moves in steps, the checks agreed beforehand run at each step, and the owner of the service signs the wave off.
You receive
- Workloads running on the target cluster
- Cut-over and rollback runbook per wave
- Sign-off record
- Phase 5After the last wave
Decommission and Handover
The source cluster is kept through the rollback window, then retired. Your engineers get the runbooks, the dashboards and the upgrade calendar for the new platform.
You receive
- Decommission checklist
- Runbooks and dashboards
- Upgrade calendar for the target cluster
Which Kubernetes migration do you need?
"Kubernetes migration" covers five different jobs. They share tooling and differ in what goes wrong, so a Kubernetes migration strategy starts by naming which one you have.
| Move | What changes | What usually causes trouble |
|---|---|---|
| New cluster, same provider | Control plane version, node images, add-ons and often the CNI or ingress controller. | Anything installed by hand in the old cluster that no manifest describes. |
| Provider to provider (EKS, AKS, GKE, OpenShift, self-managed) | Load balancers, storage classes and provisioners, identity integration, registry and network paths. | Persistent volumes are tied to the provider's storage, so data has to be copied by the application or restored from a snapshot, not moved as a volume. |
| Self-managed to managed, or back | Who runs the control plane, upgrade timing, add-on ownership and the cost model. | Custom admission, API server flags and etcd tuning that the managed service does not expose. |
| VMs or Docker Swarm onto Kubernetes | Scheduling, service discovery, config and secrets, storage, ingress and observability. | State kept on VM disks or Swarm volumes, and start-up order that Swarm or systemd handled implicitly. |
| Version migration across several minors | API versions, add-on compatibility and node pool images. | APIs removed between minors, found only when a manifest is applied. |
Docker Swarm is a choice, not a deadline. Mirantis said on 1 July 2025 that Swarm will be fully supported through at least 2030 as part of Mirantis Kubernetes Engine 3. We move teams onto Kubernetes when they want its ecosystem and operators, and we tell you when staying put is cheaper.
Why Kubernetes 1.34 is the date to plan around
Kubernetes upstream patches the three newest minor versions, about a year each. Hosted services add their own windows on top, and those windows decide how long an old cluster can safely wait. Dates below were read from each project and provider on 4 November 2026.
| Minor | Upstream patches end | EKS standard support ends | EKS extended support ends | AKS end of life | GKE standard support ends |
|---|---|---|---|---|---|
| 1.33 | 28 Jun 2026 | 29 Jul 2026 | 29 Jul 2027 | Jul 2026 | 12 Aug 2026 |
| 1.34 | 27 Oct 2026 | 2 Dec 2026 | 2 Dec 2027 | Nov 2026 | 25 Jan 2027 |
| 1.35 | 28 Feb 2027 | 27 Mar 2027 | 27 Mar 2028 | Mar 2027 | 11 Apr 2027 |
| 1.36 | 28 Jun 2027 | 2 Aug 2027 | 2 Aug 2028 | Jun 2027 | 9 Aug 2027 |
| 1.37 | 28 Oct 2027 | 1 Dec 2027 | 1 Dec 2028 | Oct 2027 | 22 Dec 2027 |
Amazon says EKS extended support is enabled by default, costs extra per cluster hour, and covers 12 months after standard support ends. As listed on AWS's EKS pricing page, read 4 November 2026, a cluster in extended support costs $0.60 per cluster hour against $0.10 in standard support, six times the rate, so a fleet left on an old minor pays that on every cluster. At the end of extended support EKS upgrades the control plane itself, at a time it does not announce. AKS runs three GA minors, and its Long Term Support option needs an opt-in and the Premium tier.
Extended support is a fair way to buy time for a planned move, and the plan should say how long you are buying. It is a poor place to live. A migration is worth pricing against it when you are changing the CNI, the ingress controller or the provider anyway, because a new cluster built on a current minor starts a fresh window.
Check before you plan
Ingress NGINX was retired in March 2026 and its repository archived on 24 March 2026. Clusters keep working, but receive no fixes. If it fronts your services, the ingress move belongs in the same plan as the cluster move.
How brokers and databases move between clusters
Stateless services move with a redeploy. Stateful ones need a data-movement method chosen for each, because persistent data lives on a persistent volume that belongs to one provider's storage and usually to one zone. This is the part of a migration where AceMQ's messaging and database engineers matter most.
| Workload | Method we usually weigh | What the rehearsal checks |
|---|---|---|
| RabbitMQ | A second cluster built on the target, with queues drained or mirrored through the Shovel or Federation plugins and clients re-pointed in steps. | Queue types and policies recreated, definitions imported, no messages lost or duplicated beyond what the consumers tolerate. |
| Kafka | A mirrored cluster using MirrorMaker 2, with consumers moved once their committed offsets have been translated. | Offset translation, topic configuration, ACLs and the order in which producers and consumers switch. |
| PostgreSQL | A streaming or logical replica on the target cluster, promoted at cut-over, or a restore from a base backup plus WAL. | Replication lag at the switch, extensions and roles present, and the old primary fenced so it cannot take writes. |
| Redis | A replica on the target promoted at cut-over, or a restore of an RDB snapshot for caches that can rewarm. | Persistence settings, client reconnect behavior and what the application does while the cache is cold. |
For a broker you can leave on its current platform, it is often safer to move the applications first and the broker last. The assessment says which order applies, and it says so before the first window.
What a rehearsed cut-over and rollback look like
A rollback you have not rehearsed is a guess. For every wave we write down the step that undoes it, and we run that step during the rehearsal.
- Before the window — Backup and restore tested on a spare namespace, a freeze on schema and manifest changes, and the checks that decide go or no-go written down.
- During the window — Traffic shifted in steps, such as a share of requests or one hostname at a time, with error rates and latency watched at each step.
- At the rollback point — A named person decides, using criteria agreed beforehand. The old cluster is still serving, so the decision costs minutes.
- After the window — A review of what the dashboards showed, a note of any deviation from the runbook and the next wave's plan adjusted.
Rule we hold
No wave is cut over until its rollback has been run once in the rehearsal, and the source stays available through the rollback window.
Version migration and upgrades
Moving up several minors at once is the other common reason for a new cluster. Each minor removes or changes APIs, and add-ons such as the CNI, CSI drivers and the ingress controller each have their own supported range. We list the APIs your manifests and Helm charts still use, check the API server's deprecated-API metrics on the old cluster, and order node pool and add-on upgrades so nothing runs outside its supported skew. Amazon now lets an in-place EKS upgrade be rolled back to the previous minor within 7 days of completing, which is worth knowing and still no substitute for a rehearsal.
Where this migration work stops
- Independent of the clouds — AceMQ does not resell cloud capacity or a Kubernetes distribution. AWS, Microsoft, Google and your other vendors bill you directly, and nothing on this page is vendor guidance.
- Applications are taken as they are — We move container images and manifests. Containerizing an application, changing its code or rewriting its Helm chart is not part of this service.
- Sign-off stays with you — The owner of each service decides when its checks are good enough and approves the wave.
Typical engagements
How these engagements run
Typical engagement scenarios: what the work covers and what it delivers. They describe the service, not past results.
Java Estate Inventory and OpenJDK Distribution Selection
Mid-Sized Distribution Company
A typical engagement for a company that wants to leave an Oracle Java SE subscription or avoid one: inventory every Java runtime, compare OpenJDK distributions against the estate, and write the migration plan.
JavaOpenJDK
Docker
KubernetesJava Services Killed by the Container Memory Limit After a JDK Upgrade
SaaS Platform Team
A typical engagement for Java services that restart with exit code 137 after a base image brings a newer JDK: the heap is not full, no OutOfMemoryError appears, and the memory that matters lives outside the heap.
JavaKubernetesDocker
Prometheus
Real-Time Manufacturing Data Ingestion Modernization
Global Automotive Manufacturer
Replacing fragile SQL-trigger-based ingestion with a reliable event-driven architecture for plant-floor data movement and low-latency operations.
RabbitMQMQTT
KafkaSQL ServerKubernetesStabilizing RabbitMQ on Kubernetes for Mission-Critical Airport Systems
Global Aviation Technology Provider
Troubleshooting cluster failover, partition handling, and quorum queue issues in a high-stakes aviation operational environment.
RabbitMQKubernetesQuorum QueuesPrometheus
GrafanaFrom Community to Supported RabbitMQ on AWS: Platform Modernization
Fortune 500 Software Company
Migration to supported RabbitMQ versions with managed services, standardization, compliance posture, and Tanzu commercial licensing.
RabbitMQTanzu RabbitMQ
AWSEKSKubernetesRabbitMQ Performance Remediation for Telecom-Scale IoT
Global Telecom Leader
Resolving weekly RabbitMQ crashes, optimizing for 300,000+ connected devices, and architecting horizontal scaling strategy.
RabbitMQKubernetesQuorum QueuesPrometheusGrafanaRabbitMQ Cluster Remediation and Windows-to-Linux Migration
Global Physical Security Company
Resolving leader election bugs and planning migration from Windows to Linux for a physical security platform.
RabbitMQWindows
LinuxKubernetesRabbitMQ Kubernetes Stabilization
Smart Home Security Platform
Hardening RabbitMQ in Kubernetes environments with StatefulSet tuning, quorum queue optimization, storage isolation, and memory/network configuration.
RabbitMQKubernetes
FAQ
Questions about Kubernetes migration
What do Kubernetes migration services include?
An inventory of what runs on the old platform, a target design, a rehearsal of one stateless and one stateful workload, migration in waves with a rollback point for each, and decommissioning. Moves between clusters, providers and versions, and from VMs or Docker Swarm onto Kubernetes, are in scope. Application code changes are not.
Should we upgrade in place or build a new cluster?
Both are sound. In-place upgrades suit a cluster that is a minor or two behind with add-ons that already match the target. A new cluster suits a jump across several minors, a change of CNI or ingress controller, or a move of provider or region, because the old cluster keeps serving until each wave has passed its checks. The inventory decides which, per cluster.
How do stateful workloads like RabbitMQ, Kafka or PostgreSQL move between clusters?
By replication or mirroring at the application layer, or by restoring a snapshot, not by moving a live volume. RabbitMQ can use Shovel or Federation, Kafka MirrorMaker 2, and PostgreSQL a streaming or logical replica promoted at cut-over. The method is chosen per workload and rehearsed against a copy of production data first.
Is migrating cheaper than paying for extended support?
Sometimes. AWS's EKS pricing page, read 4 November 2026, lists extended support at six times the standard cluster-hour rate, and it is on by default, so a fleet left on an old minor pays it on every cluster. If you are changing the CNI, ingress controller or provider anyway, a new cluster on a current minor ends the charge and starts a fresh support window. For one cluster that is two months from a planned upgrade, paying for a short extension can be the cheaper answer.
What does a Kubernetes migration cost and how long does it take?
Scope drives both: the number of clusters, how much state moves, how many ingress and identity changes are involved, and how many waves the plan needs. We do not publish a price list or quote a duration before seeing the estate. Send the source and target platforms and a rough count of clusters and stateful workloads, and we will reply within 1 hour and send a written quote.
Let's talk
Start with a Kubernetes Migration Assessment
Tell us the source and target platforms and a rough count of clusters and stateful workloads. We will scope the assessment, reply within 1 hour and send a written quote.
Get in Touch
Talk to a Kubernetes Expert
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.com66 W. Flagler St. 9th Floor
Miami, FL 33130
Miami, FL 33130
Prefer to talk now? Call us directly or use the consultation tab to find a time that works.