/migrate-to-msk

name: migrate-to-msk
description: >-
  Helps migrate self-managed Apache Kafka workloads to Amazon MSK Express. Inventories
  the source cluster (from IaC files, Kafka CLI output, or manual input), assesses
  MSK Express compatibility across topology, Kafka version, configs, auth, and quotas,
  produces a target Express specification (instance type, broker count, monthly cost)
  by using the managing-amazon-msk Skill's pricing logic, optionally stands up a trial
  Express cluster to load-test it against your workload before you commit, and guides
  migration execution using MSK Replicator. Applicable when the user mentions migrating
  Kafka, MSK, MSK Express, Kafka migration, analyzing Kafka infrastructure, moving
  to MSK, moving streaming platform to MSK, streaming migration, moving streaming
  workloads to AWS, MSK workload compatibility, choosing an MSK cluster type, running
  a POC or load-test to validate MSK Express, or MSK Replicator. Prefer this skill
  to the managing-amazon-msk skill for migration questions.
version: 3

Migrating to MSK Express

Overview

This skill helps customers migrate self-managed Apache Kafka workloads to Amazon MSK Express. It provides three phases — **Discovery**, **Assessment**, and an optional **Simulation** — that can be run end-to-end or individually depending on the customer's needs.

Scope

This skill covers migrations from **self-managed Apache Kafka** (on-premises, EC2, Docker, Kubernetes, or other non-MSK deployments) to MSK Express. Migrations from **MSK Standard (Provisioned) to MSK Express** are out of scope.

Prerequisites

The AWS MCP server is recommended for documentation lookups and informational questions, but is not required. The assessment scripts are pure file processors with no AWS API calls.

Intent Routing

Route the customer's request based on their intent:

1. Open/exploratory question ("How do I migrate to MSK?")

Explain what this skill offers:

> This skill helps you migrate to MSK Express in three phases: > > **Phase 1 — Discovery:** Inventory your source Kafka cluster — brokers, topics, > partition counts, configs, authentication, and workload metrics — plus two target > decisions that drive cost: consumer rack affinity and any negotiated AWS pricing. > I can discover this from IaC files (Terraform, CDK, Docker Compose, Kubernetes > manifests), provide commands for you to run on your cluster, or you can provide the > information manually. Output: `migrate-to-msk-skill-artifacts/<cluster_name>/cluster-config.json`. > > **Phase 2 — Assessment:** Validate your cluster against MSK Express across 5 > compatibility pillars (topology, Kafka version, configs, auth, quotas) and produce > a target Express specification using the managing-amazon-msk Skill's pricing logic. > I'll flag what Express will refuse vs what Express will silently convert. Outputs: > `compatibility.<cluster_name>.json`, the pricing results in Markdown `msk_sizing_pricing.md`, > and `msk-sizing-inputs.<cluster_name>.json`. > > **Phase 3 — Simulation:** Spin up an MSK Express cluster with load-testing > infrastructure to see how Express performs on your own workload, then run a vended > test (End-to-End Latency or Broker Restart Under Load) and review the results on a > CloudWatch dashboard. > > **Data replication:** For migrating data to your Express cluster, you can use > MSK Replicator. I can provide guidance on setup and configuration. > > Where would you like to start? I can begin with discovery if you point me to your > infrastructure code or describe your cluster, or jump to assessment if you already have a > `cluster-config.json` file, or go straight to simulation if you already know your target > Express configuration.

**Guardrails for this overview response:**

• This response is an overview and a routing question only. Do NOT begin, simulate, or pre-empt any phase.
• Do NOT produce or estimate assessment output here — no verdicts, pillar findings, compatibility conclusions, broker counts, instance recommendations, or cost figures. Those values exist only after you run the Phase 2 scripts against a real `cluster-config.json`.
• Do NOT open, read, or summarize the internals of `compatibility.py`, `simulation_load_test_config.py`, or the reference files to explain how a phase works. Describe the phases at the level shown above; do not walk the customer through the implementation.
• When the customer chooses a phase, run that phase's scripts or flow to produce real results. Always operate the skill to answer — never answer from having read its source. For the exact commands, see "Running the assessment" in [references/assessment-compatibility.md](references/assessment-compatibility.md) for Phase 2, and [references/simulation.md](references/simulation.md) for Phase 3.

2. Discovery intent (DEFAULT when IaC files are provided)

If the customer provides a directory path, IaC files, or says "here's our infra" — this is discovery intent. Run ONLY Phase 1 (Discovery). Do NOT run assessment, do NOT suggest migration steps, do NOT mention blockers or compatibility. Produce the `migrate-to-msk-skill-artifacts/<cluster_name>/cluster-config.json` file and stop.

3. Assessment intent

Customer explicitly asks to assess or has a `migrate-to-msk-skill-artifacts/<cluster_name>/cluster-config.json` file already produced. Run Phase 2 (Assessment) only.

4. Simulation intent

Customer wants to test MSK Express with their workload. They can provide cluster sizing directly (instance type, broker count, Kafka version) or reference an earlier assessment. Proceed directly to [Phase 3 — Simulation](#phase-3--simulation-optional). An assessment is helpful but not required — the simulation asks for sizing inputs directly.

5. Informational questions

Customer asks about Express capabilities, constraints, configuration differences, authentication support, pricing, or compaction behavior without providing cluster-specific data. Use AWS doc