Is Migration Assistant right for you?

Whether Migration Assistant is right for you depends on your upgrade path, infrastructure complexity, and operational goals. This page will help you evaluate whether Migration Assistant fits your use case.

Migration Assistant addresses key limitations in traditional migration approaches. For example, if you’re upgrading across multiple major versions—such as from Elasticsearch 6.8 to OpenSearch 2.19—Migration Assistant enables you to complete the process in a single step. Other methods, like rolling upgrades or snapshot restores, require upgrading through each major version, often with reindexing at every stage.

Migration Assistant also supports live traffic replication, enabling zero-downtime migrations. This makes it a strong fit for environments where minimizing service disruption is critical.

Supported migration paths

The following matrix shows which source versions can be directly migrated to which OpenSearch target versions:

Supported platforms

Source and target platforms

• Self-managed (on premises or hosted by a cloud provider)
• Amazon OpenSearch Service (Amazon OpenSearch Serverless collections are not supported)

Supported AWS Regions

Refer to Supported AWS Regions for the full list of supported Regions.

Supported features

Before starting an upgrade or migration, consider the cluster feature to be included. The following table lists what can be migrated using Migration Assistant, whether it is currently supported, and recommendations for how to handle each component.

Checklist

Use this checklist to determine whether Migration Assistant is the right fit for your migration:

• Are you migrating across one or more major versions—for example, from Elasticsearch 5 to OpenSearch 3—in a single step?
• Are you upgrading but want the ability to safely back out, reducing the risk of data loss or service disruption?
• Do you need to maintain high service availability with minimal or zero downtime?
• Do you need to validate a new OpenSearch cluster before switching over—with rollback capabilities?
• Is your environment self-managed or running on Amazon OpenSearch Service?
• Are you looking for tooling to migrate index settings and other metadata?
• Do you need to reconfigure your target cluster—for example, by changing the sharding strategy and reindexing?
• Are you migrating across Regions, from on premises, or from another cloud provider?
• Do you need a high-performance backfill solution that can reliably reindex documents—with support for pause, resume, or checkpoint recovery?

If you answered “yes” to most of these questions, Migration Assistant is likely the right solution for your migration.

Migration Assistant assumptions and limitations

Before using Migration Assistant, review the following assumptions and limitations.

Networking and environment

Connectivity to AWS services and outbound internet access are required in order to build and deploy Migration Assistant. Requirements differ based on whether you’re deploying to a new or existing virtual private cloud (VPC).

Source and target connectivity

To meet connectivity requirements, ensure the following:

• You must establish connectivity between:
  • The source cluster and/or Amazon Simple Storage Service (Amazon S3) (for snapshots, which may only require updating the bucket policy) and Migration Assistant.
  • The target cluster and Migration Assistant.
• If the source or target resides in a private VPC without internet access, use one of the following to connect:
  • VPC endpoints
  • VPC peering
  • AWS Transit Gateway

Deploying to a new VPC

When deploying to a new VPC, consider the following:

• Migration Assistant provisions a new VPC with required components (for example, NAT gateway, subnets).
• You must establish network access from this VPC to both the source and target clusters.

Deploying to an existing VPC

When deploying to an existing VPC, consider the following:

• If deploying Migration Assistant to an existing VPC (for example, the same VPC as the source or target), you may need to configure connectivity to any cluster external to the target VPC.
  • For example, if Migration Assistant is deployed to the source VPC, you may need VPC endpoints or peering to reach the target.

• Ensure all required AWS services are reachable by Migration Assistant components.

  • If the VPC has outbound access using private subnets with a NAT gateway or public subnets with an internet gateway, then VPC interface endpoints are not required.

  • If using isolated subnets with no outbound access, you must configure VPC interface endpoints or routing to the following services:

    • Application Load Balancer (Capture and Replay only) – Used to optionally reroute client traffic from the source to the target during migration.
    • Amazon CloudWatch – Publishes migration metrics.
    • Amazon CloudWatch Logs – Ingests Amazon Elastic Container Service (Amazon ECS) task logs.
    • Amazon Elastic Compute Cloud (Amazon EC2) – Used to bootstrap Migration Assistant. When deploying using AWS CloudFormation, the bootstrap EC2 instance requires outbound internet access (using NAT gateway or an internet gateway) to download the latest version from GitHub.
    • Amazon Elastic Block Store (Amazon EBS) – Provides temporary disk storage.
    • Amazon Elastic Container Registry (Amazon ECR) – Pulls container images.
    • Amazon ECS – Orchestrates container workloads.
    • Amazon Elastic File System (Amazon EFS) – Stores persistent logs.
    • Amazon Managed Streaming for Apache Kafka (Amazon MSK) (Capture and Replay only) – Used as durable storage to capture and replay live HTTP traffic.
    • Amazon S3 – Stores and retrieves snapshots and artifacts.
    • Elastic Load Balancing (Capture and Replay only) – Used by the migration console to connect to the Application Load Balancer.
    • AWS Secrets Manager – Securely stores credentials when using basic authentication on the source or target.
    • AWS Systems Manager Parameter Store – Stores configuration parameters.
    • AWS Systems Manager Session Manager – Enables secure shell access to ECS tasks such as the migration console.
    • AWS X-Ray – Supports distributed tracing.
    • Amazon Virtual Private Cloud (Amazon VPC) – Ensures proper routing, DNS resolution, and endpoint configuration.

Reindex-from-Snapshot

To use Reindex-from-Snapshot (RFS), ensure the following:

• The _source field must be enabled on all indexes to be migrated. See Source.
• The source cluster must have the Amazon S3 plugin installed.
• If you choose to bring your own snapshot (that is, one not created by Migration Assistant), the following settings must be applied when creating the snapshot:
  • include_global_state: true – Ensures that global cluster state is included.
  • compress: false – Disables metadata compression, which is required for compatibility with RFS.
• Shards of up to 80 GiB are supported by default. Larger shard sizes can be configured, except in AWS GovCloud (US), where 80 GiB is the maximum.
• Snapshots using zstd compression are not supported for migration. If compression is needed, use the default LZ4 format instead.

Capture and Replay

Capture and Replay has the following requirements:

• The Traffic Capture Proxy must be deployed to intercept client traffic.
• Live capture is recommended only for workloads with < 4 TB/day of incoming traffic to the source cluster.
• Automatically generated document IDs are not preserved during replay. Clients must explicitly provide document IDs for index and update operations.