View a Migration Plan

When you open a migration plan from the Migration Plans tab on the Dashboard, the suite displays detailed guidance and outputs organized across several tabs. Each tab focuses on a different aspect of the migration.

Overview Tab

The Overview tab provides a high-level summary of the plan.

Key information displayed:

• Source cluster type
• Target cluster type
• Environment type (Production or Non-Production)
• Migration scope summary
• Recommended migration tool
• Reason for the recommendation
• Alternative tools
• Key migration notes

From this tab, you can initiate job creation directly by clicking Create Migration Job.

---

Gateway Tab

The Gateway tab presents the architecture overview and a checklist-driven implementation plan for deploying the gateway.

Deployment Workflow

1. Prepare Configuration

   • Review the generated gateway.yaml and replace any placeholder values with your environment-specific settings.
   • Store TLS certificates in the /ssl directory.
   • Create a DNS wildcard record pointing to the gateway domain.

2. Deploy Gateway

   • Run docker compose up -d to start the gateway.
   • Validate that Prometheus metrics are available on port 9190.
   • Verify that the gateway can connect to both the source and destination clusters.

3. Repoint Applications

   • Update bootstrap.servers in your application configurations to point to gateway:19092.
   • Swap the active configuration to gateway-cutover.yaml.
   • Test produce and consume operations through the gateway.

4. Monitoring

   • Import prometheus-scrape.yaml into your monitoring stack for ongoing performance tracking.

---

Network Tab

The Network tab consolidates all networking details relevant to the migration.

Networking Summary

Field	Description
Source	Network type, region, and access configuration for the source cluster
Destination	Network type, region, and access configuration for the destination cluster
Trust Boundary	How traffic crosses between source and destination networks
Security Protocols	Encryption and authentication mechanisms in use

Required Ports

Category	Purpose
Data	Ports used for Kafka broker communication and data replication
Management	Ports for administrative APIs and cluster management
Monitoring	Ports for metrics collection and health checks

Setup Tasks

• Provision and install TLS certificates.
• Configure load balancers for gateway or broker endpoints.
• Enable encryption in transit for all data paths.

Verification Checks

• DNS resolution from all relevant hosts.
• Bidirectional network reachability between source, destination, and gateway.
• Successful TLS handshake confirmation.

Connectivity Warnings

The suite surfaces warnings for conditions that may affect the migration:

• Bandwidth and egress cost implications for cross-cloud or cross-region traffic.
• Latency concerns that could impact replication lag or consumer group synchronization.

---

Cutover Tab

The Cutover tab provides a detailed migration strategy tailored to your plan inputs. For Gateway-Assisted migrations, this tab emphasizes zero-downtime procedures with at-least-once delivery guarantees.

Core Procedure

1. Route Redirection: The gateway instantly redirects traffic from the source cluster to the destination cluster. No application restarts are required.

2. Integrity Management: Prepare for potential duplicate messages during the transition window. Implement application-side idempotency where strict deduplication is required.

3. Decommissioning: After validation confirms that all workloads are running against the destination cluster, retire the source cluster.

Specialized Guides

Producers and Consumers

When using Gateway-Assisted migration, producers and consumers do not need connection string changes. The gateway transparently routes traffic to the active cluster.

Kafka Connect

Export existing connector configurations from the source Connect cluster. Redeploy connectors against the destination cluster or through the gateway, depending on your deployment model.

Rollback Steps

The Cutover tab includes a four-step contingency plan for rolling back the migration:

1. Redirect the gateway back to the source cluster.

2. Verify that all producers and consumers have reconnected to the source.

3. Validate message integrity and consumer group offsets on the source cluster.

4. Investigate the root cause before reattempting cutover.

---

Applications Tab

The Applications tab displays discovered and refreshed application dependencies tied to the source cluster.

Sections include:

• Consumer Groups: Groups consuming from source topics, with lag and membership details.
• Schemas: Schema subjects registered in the source Schema Registry.
• Producers: Applications producing to source topics.
• Connectors: Kafka Connect connectors interacting with the source cluster.

Tip

Application data can be refreshed from this tab to capture any changes made since the plan was created.

---

Assets Tab

The Assets tab serves as a centralized resource hub with downloadable artifacts generated from the plan.

Available downloads:

Asset	Description
Exported Plan Data	Full plan configuration in a portable format
Cost Report	Estimated costs for the migration based on scope and infrastructure
Application Inventory	Export of discovered applications, consumer groups, and producers
Connector Inventory	Export of Kafka Connect connectors associated with the source cluster
Schema Inventory	Export of schema subjects and compatibility settings
Gateway Assets	Gateway configuration files, TLS templates, and Docker Compose or Kubernetes manifests
Infrastructure Assets	Network diagrams, port mappings, and setup checklists
Terraform Packages	Pre-generated Terraform modules for provisioning destination infrastructure

---

Create a Job from the Plan

Once you have reviewed the plan and are satisfied with the guidance, you can create a migration job directly from the plan.

1. Open the plan from the Migration Plans tab.

2. On the Overview tab, click Create Migration Job.

3. The suite opens the job creation flow with plan inputs pre-applied to the configuration.

4. Review and refine the job settings as needed.

5. Submit the job to begin execution through the standard migration workflow.

Caution

Plan inputs provide a starting point for job configuration. Review all pre-filled values before submitting, as cluster credentials and runtime settings may require updates.