Migrations & Upgrades

Migration work rewards a specific temperament: inventories before restarts, rehearsals before production, parallel runs before cutovers, and a rollback story at every step until the point of no return — which gets named in writing before anyone reaches it.

What we migrate

• Broker version upgrades — multi-hop upgrade paths from aging 2.x and 3.x estates to current versions, protocol and client compatibility checks, coordinated client upgrades where needed.
• ZooKeeper to KRaft — the full sequence: dependency inventory, controller quorum sizing, staging rehearsal against a metadata snapshot, dual-write migration mode, a deliberately long observation window, and finalization only when the evidence is in.
• Self-managed to MSK or Confluent — and back — we are vendor-neutral and have moved teams in both directions. The deliverable includes the honest cost and capability comparison for your workload, not a foregone conclusion.
• Cross-cluster and multi-region — MirrorMaker 2 and replicator-based topologies, offset translation for consumer cutover, active-passive failover design and the failback plan nobody writes until they need it.

The method

1. Inventory — every client, connector, ACL, quota, and script that touches the cluster. Migrations fail on the forgotten cron job, not the broker binary.
2. Rehearsal — the procedure runs in staging against realistic metadata and load before it runs anywhere that matters.
3. Parallel run — old and new paths run together with reconciliation checks wherever the migration allows it.
4. Instrumented cutover — cutover windows with explicit go/no-go criteria, live metrics, and a tested rollback until the named irreversible step.

The success criterion is boredom: a migration your engineers describe afterwards as uneventful.