What a Migration Assessment Report Should Include
The Report Is the Decision
A migration assessment report is the artifact that turns "we should move off Oracle" into a plan you can staff, schedule, and defend in a budget meeting. Done well, it's the most valuable document in the whole project — it sets the timeline, the team size, and the risk posture before anyone writes a line of conversion code.
Done badly, it's a glossy PDF full of adjectives — "complex," "significant effort," "some manual work required" — that commits you to nothing and protects no one. The difference is specificity. A good assessment report is numeric, reproducible, and honest about the hard 5%. Here are the ten sections it should contain.
The Ten Sections
| # | Section | What it must answer |
|---|---|---|
| 1 | Executive summary | One page: the verdict, the headline numbers (objects, data size, % auto-convertible), the risk level, and the rough timeline. A CFO/CIO should grasp the scope in 60 seconds. |
| 2 | Object inventory | Counts per schema and object type — tables, views, packages, triggers, sequences, types, jobs. The table-to-package ratio tells you if this is a data move or a code project. |
| 3 | Data profile | Total size, largest tables, LOB volume, partitioned tables. Drives bulk-load runtime and whether CDC is needed to keep the cutover window short. |
| 4 | PL/SQL surface + automation rate | Total lines of PL/SQL and the measured percentage that transpiles automatically (not a guess). The single best predictor of conversion effort. |
| 5 | Hard-construct catalog (the 5%) | Every construct that needs a human decision — packages-with-state, autonomous transactions, CONNECT BY, XMLTYPE, AQ, DB links — counted and located. This is the section that earns trust. |
| 6 | Dependency & load-order map | Circular foreign keys and cross-schema references, so the load order is deterministic and constraints can be deferred safely. |
| 7 | Risk scorecard | Each axis (data volume, code volume, hard-construct density, dependencies, platform features) scored low/medium/high, rolled into one readiness signal. |
| 8 | Effort & timeline estimate | A phase-by-phase estimate derived from the numbers above — not from database size alone — with an explicit contingency factor. |
| 9 | Recommended approach | The concrete plan: logical vs CDC cutover, phasing, which tables go first, validation strategy. An assessment without a recommendation is just data. |
| 10 | Evidence appendix | The raw queries and outputs behind every number, so the report is reproducible and auditable rather than “trust me”. |
Every Claim Needs a Number
The test for any line in an assessment report: could two engineers read it and arrive at the same plan? "Significant PL/SQL" fails. "62,000 lines of PL/SQL across 40 packages, ~95% auto-convertible, 18 constructs flagged for review" passes — it tells you exactly how many engineer-days of review to budget. Replace every adjective with a measurement:
- "Large database" → 35 TB; largest table 18.1 GB; 4 partitioned tables
- "Some complex code" → 18 hard constructs (3 autonomous txns, 5 CONNECT BY, 2 packages-with-state…)
- "Manual effort required" → ~3,000 lines for human review ≈ 2 engineer-weeks
- "Low risk" → risk score 6/15; one orange item (no CDC plan for the 18 GB fact table)
Red Flags of a Useless Report
- No hard-construct list. If it doesn't name the 5% that needs human work, it hasn't actually looked.
- A single automation percentage with no basis. "90% automated" with no per-object breakdown is marketing, not assessment.
- An estimate anchored on data size. Timeline driven by gigabytes — ignoring code and application-layer SQL — is the classic under-estimate.
- No recommendation. Data without a plan pushes the hard decisions back onto you.
- Not reproducible. If you can't see the queries behind the numbers, you can't trust them.
Generating It Automatically
Most of this report is mechanical — it's reading the data dictionary and the PL/SQL source and counting. DBMigrateAIPro's assessment produces all ten sections in about a minute: the object inventory, data profile, PL/SQL surface with a measured automation rate, the flagged hard-construct catalog, the dependency map, and a Migration Advisor risk score — with the raw queries saved as the evidence appendix. You start from a complete, reproducible report and spend your time on the one section a tool can't fully write for you: the judgement calls in the recommendation.
The Honest Verdict
A migration assessment report isn't a formality you produce to start the project — it isthe project's first and most important deliverable. Insist on the ten sections, demand a number behind every claim, and make sure it names the hard 5%. A report that does those three things turns a risky migration into a planned one.
Get a real assessment report in a minute
DBMigrateAIPro's assessment is read-only, runs in about a minute, and produces all ten sections with the evidence behind them. Free for Year 1 — no signup, no license key.
- 🔗 Download the desktop tool: medaxai.com
- 🔗 Related — How to Assess Your Oracle Database Before Migration
- 🔗 Related — Building a Migration Risk Matrix: Step by Step