AI and Migration Time: What Our Data Actually Shows

The Number We Won’t Give You

Migration tools advertise time savings as a single percentage. We are not going to, and it is worth explaining why before giving you the numbers we do have.

A migration’s duration is dominated by things no tool touches: how much Oracle-specific SQL is embedded in your application layer, how many environments you must rehearse in, how long change approval takes, and how quickly people answer questions about what a package was for. A vendor quoting “60% faster” is quoting a project whose shape you cannot see, and the honest value of that figure for your planning is zero.

What We Do Measure

One number, measured continuously, on a benchmark you could reproduce: 95.5% of objects convert without human intervention on a synthetic 4,000-object Oracle dump — tables, indexes, materialized views, partitions, packages and triggers in roughly ERP proportions. It runs as a script on every change and a regression fails the build.

Two more, from the same suite: the advisor processes 1,000 objects in well under a second, so assessment is never the thing you wait for; and the 4.5% that doesn’t convert is itemised by construct rather than summarised.

How That Translates — Do the Arithmetic Yourself

Conversion effort is the part automation actually moves, so estimate it directly rather than trusting a blended figure:

conversion effort  =  (objects x (1 - automation rate) x hours per object)
                   +  (hard constructs x hours each)

example, 4,000 objects, 95.5% automated, ~1.5h per manual object:
  4,000 x 0.045 x 1.5h   =  270h
  + 28 hard constructs x 6h  =  168h
                             =  438h  of conversion work

Then compare against your own baseline for doing it by hand. That is a number you can defend in a planning meeting, because every input is yours and every input is challengeable.

Where the Time Actually Goes

• Discovery. Hours, not weeks, once automated — and this is where the largest genuine saving sits, because manual inventory of 4,000 objects is slow and error-prone.
• Schema and code conversion. The automatable part. Scales with the flagged remainder, not the total.
• Data movement. Bounded by hardware and network. A tool can parallelise it; it cannot repeal physics.
• Validation. Faster to run automatically, but the cycles are driven by how many defects you find — which is why finding them early matters more than running them fast.
• Application changes and UAT. Usually the longest phase, and almost entirely outside any migration tool’s reach. Anyone promising a large end-to-end reduction is implicitly claiming to shorten this, which they cannot.

The Saving That Doesn’t Show Up in a Percentage

The largest real reduction isn’t conversion speed — it is rework avoided. A defect found during conversion costs an hour. The same defect found in UAT costs days, because someone must first work out which of 4,000 objects caused it. Every construct flagged up front is a defect that never reaches that stage.

That is unglamorous and hard to put on a slide, which is probably why so few tools talk about it.