Skip to main content

What Schema Conversion Will Not Rewrite

Cloud ArchitecturePalaniappan P2 min read

Quick summary: DMS Schema Conversion sorts objects into converted, warnings, and will-not-convert. The project is the last bucket plus the SQL that lives in the ORM. A connection-string change is not that backlog.

Key Takeaways

  • On 4 October 2026 the useful unit is the assessment itself: DMS Schema Conversion, not the older Schema Conversion Tool name
  • Where this fails > What broke: Lab, 4 October 2026
  • What to do this week 1
  • 2
  • 3
Four DMS Schema Conversion buckets: auto-converted, warnings, will not convert, and application SQL, with the last two as the project backlog
Table of Contents

The DMS playbook tells you to run an assessment and then says it does not cover ORM rewrites beyond what that assessment flags. The refactor post’s database pattern is still easy to misread as a connection-string change. On 4 October 2026 the useful unit is the assessment itself: DMS Schema Conversion, not the older Schema Conversion Tool name.

The Oracle and SQL Server decision owns the fork: stay licensed, Babelfish, or convert. This page starts only after convert is the choice. Babelfish is partial T-SQL. It is not a zero-rewrite promise, and it is not this backlog.

Four buckets

BucketWhat it isWhat you do
Auto-convertedObjects the assessment converts cleanlyDo not staff a project around this count.
WarningsConverted with a behavior you have not acceptedRead them. A warning is not a percentage.
Will not convertProcedures, triggers, jobs, and types the tool refusesThis is a backlog with owners.
Application SQLStatements in the ORM or the service, invisible to the database assessmentSearch the code. The assessment will not list them.

We recommend staffing the third and fourth buckets before cutover. The trade-off is a longer project than the row-count demo. A weekend cutover that moves tables and leaves procedures behind is how the application fails on Monday with the data already on Aurora PostgreSQL.

Where this fails

What to do this week

  1. Open the latest DMS Schema Conversion assessment. Fill the four counts.
  2. Turn will-not-convert into tickets. Do not average them into a percent complete.
  3. Search the application for vendor SQL the assessment cannot see.
  4. Leave task settings, LOB lag, and the cutover checklist on the DMS playbook.
  5. If the residue is the engagement, talk to RDS consulting.

What this post doesn’t cover

It does not choose Babelfish versus convert, design Aurora Limitless, or walk DMS task settings. It does not claim a percentage of objects that convert. That number is whatever your assessment says.

Frequently asked questions

Why does the application fail after DMS moves the data?
Because the assessment's will-not-convert objects, and the SQL that lives in the application rather than the database, were not staffed. Auto-converted tables moving rows is the part DMS does. Procedures, triggers, agent jobs, and vendor SQL in an ORM are the residue.
When should we not schedule cutover?
Do not schedule cutover while the will-not-convert bucket and the application-SQL bucket are unread. Those two are the backlog. The auto-converted count is not evidence that the application will run.
What could go wrong if we treat warnings as noise?
A warning is a behavior you have not accepted. Shipping it as converted means the first production path that hits that object fails after the data is already on Aurora. Read warnings as a list, not as a percentage.
Is this the Oracle and SQL Server decision?
No. That article chooses stay licensed, Babelfish, or convert to Aurora PostgreSQL. This article starts after convert is the choice, and it reads the assessment. The DMS playbook still owns task settings and the cutover weekend.
Should we still say Schema Conversion Tool?
No. The current product name is DMS Schema Conversion. Older posts say SCT. Do not open a third name in the plan.
Palaniappan P
Palaniappan P

AWS Cloud Architect & AI Expert

AWS-certified cloud architect and AI expert with deep expertise in cloud migrations, cost optimization, and generative AI on AWS.

AWS ArchitectureCloud MigrationGenAI on AWSCost OptimizationDevOps

Recommended Reading

Explore All Articles »