In a recent demo, our team migrated one terabyte of production data from Elasticsearch 7.10 running on Amazon OpenSearch Service to OpenSearch 3.x running on OpenSearch Service in 33 minutes. The migration was orchestrated entirely by an AI agent. No runbook. No manual configuration files. No engineer babysitting terminal windows at 2 AM. The agent made infrastructure decisions, monitored progress, handled errors, and completed the migration while the team watched from the sidelines.
The toolchain was Kiro connected to Migration Assistant for Amazon OpenSearch Service running on EKS. Migration Assistant is open source and supports migrations from Elasticsearch, self-managed OpenSearch, and Apache Solr (versions 6.x through 9.x) to both Amazon OpenSearch Service domains and Amazon OpenSearch Serverless collections. It handles snapshot-based backfill, live traffic capture and replay for validation, and metadata translation. The AI-assisted experience lets you drive the entire workflow from Kiro, Claude Code, or any MCP-compatible tool: the agent plans the migration, deploys infrastructure, executes the data movement, monitors progress, and validates results. In this demo, the result challenges assumptions about what still requires human hands during a database migration.
Why migrations still eat engineering weeks
Database migrations have three layers of difficulty. The first is planning: figuring out which indices to migrate, what version incompatibilities exist, how to handle mapping differences, and what order to execute steps. The second is execution: configuring snapshots, parallelizing backfill, managing network throughput, and coordinating the cutover. The third is monitoring: watching progress, detecting errors, calculating ETAs, and deciding whether a failure is recoverable or fatal.
Most teams solve all three layers with the same tool: a senior engineer. That engineer writes the plan, executes it step by step, monitors progress manually, and makes judgment calls when things go wrong. The work is cognitively demanding but largely repetitive across migrations. The cluster sizes differ. The index counts differ. The judgment calls are the same patterns applied to different numbers.
This is the kind of work where AI agents should excel: well-defined operations with clear success criteria, where the decisions follow from observable state rather than ambiguous business context. The question is whether the tooling is mature enough to let an agent make those decisions reliably. Based on what we observed, the answer is yes.
What the agent actually did
The demo started with Kiro connected to a Migration Assistant deployment running on EKS. The Migration Assistant was bootstrapped in a fresh VPC via CloudFormation. The source was an Amazon OpenSearch Service domain running Elasticsearch 7.10 with 1 TB of primary data (2 TB including replicas). The target was an Amazon OpenSearch Service domain running OpenSearch 3.x.
Kiro scanned the AWS account, discovered the source and target clusters, and presented options. When told to migrate as fast as possible with no other workloads running, the agent adjusted its approach accordingly. It set snapshot throttling high (800 MB/s) because there was no competing I/O to protect. It calculated optimal parallelization at 480 concurrent reindex pods, matching the shard count. It configured EKS auto mode to provision EC2 instances on demand so the infrastructure scaled to match the workload.
None of these decisions came from a template. The agent queried the source cluster for real-time state and made context-aware choices. If other workloads had been running, it would have throttled the snapshot to avoid disk contention. The throttling decision came from understanding the tradeoff between migration speed and source cluster impact.
The timeline
The 33-minute migration broke down as follows. Snapshot took 5 minutes at full throttle. Metadata migration (index mappings, aliases, templates) took 1 minute. Backfill across 480 parallel pods took 12 minutes. The remainder was setup, validation, and the agent confirming success. End to end, from first prompt to validated completion, 33 minutes for a terabyte.
Monitoring and error handling
During the snapshot phase, Kiro queried the source cluster every 30 seconds for progress metrics. During backfill, it recalculated ETAs every minute. This monitoring behavior was not preconfigured in the Argo workflow. The agent added it because that is what a human operator would want to know. The feedback loop from these AI-assisted runs is now informing what gets built into the Migration Assistant itself.
The agent caught errors and decided what to do with them. The agent distinguished between recoverable errors (retry) and fatal errors (stop and surface for human investigation). The team could have disconnected entirely and the migration would have completed successfully. That level of autonomy is the point. The agent was not generating scripts for a human to run. It was running infrastructure.
AI handles choreography. Humans handle strategy.
Watch this demo and a clear division of labor emerges. The humans decided which clusters to migrate, what performance tradeoffs to accept, and whether to prioritize speed over source cluster stability. The agent handled everything else: the configuration, the monitoring loops, the progress checks, the validation queries, and the error recovery.
The point is not fewer engineers. The point is engineers spending time on decisions, not choreography. A 1 TB migration that previously required 4-6 hours of active senior engineering time now requires a few prompts and strategic oversight. The operational choreography disappears. The judgment about what to migrate and why stays with the human.
Fifty cents. That is what the AI orchestration for the entire migration consumed in compute. Compare that to the fully loaded cost of a senior engineer spending half a day on the same work. The economics push toward using the agent for execution and reserving human time for decisions that require business context.
The tooling is open source
Migration Assistant for Amazon OpenSearch Service is open source at opensearch-project/opensearch-migrations and supports Elasticsearch, Solr, and self-managed OpenSearch as sources. The s/runbook/agent/ substitution is available today. Point Kiro, Claude Code, or any MCP-compatible tool at the Migration Assistant. The agent handles the infrastructure decisions, the progress monitoring, and the error recovery. The senior engineer who used to babysit the migration can now review the plan, approve it, and check back when the agent reports completion.
Medium tags: opensearch, elasticsearch, migration, ai-agents, devops
