AI-Generated Migration Reports: What They Include

A Report You Can Argue With

Most migration assessments are adjectives. “Moderate complexity.” “Some manual effort required.” Nobody can plan against that, and nobody can challenge it either — which is usually the point.

A useful report has a number behind every claim and a location behind every number. Here is what ours contains and, more importantly, why each section exists.

1. Object Inventory

Counts by type: tables, indexes, views, materialized views, sequences, packages, procedures, functions, triggers, synonyms. The ratio matters more than the totals — a schema that is mostly tables is a data job, and a schema that is mostly packages is a code job. Those have different critical paths, different staffing, and different risks.

2. Data Profile

Segment sizes, row counts, LOB volume, partitioning. This section predicts runtime, and LOBs are the usual surprise: a table that is 40 GB of BLOB moves nothing like a 40 GB table of scalars, because the transfer is dominated by round trips rather than raw bytes.

3. Conversion Rate and the Gap List

The percentage of objects that convert without human intervention — and then, itemised, the ones that don’t. This is the section that decides the estimate, so it names the object, the construct, and the reason:

GAP  MV_SALES_DAILY      FAST refresh      no PG equivalent; use trigger or schedule
GAP  IDX_ORDERS_BITMAP   BITMAP index      B-tree fallback; check selectivity
GAP  PKG_BILLING         autonomous txn    dblink or redesign
GAP  ORDERS              INTERVAL part.    DEFAULT partition + pg_partman

A percentage on its own invites the wrong question (“can you get it higher?”). The list invites the right one: “who owns each of these, and how long does it take?”

4. PL/SQL Surface

Line counts by object, with construct density — the complexity score, and the specific lines that produced it. Sorted so the twenty objects that will consume most of the conversion budget are at the top.

5. Risk and Order

A dependency-aware sequence, because you cannot create a view before its tables or a foreign key before its parent. Plus the risk flags that change a plan rather than just colouring it: circular dependencies, objects with high fan-in, anything touching SYS.

6. Timeline

Built from the sections above rather than from data size, which is rarely the bottleneck: data move, code conversion (PL/SQL lines multiplied by one minus the automation rate), hard constructs (count times hours), application-layer SQL changes, validation cycles, and cutover rehearsals — then a contingency multiplier that rises with hard-construct density.

Because it is composed from measured inputs, you can challenge any single line of it. That is the property that makes an estimate worth having.

What It Won’t Tell You

It cannot tell you whether your application layer has Oracle-specific SQL embedded in it — that lives in your code, not your database. It cannot tell you which of your batch jobs actually still matter. And it will not pretend the hard constructs are easy. A report that reads as uniformly encouraging is a sales document.