We use essential cookies and similar tools that are necessary to provide our site and services. We use performance cookies to collect anonymous statistics, so we can understand how customers use our site and make improvements. Essential cookies cannot be deactivated, but you can choose “Customize” or “Decline” to decline performance cookies.
If you agree, AWS and approved third parties will also use cookies to provide useful site features, remember your preferences, and display relevant content, including relevant advertising. To accept or decline all non-essential cookies, choose “Accept” or “Decline.” To make more detailed choices, choose “Customize.”
Customize cookie preferences
We use cookies and similar tools (collectively, "cookies") for the following purposes.
Essential
Essential cookies are necessary to provide our site and services and cannot be deactivated. They are usually set in response to your actions on the site, such as setting your privacy preferences, signing in, or filling in forms.
Performance
Performance cookies provide anonymous statistics about how customers navigate our site so we can improve site experience and performance. Approved third parties may perform analytics on our behalf, but they cannot use the data for their own purposes.
Allowed
Functional
Functional cookies help us provide useful site features, remember your preferences, and display relevant content. Approved third parties may set these cookies to provide certain site features. If you do not allow these cookies, then some or all of these services may not function properly.
Allowed
Advertising
Advertising cookies may be set through our site by us or our advertising partners and help us deliver relevant marketing content. If you do not allow these cookies, you will experience less relevant advertising.
Allowed
Blocking some types of cookies may impact your experience of our sites. You may review and change your choices at any time by selecting Cookie preferences in the footer of this site. We and selected third-parties use cookies or similar technologies as specified in the AWS Cookie Notice.
Your privacy choices
We display ads relevant to your interests on AWS sites and on other properties, including cross-context behavioral advertising. Cross-context behavioral advertising uses data from one site or app to advertise to you on a different company’s site or app.
To not allow AWS cross-context behavioral advertising based on cookies or similar technologies, select “Don't allow” and “Save privacy choices” below, or visit an AWS site with a legally-recognized decline signal enabled, such as the Global Privacy Control. If you delete your cookies or visit this site from a different browser or device, you will need to make your selection again. For more information about cookies and how we use them, please read our AWS Cookie Notice.
Migration Assistant for Amazon OpenSearch Service assists you in migrating or upgrading your Elasticsearch and OpenSearch workloads to Amazon OpenSearch Service managed clusters or serverless collections. This AWS Solution automates manual tasks with a low-risk and prescriptive migration path for existing and live data. It also includes advanced features, such as a metadata migration tool and capture and replay comparison tooling to help you identify potential migration and upgrade issues earlier. The migration process is streamlined, performance and behavioral comparisons based on real customer workloads are enabled, and the pre-migration, migration, and validation phases are accelerated.
This solution prescribes a systematic migration workflow to upgrade, migrate, recover, and modify an OpenSearch Service cluster. The workflow includes a migration console command line interface (CLI) for management, a dedicated scaling group for existing data backfill, and a replayer to synchronize live traffic between source and target clusters. Users can pause or abort the migration without affecting production traffic, thereby reducing risk. Additionally, the backfill functionality minimizes further risk by retrieving data from a snapshot, leaving the source cluster unaffected, and supporting multi-hop migrations, which decreases the overall number of migrations required.
Benefits
Simplified management experience
Transfer data from an originating (source) cluster to a designated target (OpenSearch Service cluster or OpenSearch Serverless Collection).
Adaptable, low-risk migration
Safely capture and replay traffic on source and target clusters to identify optimal performance while reducing migration risk through abort capabilities, comparison tools, source preservation, and multi-hop support.
Centralized location for data analysis
Record requests and responses between the source and destination clusters for comparison, then forward the latency metrics and response codes to an analytics hub. You can analyze the data essential for transitioning your traffic from a legacy system to a new OpenSearch Service destination.
Step 4 After a backfill has been completed, the captured traffic is replayed by the user with a Traffic Replayer.
Step 5 The performance and behavior of traffic routed to the source and target clusters are analyzed by reviewing relevant logs and metrics.
Step 6 After confirming the target cluster’s functionality meets expectations, the user redirects clients to the new target. Additionally, the user can retire and discard the old cluster’s infrastructure.
Step 1 Client traffic is directed to the existing cluster.
Step 2 An Application Load Balancer (ALB) is positioned in front of the traffic capture proxy to route traffic as needed. The ALB forwards traffic to the capture proxy, which then relays it to the source while simultaneously replicating the traffic to Amazon Managed Streaming for Apache Kafka (Amazon MSK).
Step 3 With continuous traffic capture in place, a Reindex-from-Snapshot (RFS) is initiated by the user through the Migration Management Console.
Step 4 After a backfill has been completed, the captured traffic is replayed by the user with a Traffic Replayer.
Step 5 The performance and behavior of traffic routed to the source and target clusters are analyzed by reviewing relevant logs and metrics.
Step 6 After confirming the target cluster’s functionality meets expectations, the user redirects clients to the new target. Additionally, the user can retire and discard the old cluster’s infrastructure.
Step 1 Client traffic is directed to the existing cluster.
Step 2 An Application Load Balancer (ALB) is positioned in front of the traffic capture proxy to route traffic as needed. The ALB forwards traffic to the capture proxy, which then relays it to the source while simultaneously replicating the traffic to Amazon Managed Streaming for Apache Kafka (Amazon MSK).
Step 3 With continuous traffic capture in place, a Reindex-from-Snapshot (RFS) is initiated by the user through the Migration Management Console.
Step 4 After a backfill has been completed, the captured traffic is replayed by the user with a Traffic Replayer.
Step 5 The performance and behavior of traffic routed to the source and target clusters are analyzed by reviewing relevant logs and metrics.
Step 6 After confirming the target cluster’s functionality meets expectations, the user redirects clients to the new target. Additionally, the user can retire and discard the old cluster’s infrastructure.
Step 1 Client traffic is directed to the existing cluster.
Step 2 An Application Load Balancer (ALB) is positioned in front of the traffic capture proxy to route traffic as needed. The ALB forwards traffic to the capture proxy, which then relays it to the source while simultaneously replicating the traffic to Amazon Managed Streaming for Apache Kafka (Amazon MSK).
Step 3 With continuous traffic capture in place, a Reindex-from-Snapshot (RFS) is initiated by the user through the Migration Management Console.
Step 4 After a backfill has been completed, the captured traffic is replayed by the user with a Traffic Replayer.
Step 5 The performance and behavior of traffic routed to the source and target clusters are analyzed by reviewing relevant logs and metrics.
Step 6 After confirming the target cluster’s functionality meets expectations, the user redirects clients to the new target. Additionally, the user can retire and discard the old cluster’s infrastructure.
Step 1 Client traffic is directed to the existing cluster.
Step 2 An Application Load Balancer (ALB) is positioned in front of the traffic capture proxy to route traffic as needed. The ALB forwards traffic to the capture proxy, which then relays it to the source while simultaneously replicating the traffic to Amazon Managed Streaming for Apache Kafka (Amazon MSK).
Step 3 With continuous traffic capture in place, a Reindex-from-Snapshot (RFS) is initiated by the user through the Migration Management Console.
Related content
Video
Solving with AWS Solutions: Machine Downtime Monitor on AWS
Watch the video
AWS Architecture Blog
Digitally transform your factory with Machine Downtime Monitor on AWS
In manufacturing enterprises, digital transformation and Industry 4.0 are likely at the top of your mind. Learn how to digitally transform your factory with Machine Downtime Monitor on AWS.