---
title: "Zero-downtime Kafka migration with Confluent Cluster Linking"
description: "Mirror live orders into a new cluster at identical offsets, sync the Kafka consumer offset 1:1, then promote the mirror and cut over with no reprocessing."
url: https://monedula.dev/kafka-simulator/scenarios/migrate-with-cluster-linking/
---

# Zero-downtime Kafka migration with Confluent Cluster Linking

Scenario 12.0.3 · Capstone: migrate a cluster with Cluster Linking, zero downtime. Capstones · Advanced · about 4 min · Apache Kafka 4.3 · Confluent Platform feature.

An offset-preserving cluster link mirrors a live topic into a new cluster keeping identical offsets, syncs the consumer’s committed offset 1:1, then promote_mirror cuts over - the consumer resumes at the same offset on the new cluster with no reprocessing.

Run it: https://monedula.dev/kafka-simulator/playground/?scenario=12.0.3

## What you start with

A zero-downtime cluster migration with Confluent Cluster Linking. An offset-preserving link mirrors a live `orders` topic into a new cluster byte-for-byte at identical offsets (carrying no offset-translation table), and the link’s checkpoint syncs the consumer’s committed offset 1:1. Then promote_mirror flips the read-only mirror to a writable topic and cuts the consumer over.

## Step by step

1. **Old cluster live - cluster link to new** (t+0.000s): The `old` cluster serves orders; the `new` cluster is the migration target. A Cluster Link (offset-preserving) is armed from old → new. The consumer g1 reads + commits on the old cluster. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=12.0.3&t=0)
2. **Mirrored at identical offsets** (t+0.700s): O1..O3 are produced on old and g1 drains them. The cluster link copies them byte-for-byte into new at the SAME offsets - old.orders on the new cluster is a read-only mirror whose offsets match the source exactly (no translation table). [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=12.0.3&t=1)
3. **Committed offset synced 1:1** (t+1.100s): The offset-sync checkpoint copies g1's committed offset onto the link as-is (identity) - because dest offset == source offset, there is nothing to translate. The new cluster now knows exactly where the consumer is. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=12.0.3&t=2)
4. **Cutover - promote_mirror, no reprocessing** (t+1.900s): promote_mirror flips old.orders from a read-only mirror to a writable topic and detaches the link. Migration is complete: the consumer can resume on the new cluster at the identical committed offset, so it reprocesses nothing and skips nothing - zero-downtime cutover. [Open at this step](https://monedula.dev/kafka-simulator/playground/?scenario=12.0.3&t=3)

## The takeaway

Because the link preserves offsets and syncs committed positions 1:1, “resume where you left off” is the identical position on the new cluster - a cutover with no reprocessing and no gap, unlike MM2 which re-produces records and must translate offsets.

## Further reading

- [Confluent documentation](https://docs.confluent.io/platform/current/multi-dc-deployments/cluster-linking/index.html)