How to Estimate Migration Timeline: The Honest Formula

Why Migration Estimates Are Wrong in the Same Direction

Ask three teams to estimate the same Oracle-to-PostgreSQL migration and you'll usually get three numbers that are all too low — and all wrong for the same reason. They anchor on the most visible quantity: data size. "It's a 2 TB database, so it's a big project." But moving 2 TB is rarely the hard part. A modern pipeline streams it in hours. The estimate goes sideways because the work that actually consumes the calendar — code conversion, the handful of hard constructs, application-layer changes, and validation cycles — never got its own line.

The honest formula budgets each driver separately. It produces a bigger number than the gut estimate, and that's the point: the bigger number is the one you can actually hit.

The Formula, in Plain Terms

Total effort is the sum of seven phases, each driven by something you can measure in the assessment — not by database size alone:

Total = Assessment
      + DataMove        (size ÷ throughput, divided by parallel workers)
      + CodeConversion  (PL/SQL lines × (1 − automation_rate) ÷ review_rate)
      + HardConstructs  (count of design-decision items × hours each)
      + AppChanges      (Oracle-specific SQL in the application layer)
      + Validation      (dry-runs × cycle time, until proof comes back green)
      + Cutover         (rehearsals until the runbook is boring)
      ────────────────────────────────────────────────────────────
      × Contingency     (×1.3 typical; ×1.5 if hard-construct density is high)

Notice what's not the dominant term: DataMove. On most projects it's the smallest of the seven. The terms that grow your timeline are code, hard constructs, and application changes — and those scale with the assessment's PL/SQL surface and hard-construct count, not with gigabytes.

Where the Time Actually Goes

A rough share of effort for a typical enterprise migration. Your mix shifts with the assessment — a code-heavy schema pushes conversion up; a data-heavy, code-light schema pushes everything down:

A Worked Example

Take a real-shaped database: 800 GB, 120 tables, 60,000 lines of PL/SQL across 40 packages, 18 flagged hard constructs, and a Java application with ~400 Oracle-specific SQL statements.

• Data move: 800 GB at a sustained load rate, parallelised across 8 workers → on the order of a day of wall-clock, run unattended. Not the bottleneck.
• Code conversion: 60,000 lines, ~95% automated, leaves ~3,000 lines for human review. At a careful review pace that's the better part of a couple of engineer-weeks.
• Hard constructs: 18 items averaging half a day of design + implementation + test → ~9 engineer-days.
• Application changes: 400 statements to inventory, swap (ROWNUM, NVL, DECODE, sequences), and test — often the single most underestimated phase.
• Validation: two or three full dry-runs to green, each gated on a clean validation report.
• Cutover: two rehearsals until the runbook runs without surprises.

Sum the engineer-effort, apply a ×1.3 contingency, and you have a defensible number — one where the data move, the thing the gut estimate fixated on, was a rounding error against the code and application work.

The Contingency Multiplier Nobody Likes

Every honest estimate carries a contingency factor, because the assessment finds the known unknowns but never all of them. The multiplier scales with hard-construct density — the part of the schema where surprises live:

• ×1.2 — code-light, data-heavy schema; few hard constructs.
• ×1.3 — typical mixed enterprise schema.
• ×1.5 — high package-with-state density, heavy AQ / DB-link / autonomous-transaction usage.

Padding an estimate isn't pessimism — it's the honest acknowledgement that the 5% of code needing a design decision is exactly the 5% you can't fully scope until you're in it.

Where the Inputs Come From

Every variable in the formula is an output of the assessment: data volume and largest table, total PL/SQL lines, the hard-construct count, and the dependency map. DBMigrateAIPro's assessment produces all of them in about a minute, and the automation rate isn't a guess — the transpiler reports what it converted cleanly versus what it flagged for review. That turns the estimate from an argument into an arithmetic exercise.

The Honest Verdict

A good migration estimate isn't a single number pulled from database size — it's seven measured phases plus a contingency that respects what you don't yet know. Do it that way and you'll quote a bigger number than the team that anchored on gigabytes. You'll also be the team that hits its date.