AWS DMS Pre-Flight Check

How the pre-flight check reads your schema

Export your schema as DDL and paste it in. The parser walks every CREATE and ALTER statement, builds an inventory of the objects it finds, then applies the rules for your chosen source engine to decide which of them a DMS task will actually carry. It is tolerant by design: statements it cannot interpret are skipped rather than treated as errors, so a partial or hand-edited dump still produces a usable count.

Nothing is uploaded and nothing is stored. The parsing runs in the page, which is why it needs no connection string and no credentials. For the reasoning behind each rule, the full argument is in AWS DMS limitations: what it won’t migrate for you.

How to read the manifest

The result is one document in two halves. On the left is what DMS carries: your tables, their column definitions, the primary key, and the data itself via full load plus CDC. That side is short, and it is meant to be.

On the right is everything else, and each entry there is split again by who does the work:

• Do it yourself marks the mechanical fixes. Secondary indexes, foreign keys, check constraints and grants can all be scripted straight from the source DDL by anyone on your team. Nothing about them needs advice.
• Needs judgement marks the ones where the fix depends on which of several approaches suits your situation: stored procedures, triggers, sequence reseeding, partitioning, and any column whose type has no clean equivalent on the target.

Findings that change the plan sort to the top regardless of how many objects they involve, so a single keyless table outranks four hundred foreign keys. The count beside each entry is a floor rather than an audit.

Why tables with no primary key come first

Ongoing replication needs a key to identify which row changed. A table with no primary key and no unique index can be full-loaded but never kept in sync by CDC — so it has to be frozen or reloaded inside the cutover window. Audit tables and staging tables are the usual offenders, because nothing ever read them by row and so nobody added a key.

This is the single most expensive thing to discover late, which is why the check sorts it to the top of the list rather than burying it under whichever object class happens to be most numerous. Finding it during the dress rehearsal means redesigning a key under time pressure; finding it now means it is a line in the plan.

Set the engines before you read the result

The same schema is a different project depending on where it lands, so the source and target selectors are not cosmetic. Pick the same engine on both sides and the check reports a homogeneous migration, relaxes the rules on views, and says so in the manifest header. Pick different engines and it assumes a dialect conversion, which changes both the effort tags and the data-type columns it flags.

The source engine also selects which type rules run. A rowversion column only matters coming from SQL Server, LONG and BFILE only from Oracle, ENUM only from MySQL. Set it wrong and the count is still valid for object classes but misses the columns that cause silent data loss. Why the two migration shapes differ so much is covered in the DMS limitations guide.

What this tool cannot tell you

It reads a schema, so it sizes scope and never duration. Row counts, data volumes, workload and network throughput are not in a DDL dump, and any tool claiming to estimate your migration time from DDL alone is guessing. The parser is also deliberately tolerant: it skips statements it cannot interpret rather than failing, so treat every count as a floor rather than an audit.

For the reasoning behind each rule here, the full breakdown is in AWS DMS limitations: what it won’t migrate for you. If the right-hand column came back longer than you expected, tell me what you are migrating and I will look at it with you.