Choose your deployment
Migration Assistant always runs on Kubernetes. The primary decision is how much platform configuration you want the tooling to automate.
Deployment types
The following table compares the two deployment types.
| Type | Best when | Included |
|---|---|---|
| Deploy on Kubernetes | You already operate a Kubernetes platform, you are not on AWS, or you are evaluating locally | The core Migration Assistant engine and workflow model, with you supplying the platform integrations |
| Deploy on Amazon Elastic Kubernetes Service (EKS) | You are on AWS and want the recommended production path | The same engine plus AWS bootstrap automation, pod identity, image mirroring, snapshot helpers, and CloudWatch integration |
Both paths install the same Migration Assistant Helm chart. The difference is how much of the surrounding environment is prepared for you.
Default components
The following table describes the components that the Migration Assistant Helm chart installs.
| Component | Purpose |
|---|---|
| Migration Console | Pod with CLI tools for configuring and running migrations |
| Workflow Engine | Orchestrates migration tasks (Argo Workflows) |
| Strimzi | Kafka operator for Capture and Replay |
| Prometheus-compatible metrics | Metrics collection and platform observability integration |
Source and target cluster configuration is handled dynamically through the Workflow CLI, not through large Helm value files.
Why Amazon EKS is recommended on AWS
On AWS, Amazon EKS is the recommended path because it removes a large amount of non-migration work:
- Cluster and VPC bootstrap.
- Pod identity for AWS API access.
- Private image support for isolated subnets.
- Snapshot bucket and role helpers.
- CloudWatch dashboards and logging.
- AWS-aware storage and node-pool defaults.
This approach reduces platform configuration effort and allows you to focus on validating the migration.
Prerequisites
All deployment paths require:
- Kubernetes cluster: Version 1.24 or later.
- Helm 3: Installed and configured
kubectl: Configured to access your cluster.- Network access: Connectivity from the cluster to source and target clusters.
Use Deploy on Kubernetes if you are bringing your own Kubernetes platform.
Use Deploy on Amazon EKS if you want the AWS production path that the rest of the new Migration Assistant documentation assumes by default.
Previous phase
The previous phase in the migration process was:
Next phase
The next phase depends on your migration scenario:
- Scenario 1: Backfill only: Migrate metadata
- Scenario 2: Live capture only: Reroute traffic from the source to the Capture Proxy
For a complete overview of all migration phases, see Migration phases.