You're on AWS DMS: It Moves Your Databases Into AWS. Data Workers Owns Whether What Lands Is Right and Holds the Cutover
AWS DMS moves and replicates your databases into AWS. Data Workers checks every table has passing evidence, traces what a gap would break and holds the cutover for the owner's sign-off.
Your team moves databases with AWS Database Migration Service. Schema Conversion turned the Oracle or SQL Server schema into Aurora PostgreSQL, with generative AI picking up the procedures the rule-based converter flagged as action items. A replication task runs full load and CDC on a replication instance or DMS Serverless, table mappings pick the schemas, and data validation fills the table statistics: Validated, Mismatched records, Pending records, No primary key. Like-for-like moves run as homogeneous data migrations. Fleet Advisor was discontinued on May 20, 2026, so the inventory lives in spreadsheets again, and the cutover runbook ends with a weekend window and a line that says "validation clean."
That line carries more weight than it looks. DMS can only validate a table it can key, and a table it can't key reports no failures at all. Whether every table that matters has evidence it arrived right, what a gap would break downstream, and who signs off before the application points at Aurora is a different job. Data Workers takes it: it plans each wave with its parity checks, traces every gap through the jobs and reports that read the table, gets the fix approved and holds the cutover until the owner signs off.
Key takeaways
- •DMS keeps its job. Schema Conversion, tasks, validation, reloads and resync stay with your migration team. Data Workers works on what lands and the decision to cut over.
- •"Zero failures" gets checked against the table list. The completion gate counts a table only when it has a passing validation and a parity record. Tables DMS couldn't validate show up by name before the window.
- •Parity evidence comes from DMS data validation or the owner. Data Workers tracks it, traces what a gap reaches and holds the gate.
- •Connected over the AWS API or the AWS MCP server today. Aurora PostgreSQL, Airflow and Slack connect natively, including DMS's failure table on the target.
- •Every fix and the cutover go through a named person. Autonomy is set per domain: start at L1 observe on the next wave, then L2 propose.
AWS DMS moves your databases into AWS. Data Workers owns whether what lands is right.
DMS's job is to get every row to the target and keep it current until you cut over. The job around it is different: know which tables feed which jobs and reports, notice when evidence is missing rather than negative, get the cause fixed, and hand the owner a sign-off with the proof attached. Here is one cutover weekend at a consumer lender moving loan servicing from Oracle Database 19c on premises to Aurora PostgreSQL. Times are ET. This is an illustration, not a customer case.
| Time | System | What happens |
|---|---|---|
| Fri 14:00 | AWS DMS | Task ora-lns-to-aurora (full load and CDC, validation on) has run for twelve days. Latency is under five seconds and the console shows zero validation failures. The runbook sets cutover for Saturday 02:00 |
| 14:20 | AWS MCP server + Data Workers | The migration owner's agent pulls the task's table statistics over the AWS MCP server and attaches them to wave 3 as parity evidence. The completion gate fails closed: 414 of 418 tables are Validated; payment_schedule, escrow_disbursement, fee_assessment and note_history show "No primary key". Their Oracle primary keys were created with NOVALIDATE, which DMS doesn't treat as a key, so DMS skips them and reports no failures |
| 14:25 | Data Workers + Airflow | blast_radius_analysis on the four tables, from the context graph, where the team recorded which Airflow DAGs read the tables: payment_schedule feeds the collections_daily DAG (payoff quotes and delinquency buckets), the Power BI "Delinquency and roll rates" report and the monthly servicing file to the loan investors |
| 14:30 | Slack | The approval request reaches the migration owner: hold the cutover; ask the DBA to validate the four keys in Oracle; revalidate the four tables in DMS |
| 15:10 | Spellbook | The owner approves the hold and the plan and moves the change window to Sunday 02:00 |
| 19:00 | Oracle 19c | The DBA validates the four primary key constraints after hours; no duplicates turn up |
| 19:40 | AWS DMS | The owner revalidates the four tables. Three come back Validated. payment_schedule shows Mismatched records: 2,184 RECORD_DIFF rows |
| 20:05 | Data Workers + Aurora PostgreSQL | The owner attaches DMS's failure table from the target: every difference is in accrued_interest, such as 125.4375 at the source against 125.44 at the target. The owner's \d payment_schedule shows the column as NUMERIC(12,2) in Aurora: during review someone tidied the exported conversion script to two decimals, while Oracle keeps four. diagnose_incident names the cause; payoff quotes built on it would drift by cents per loan |
| 20:10 | Data Workers | generate_migration drafts the change back to NUMERIC(12,4) with its rollback SQL, plus a run plan: apply the change, reload payment_schedule in DMS, let validation finish, re-check the gate |
| Sat 09:00 | Spellbook | The owner approves the change and the plan |
| 09:30 | Aurora PostgreSQL | The owner applies the change; the rollback is on file with the receipt |
| 10:00 | AWS DMS | The owner reloads payment_schedule; full load and validation run again while CDC keeps the rest current |
| 16:40 | AWS DMS | payment_schedule is Validated with no failures |
| 17:00 | Data Workers | The owner attaches the fresh table statistics. The gate passes: 418 of 418 tables have a passing validation and a parity record. The receipt records the approved column type. The sign-off request goes to the owner and the servicing application owner |
| Sun 02:00 | Aurora PostgreSQL | Both sign off in Spellbook; the team cuts the application over to Aurora |
| 06:30 | Airflow | collections_daily runs on Aurora. The daily accrued-interest total the team records with monitor_metrics sits inside its baseline from the Oracle runs |
| Mon 08:30 | Power BI | Collections opens the delinquency report on numbers that match Friday's Oracle close |
Every part of DMS worked as documented: validation reported exactly what it could compare and left out, without a failure, what it couldn't. Catching that takes things DMS was never meant to hold: the tables the business depends on, the jobs and reports that read each one, and the rule that nobody cuts over until each has evidence.
| Job | What AWS DMS does | What Data Workers does |
|---|---|---|
| The move | Full load and CDC with table mappings and task settings, on replication instances, DMS Serverless or homogeneous data migrations | Connects over the AWS API or MCP server; reads the target natively when it is PostgreSQL |
| The schema | Schema Conversion converts schemas and code, with generative AI for objects the rules can't convert | Checks the landed data against the source, traces each difference and drafts fixes with rollback SQL for the owner to apply |
| The evidence | Data validation compares keyed rows and fills table statistics and the failure table | Tracks which tables have passing evidence; the gate fails closed on any table without it |
| The diagnosis | DETAILS shows the source and target values that differ for each key | Joins the failures, the target schema and lineage into one cause, with the blast radius across jobs, reports and files |
| The repair | Revalidate, reload a table, or let data resync re-apply source rows on a schedule | Proposes the fix and the run order; the owner revalidates, reloads and resyncs in DMS |
| The cutover | Keeps the target current until you switch | Holds the completion gate and routes the sign-off to named owners, with a receipt: what was checked, who approved it, how to undo it |
Why doesn't AWS DMS just do this itself?
Because DMS is built to move and replicate databases faithfully at any scale, and its validation is scoped to what it can prove: rows it can key. Its docs list what it leaves out: tables without a primary key or unique index, Oracle keys created with NOVALIDATE, views, Oracle LONG columns, columns under a masking transformation, and PostgreSQL keys whose collation sorts differently from Oracle's. Tables without a usable key "are suspended from validation and no validation failures are reported." That is a sensible design for a migration engine: report what you can compare, and leave judgement to the team. Homogeneous data migrations "don't provide a built-in tool for data validation" at all.
The AI in DMS follows the same scope. Schema Conversion's generative AI converts code objects, and AWS says plainly: "You must review and validate all conversion outputs." Through the AWS MCP server, an agent such as Claude Code, Kiro or Cursor can create migration projects, convert schemas and export assessment reports. None of that knows that payment_schedule feeds a collections job, or that the investors' monthly file reads it.
Owning whether a migration landed right across Oracle, DMS, Aurora, Airflow, Power BI and an outbound file is a different product: a context graph of every table and consumer, wave plans with tracked evidence, a gate that fails closed, named approvers and receipts an auditor can read. That is Data Workers. More in is it safe to let AI agents change production data.
Every tool owns a slice. Data Workers covers the whole lifecycle
Each point tool adds another console, contract and handoff. Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail.
| Stage | Data Workers | AWS DMS | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 3 | Schema Conversion browses source metadata and DMS keeps task and table statistics; it doesn't hold what a table means downstream. Data Workers keeps one governed context graph of meaning, owners and consumers. |
| Analytics & Insights | 8 | 1 | Not DMS's job: it moves the data, and reporting runs elsewhere. Data Workers answers data questions from governed definitions with lineage behind every number. |
| Data Quality | 8 | 3 | Data validation compares source and target rows and records mismatches; tables without a usable key are skipped. Data Workers tracks which objects have passing evidence and which don't. |
| Observability & Incidents | 8.5 | 4 | CloudWatch metrics, task logs and table statistics show the task's health. Data Workers turns a validation gap or mismatch into a diagnosed incident with blast radius and a fix. |
| Pipelines & Ingestion | 8.5 | 9 | DMS's home stage: full load and CDC from Oracle, SQL Server, PostgreSQL and more, DMS Serverless, homogeneous migrations and data resync. Data Workers plans the reloads and revalidations for the owner. |
| Schema & Migration | 8 | 8 | Schema Conversion converts schemas and code, with generative AI for objects the rules can't convert. A tie: Data Workers plans the waves, generates fixes with rollback SQL and holds the completion gate. |
| Governance & Access | 8.5 | 5 | IAM policies, IAM database authentication and Secrets Manager govern the move. Data Workers routes every data change and the cutover sign-off to a named approver. |
| Security & Privacy | 8 | 6 | TLS in transit, KMS encryption and VPC endpoints protect the replication. Data Workers leaves a receipt on every data change. |
| Cost / FinOps | 8 | 3 | Hourly instances or serverless capacity units price the move. Data Workers reads AWS Cost Explorer by service and traces Snowflake credits to the dbt model behind them. |
| MLOps & Models | 7.5 | 1 | Not DMS's job. Data Workers keeps the data under models and agents healthy. |
How AWS DMS and Data Workers work together
Data Workers connects to AWS DMS over the AWS API or the AWS MCP server today. Data Workers never starts, stops, reloads, revalidates or resyncs a task; your migration team does. The owner's agent pulls table statistics over the AWS MCP server and attaches them to the wave as parity evidence, and on a PostgreSQL target, DMS's failure table (awsdms_validation_failures_v2 from engine 3.6.1) is an ordinary table Data Workers reads natively. Aurora PostgreSQL, Airflow and Slack are native too, among 50+ connectors; Oracle and Power BI connect over their APIs. The full list is in Data Workers integrations.
The migration agent in the Data-Agents Swarm plans each wave from a dependency map, with downstream consumers drawn from lineage, and tracks the parity checks each table needs. The completion gate defaults to "not done": it names every table without a passing validation and a parity record, and stays closed until the owner signs off. Data Workers plans, checks and traces around Schema Conversion.
The AWS MCP server and the Data Workers agents run side by side in one client, so the owner revalidates and reloads in the same session where Data Workers explains what a gap reaches. The Data Workers side follows the documented client setup: clone the open-source repo and add each agent's start-agent.sh entry.
# Example: the AWS MCP server plus Data Workers agents in Claude Code
# AWS MCP server (remote; OAuth sign-in in the browser)
claude mcp add aws-mcp https://aws-mcp.us-east-1.api.aws/mcp --transport http
# Data Workers agents, from a clone of the open-source repo
claude mcp add --scope user dw-schema -- "$(pwd)/start-agent.sh" dw-schema
claude mcp add --scope user dw-catalog -- "$(pwd)/start-agent.sh" dw-context-catalog
claude mcp add --scope user dw-incidents -- "$(pwd)/start-agent.sh" dw-incidentsList the tools with your client's own command (/mcp in Claude Code). In this weekend, generate_migration drafts the column change with rollback SQL for the owner to apply; blast_radius_analysis and trace_cross_platform_lineage (dw-context-catalog) map what a table reaches, and explain_table gives its definition, lineage and documentation; diagnose_incident and get_incident_history (dw-incidents) name the cause and keep the record; monitor_metrics watches the numbers the team records after cutover. For agents that read but never change AWS resources, the MCP server's SigV4 setup has a read-only mode that hides write-capable tools.
In production the agents run in your infrastructure, in your AWS account if you like, and hold the database credentials and model key. Your data stays in your systems; the hosted Conductor sees workflow metadata only. More in where does our data go. For the wider estate across Redshift, Glue, S3 Tables and SageMaker, see Data Workers on AWS.
One migration, L0 to L4, set per domain:
- •L0 manual. The team cuts over Saturday on "validation clean", and collections finds the payoff drift on Monday from a borrower's complaint.
- •L1 observe. Data Workers lists the four tables without evidence on Friday afternoon, with what each feeds. Nothing changes.
- •L2 propose. Data Workers proposes the hold, the column change and the run order; nothing moves until the named owner approves, and an unanswered request expires and escalates, never auto-grants.
- •L3 act reversibly. For classes with a clean record, Data Workers files its findings and re-checks the gate as evidence arrives. Target changes, reloads and the cutover stay with the owner.
- •L4 autonomous. For a scoped domain, Data Workers keeps each wave's gate current, so the sign-off request is ready the moment the last table passes.
Who sets those levels: who owns the agents, how approvals work for AI data agents and autonomy levels L0 to L4 explained.
What changes for your team
- •Cutover meetings start from the gate. The tables without evidence, and what each feeds, are on screen before anyone books the window.
- •"Zero failures" stops being the whole story. Tables DMS skipped are named, with the reason.
- •Hand edits to converted schemas get caught as a mismatch with its cause, before the application depends on them.
- •One record for the migration and data teams. Evidence, approvals and sign-off live in Spellbook Data Catalog (in preview), and the receipt outlives the project.
For CDC background, see what is CDC, change data capture explained and the CDC tools comparison.
Keep AWS DMS, or consolidate?
Keep AWS DMS if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
For most AWS teams the answer is keep it: DMS is the native way to get Oracle, SQL Server and PostgreSQL into RDS, Aurora, Redshift and S3, and conversion, validation and resync are built in. What teams consolidate is the tooling around the move: cutover spreadsheets, hand-written queries against the failure table, one-off row-count scripts and the Slack thread that is the only record of who said go. Many estates run a second replication tool next to DMS: see you're on Debezium, you're on Qlik Replicate and you're on Informatica PowerCenter. One record spans them.
Weighing a build on the AWS MCP server and a coding agent? Read build it ourselves with Claude Code and MCP servers: pulling table statistics from a chat is easy; the context graph, wave plans, approvals, undo and receipts are the work. For the category view, see what is an agentic data platform.
The case for your CFO
The outcome. A migration cuts over only when every table that matters has evidence it arrived right, and the sign-off names who approved it. The business keeps servicing and reporting on the same numbers it had the day before.
The risk story. At L0 and L1, agents only read. At L2 they propose and a named person approves; at L3 they act on reversible steps inside the domains you open. Target changes, reloads and the cutover stay with the migration owner. No agent can promote its own work, an org-wide stop halts all autonomous dispatch, and every change carries a receipt: what changed, who approved it, the blast radius and the undo.
Why now. Migration teams convert schemas with generative AI and drive DMS through agents, and AWS asks you to review every output. Faster moves make the check before cutover matter more.
The first win. L1 on the next wave: before the window, the gate lists every table without passing evidence and what it feeds.
What stays the same. DMS, your tasks, Schema Conversion, Oracle, Aurora, Airflow, Power BI and your change process stay as they are. For the numbers, see the ROI of agentic data operations.
The sentence for upstairs: "DMS moves our databases; Data Workers makes sure every table has proof it arrived right, and nobody cuts over until the owner signs off on it."
Getting started
Start with a pilot. Pick the next DMS wave with a cutover date, give Data Workers read access to the target and the lineage around it, and run at L1 so the gate shows which tables have evidence. Then turn on L2 so fixes and the sign-off flow through named approvals, and open L3 for narrow classes once the receipts show the agents were right. The pilot path is on the pricing page, and the pilot is credited in full against the first year.
FAQ
How does Data Workers connect to AWS DMS? Over the AWS API or the AWS MCP server today. On a PostgreSQL or Aurora PostgreSQL target, it reads the target schema and DMS's failure table natively. It never starts, stops, reloads or revalidates a task.
Our task shows zero validation failures. Why would a table still be unchecked? DMS validates only tables it can key. A table without a primary key or unique index, or with an Oracle key created with NOVALIDATE, is suspended from validation with no failures reported. Views, Oracle LONG columns, masked columns and some collation cases are also outside validation. The gate turns the table statistics into a list with owners.
Does Data Workers compare source and target data itself? No. Parity evidence comes from DMS data validation, a validation-only task, or a check the owner runs and attaches. Data Workers never compares, reloads or revalidates; it tracks that evidence per table, traces what a gap reaches, proposes the fix and holds the gate until the owner signs off.
We use homogeneous data migrations. Does this still apply? Yes. Homogeneous data migrations have no built-in data validation, so the owner brings parity evidence from a validation-only task or their own checks, and the gate tracks it the same way.
Will Data Workers translate our Oracle code to PostgreSQL? Schema Conversion does that job on AWS, and Data Workers builds on it: it checks what landed against the source, drafts fixes with rollback SQL when something lands wrong, and holds the gate.
Which DMS engine version should we be on? Check the release notes before you plan a wave: 3.6.0 reached end of life on July 27, 2026; 3.5.4, the current DMS Serverless engine, runs to March 31, 2027; and 3.6.1 is the newest, with data resync for Oracle and SQL Server sources into PostgreSQL targets. Data resync re-applies source rows for validation failures, so it fixes mismatches only once the target's column types are right.
Fleet Advisor is gone. How do we inventory what to move? AWS discontinued Fleet Advisor on May 20, 2026. Data Context Wizard builds one graph of your tables, owners and consumers, and the migration agent plans waves from that dependency map, so the inventory stays tied to what each table feeds.
Sources
- •AWS, AWS Database Migration Service product page (features; Fleet Advisor discontinued May 20, 2026), https://aws.amazon.com/dms/ (checked Oct 3, 2026)
- •AWS DMS User Guide, AWS DMS data validation (table statistics, failure tables, revalidation, validation-only tasks, limitations), https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html (checked Oct 3, 2026)
- •AWS DMS User Guide, AWS DMS data resync, https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.DataResync.html (checked Oct 3, 2026)
- •AWS DMS User Guide, release notes (engine versions 3.6.1, 3.6.0, 3.5.4 and end-of-life dates), https://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReleaseNotes.html (checked Oct 3, 2026)
- •AWS DMS User Guide, Working with AWS DMS Serverless and its limitations, https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Serverless.html and https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Serverless.Limitations.html (checked Oct 3, 2026)
- •AWS DMS User Guide, homogeneous data migrations, https://docs.aws.amazon.com/dms/latest/userguide/data-migrations.html (checked Oct 3, 2026)
- •AWS DMS User Guide, Converting database objects with generative AI, https://docs.aws.amazon.com/dms/latest/userguide/schema-conversion-convert.databaseobjects.html (checked Oct 3, 2026)
- •AWS DMS User Guide, Using AI agents with DMS Schema Conversion, https://docs.aws.amazon.com/dms/latest/userguide/sc-genai-agents.html (checked Oct 3, 2026)
- •AWS Agent Toolkit User Guide, Setting up the AWS MCP Server, https://docs.aws.amazon.com/agent-toolkit/latest/userguide/getting-started-aws-mcp-server.html (checked Oct 3, 2026)
- •Data Workers open-source repository (tool registrations in dw-schema, dw-context-catalog, dw-incidents), https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 3, 2026)
- •Data Workers client setup guide, https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 3, 2026)