AWS Database Migration Service provides managed full-load migration and change data capture, supports row-level validation for documented configurations, and exposes operational metrics for replication. DMS Schema Conversion can assess and convert supported database objects, including generative AI-assisted conversion for selected findings. Those capabilities are substantial. A complete modernization program must also prove that the converted application produces the same business result on its new database.
The opportunity is therefore not another replication engine or another dashboard for AWS DMS tasks. It is an AWS Database Modernization Factory with reusable software and delivery controls that help a customer answer six broader questions:
- 1What databases and application dependencies do we actually have?
- 2Which AWS destination fits each workload?
- 3What database and application code still requires remediation?
- 4Does the converted system behave like the source?
- 5Can we rehearse cutover and rollback under realistic conditions?
- 6What must be tuned and verified after production cutover?
This guide presents an AWS-native architecture for answering those questions. It focuses first on Oracle, with Aurora PostgreSQL, RDS for Oracle, Oracle Database@AWS, and Amazon Redshift treated as distinct target decisions. The same assurance controls can then support Db2, SAP ASE, selected SQL Server workloads, and analytical platforms moving to Redshift.
AWS Services Provide the Migration Foundation
The AWS migration toolset has expanded. AWS ended support for DMS Fleet Advisor on May 20, 2026 and directs customers toward Migration Evaluator [1]. AWS Transform discovery can now inventory Oracle database topology, versions, editions, options, feature use, size, RAC and Data Guard signals, and certain network dependencies [2]. DMS Schema Conversion exposes agent-driven workflows for projects, metadata, conversion, assessments, reports, and explanations [3].
That changes where a partner should invest. A generic inventory scanner or an AI wrapper around a schema conversion report is no longer enough. AWS also published a reference implementation that uses Amazon Bedrock and Strands agents to remediate Oracle PL/SQL, deploy converted objects, run tests, and generate confidence signals [4]. Customers can reasonably expect native discovery and code conversion to keep improving.
What remains is the accountable path from those technical findings to a target decision and a production acceptance decision.
For a standard heterogeneous DMS task, AWS DMS can create target tables, primary keys, and in some cases unique indexes. It does not recreate every secondary index, non-primary-key constraint, or default [6]. Schema conversion fills part of that gap, but AWS documents categories that its generative conversion does not cover, including triggers, dynamic SQL, indexes, constraints, computed columns, table defaults, parameter defaults, and column data types [7]. Generated output must be reviewed and validated.
The correct division of responsibility is clear:
| Layer | Primary responsibility | What it should prove |
|---|---|---|
| Discovery | AWS discovery services plus customer inventory | The estate and its dependencies are known |
| Target decision | Architecture and commercial assessment | Each workload has a justified AWS destination |
| Conversion | DMS Schema Conversion, AWS Transform, AWS SCT, and reviewed remediation | Database and application code compiles on the target |
| Data movement | AWS DMS full load and CDC | Data reaches the target within agreed lag thresholds |
| Acceptance | Repeatable business parity tests plus domain-owner review | Business behavior and performance meet acceptance criteria |
| Cutover and operations | Runbooks, approvals, observability, and tuning | The organization can cut over, recover, and operate safely |
AWS owns strong native services in several layers. The customer still owns the production decision.
AWS DMS is not the only movement option in the Factory. It is the default for supported full-load and CDC paths. Engine-native backup and restore, export and import, or bulk-load utilities may fit better when the source-target pair, estate size, network path, or downtime model makes continuous replication unnecessary or inefficient. The architecture records that decision separately from schema conversion and separately again from business acceptance.
Where Migration Risk Actually Remains
Row-level validation is valuable, but it is not business acceptance. DMS validation generally compares source and target rows and requires a primary key or unique index. AWS documents limits for views, selected Oracle data types, continuously changing rows, consolidating multiple databases into one, and Aurora PostgreSQL Limitless [5]. Data resynchronization is narrower: it is limited to Oracle and SQL Server sources with PostgreSQL targets, requires keys, and temporarily pauses CDC and validation during resynchronization [8].
A complete acceptance plan needs several forms of evidence.
| Evidence class | Example question | Acceptance artifact |
|---|---|---|
| Data parity | Did every expected record and value arrive? | Counts, checksums, null, precision, encoding, and key exceptions |
| Query parity | Do equivalent queries return equivalent results? | Source-to-target result comparisons for critical queries |
| Business parity | Do balances, invoices, inventory, and reports reconcile? | Domain-owned totals and tolerance rules |
| Behavioral parity | Do procedures and transactions produce the same effects? | Before-and-after state assertions |
| Semantic parity | Did isolation, locking, timezone, and error behavior change? | Concurrency and edge-case test results |
| Performance parity | Does the target satisfy workload objectives? | Replay results for latency, throughput, and resource use |
This is the most defensible product boundary. A migration confidence score should not be a model's opinion or a percentage of converted objects. It should summarize executable evidence mapped to acceptance criteria, with every failed test and human exception visible.
The same principle applies to cutover. CDC is asynchronous. AWS exposes source and target latency metrics, but the customer must define acceptable lag and decide when to stop source writes [9]. AWS cutover guidance still calls for final synchronization, rollback checkpoints, a named rollback decision owner, and a plan for writes that occur after cutover [10]. The delivery workflow should collect this evidence and make the go or no-go decision explicit.
Reference Architecture for the Database Modernization Factory
The Tactical Edge AWS Database Modernization Factory configures AWS-native migration services within six repeatable delivery workstreams. Its reusable software layer contains a read-only Assessment Collector, a source-to-target Validation Harness, AWS deployment templates, and an approval-gated Cutover Orchestrator. Application remediation, business test design, source-write freeze, endpoint switching, rollback, and stabilization remain customer-specific delivery work.
The first implemented adapter path targets Oracle and PostgreSQL. That includes Aurora PostgreSQL and RDS for PostgreSQL targets. Additional source engines belong on the supported list only after their adapters, metadata queries, fixtures, and migration-path tests are complete.
| Delivery workstream | Inputs | Processing | Output |
|---|---|---|---|
| Estate assessment | AWS discovery output, catalogs, connection data, jobs, repositories | Normalize databases, applications, reports, owners, and dependencies | Estate graph and migration waves |
| Target evaluation | Workload behavior, compatibility, risk, cost, licensing goals | Compare rehost, replatform, and refactor destinations | Target decision record for each workload |
| Conversion remediation | DMS action reports, source objects, application SQL | Triage, remediate, test, and route high-risk changes for approval | Source-controlled conversion backlog |
| Business parity testing | Masked data, critical queries, procedures, business rules, workload samples | Execute source and target tests in temporary environments | Functional-equivalence evidence |
| Cutover coordination | DMS tasks, CloudWatch metrics, dependencies, approval rules | Rehearse, sequence, watch lag, capture decisions, preserve rollback | Approved cutover and rollback runbook |
| Post-cutover stabilization | Query telemetry, locks, connections, backups, cost, incidents | Compare production behavior with the acceptance baseline | 30 to 90 day optimization and stabilization report |
The implementation should reside in the customer's AWS environment or a customer-approved delivery account. Source collection is read-only. Credentials stay in AWS Secrets Manager. Conversion changes flow through version control and review. Temporary target environments use masked or approved representative data. CloudWatch captures DMS task health and lag. Step Functions can orchestrate repeatable test and cutover workflows, while approval steps remain with named customer owners.
The delivery workflow should not automatically accept risky code because an LLM produced it. Generative conversion is probabilistic, and AWS notes that the same SQL may produce different converted output over time [7]. The safe pattern is automation followed by compilation, deterministic tests, a risk classification, and human approval for objects that affect money movement, regulated reports, security boundaries, or irreversible writes.
Choose Database Routes by Workload
Oracle is the strongest initial wedge because it combines a large enterprise footprint with substantial database-resident logic and meaningful target choices. It is also where simplistic positioning creates the most risk. Not every Oracle customer should be told to exit Oracle.
| Source workload | AWS destination options | Best when | Assurance focus |
|---|---|---|---|
| Oracle transactional | Aurora PostgreSQL or RDS PostgreSQL | The customer wants open-source modernization and can remediate Oracle dependencies | PL/SQL, application SQL, transaction semantics, workload performance |
| Oracle transactional | RDS for Oracle | Managed operations matter more than immediate code conversion | Compatibility, upgrade, operational readiness, licensing model |
| Oracle with Exadata, RAC, or Oracle-specific requirements | Oracle Database@AWS | Minimal application change and Oracle capabilities are required | Network, identity, operations, resilience, and service integration |
| Oracle analytical | Amazon Redshift | The workload is reporting and analytics rather than transactional | ETL, BI, semantic totals, CDC behavior, workload replay |
| Db2 LUW or z/OS, SAP ASE | Aurora PostgreSQL or RDS PostgreSQL | Legacy skills are scarce and modernization value justifies conversion | Procedural behavior, encodings, batch jobs, application dependencies |
| SQL Server | Aurora PostgreSQL or RDS PostgreSQL | The workload falls outside native AWS Transform coverage or needs independent assurance | Non-.NET stacks, unsupported frameworks, cross-database logic, regulated evidence |
| Teradata, Netezza, or Greenplum | Amazon Redshift | The customer is modernizing a warehouse estate | Scripts, ETL, BI lineage, semantic reconciliation, workload management |
| MySQL or PostgreSQL | Same-engine Aurora or RDS | The goal is managed operations, consolidation, or a version upgrade | Extension compatibility, replication, performance, operational cutover |
Oracle Database@AWS now includes multiple service options, so target advice must reflect current service capabilities rather than a blanket Oracle-exit message [11]. For SQL Server, AWS Transform already covers a broad workflow across SQL Server schemas, stored procedures, DMS movement, supported .NET application changes, dependency mapping, validation, deployment, approvals, and rollback [12]. Tactical Edge should focus that lane on documented exclusions and independent assurance, not compete with the native service's center.
Warehouse migrations deserve a distinct lane. DMS can load and replicate selected changes into Amazon Redshift, but warehouse modernization also includes ETL and ELT, scripts, BI dependencies, business reconciliation, workload replay, and production performance [13]. Redshift already provides automatic table optimization and Advisor recommendations [14]. The opportunity is not to claim AWS lacks tuning tools. It is to validate the migrated workload and turn recommendations into reviewed, measured changes.
Start With an Oracle Assessment and One Representative Pilot
The safest commercial entry point is not a promise to migrate the entire estate. It is a fixed-scope Oracle Exit and AWS Modernization Assessment followed by one representative pilot.
The assessment should deliver:
- A database and application dependency inventory.
- A target recommendation for each workload.
- DMS Schema Conversion findings and unresolved-object classification.
- An application-code impact report across services, jobs, ETL, reports, and integrations.
- A cutover and downtime architecture.
- Migration waves, prerequisites, risk, and effort.
- A pilot scope tied to explicit acceptance criteria.
Select a pilot that is representative, not trivial. It should include meaningful procedural logic, at least one dependent application path, a realistic change rate, and business totals that a domain owner can verify. The pilot then proves six things: target compatibility, conversion quality, full load, CDC behavior, application compatibility, and cutover procedure.
The output should read like an acceptance record, not a marketing claim. For example: every expected object has a disposition; every critical business test has a result; replication lag stayed within the agreed window during rehearsal; rollback was tested; remaining exceptions have owners and dates. That evidence gives technical and business stakeholders a common basis for approving the next migration wave.
After the Oracle pattern works, the same Factory controls can extend to Db2 and SAP ASE, then to a separate Warehouse-to-Redshift lane. Standardized MySQL and PostgreSQL migrations can use the same cutover and assurance workstreams, but each automated engine path still requires its own tested adapter and acceptance suite.
Frequently Asked Questions
Does this replace AWS DMS?
No. AWS DMS and DMS Schema Conversion provide managed migration, replication, conversion, and data validation capabilities. The Factory adds reusable assessment, business-parity evidence, deployment templates, and a human-approved cutover gate, plus customer-specific application and operational delivery.
Why not use schema-conversion percentage as the readiness score?
Schema conversion measures how much database structure and code received a target representation. It does not prove that business workflows, transaction behavior, application integrations, or critical queries produce equivalent results. Readiness must come from executed acceptance tests.
Is Oracle to Aurora PostgreSQL always the preferred path?
No. Aurora PostgreSQL is attractive when open-source modernization justifies the conversion work. RDS for Oracle can reduce operational burden with less application change. Oracle Database@AWS can fit Oracle-specific and Exadata requirements. Redshift fits analytical workloads. The source workload determines the destination.
Where does generative AI help?
It can explain conversion findings, draft remediation for unsupported objects, generate candidate tests, and classify exceptions. It should not approve its own high-risk conversion. Compilation, deterministic tests, domain-owner evidence, and human approval remain the release gates.
What should happen after cutover?
Continue assurance long enough to see production query patterns, locks, connections, storage growth, backups, recovery, cost, and incidents. Compare them with the pilot baseline, fix regressions, and close the migration only after operations accepts the target.
References
[1]AWS, "End of support for AWS DMS Fleet Advisor," 2026. https://docs.aws.amazon.com/dms/latest/userguide/dms_fleet.advisor-end-of-support.html
[2]AWS, "AWS Transform discovery tool data collection," 2026. https://docs.aws.amazon.com/transform/latest/userguide/discovery-tool-data-collection.html
[3]AWS, "Using AI agents with AWS DMS Schema Conversion," 2026. https://docs.aws.amazon.com/dms/latest/userguide/sc-genai-agents.html
[4]AWS Database Blog, "Automate Oracle PL/SQL to PostgreSQL migration with Amazon Bedrock and Strands Agents," 2026. https://aws.amazon.com/blogs/database/automate-oracle-pl-sql-to-postgresql-migration-with-amazon-bedrock-and-strands-agents/
[5]AWS, "AWS DMS data validation," 2026. https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html
[6]AWS, "Troubleshooting migration tasks in AWS DMS," 2026. https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Troubleshooting.html
[7]AWS, "Converting database objects with generative AI in DMS Schema Conversion," 2026. https://docs.aws.amazon.com/dms/latest/userguide/schema-conversion-convert.databaseobjects.html
[8]AWS, "AWS DMS data resynchronization," 2026. https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.DataResync.html
[9]AWS, "Troubleshooting replication latency in AWS DMS," 2026. https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Troubleshooting_Latency.html
[10]AWS Prescriptive Guidance, "Migration cutover stage and rollback planning," 2026. https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-migration-cutover/cutover-stage.html
[11]AWS, "Getting started with Oracle Database@AWS," 2026. https://docs.aws.amazon.com/odb/latest/UserGuide/getting-started.html
[12]AWS, "Modernizing SQL Server workloads with AWS Transform," 2026. https://docs.aws.amazon.com/transform/latest/userguide/sql-server-modernization.html
[13]AWS, "Using Amazon Redshift as a target for AWS DMS," 2026. https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.Redshift.html
[14]AWS, "Amazon Redshift automatic table optimization," 2026. https://docs.aws.amazon.com/redshift/latest/dg/c_ato-enabling-disabling-monitoring.html