Assess, prove, execute, decide, transform.

In that order, because each phase is only worth building once the one before it has earned trust. The parts everyone wants on day one are attempted last.

Now
Phase one, one language pair, read-only
First pair
Java with Oracle to a modern JVM stack. .NET Framework second
Standalone
Phases one and two each sell on their own
Assess
F1, F2, F3

Ingestion, the system model and clarification for one language pair. No code is written and no write access is required, so it clears security review in weeks rather than never.

System map, risk register, confirmed rules, a generated task board
Prove
F8 test generation

Characterization tests for untested legacy code. Still purely additive, nothing changes behaviour, and it is the prerequisite for every phase after it.

Behaviour pinned before anything is permitted to move
Execute
F5, F6, F7

Narrow scope on purpose: dependency upgrades, dead code removal, test backfill. Agent-authored pull requests, human review, differential replay before merge.

The first merged change the platform can stand behind
Decide
F9

Migration decisions with constraint propagation. Recommendations are only worth reading once the model they rest on has been checked against reality.

Architecture decision records that bind downstream work
Transform
Full scope

Agent execution on service extraction, schema migration and framework replacement. The genuinely hard work, attempted with a model and a safety net rather than without.

The migration everyone asked for on day one
How success is measured

Three families, and only one of them is allowed to matter most.

Understanding

Evidence depth per module. Proportion of live code covered by a confirmed rule. Clarification compression ratio, targeting better than fifteen to one. Median time to answer, by role.

Throughput

Tasks verified per week. Agent completion rate without a human takeover. Time from a task becoming ready to the change being merged.

Safety

The ones that matterUnexplained differences reaching merge, target zero. Assumptions outstanding at cutover, target zero. Production defects traceable to a wrong or missing assertion.

Anti-metrics.

Do not optimise for questions answered, tasks generated, or lines migrated. Each of those produces a mill that looks busy and delivers nothing, and each is the number a struggling programme reaches for.

What could sink this, and what is being done about it.

RiskSeverityMitigation
Verification is the hardest component and gates everythingCriticalBuild it first. Ship test generation as a standalone product before any agent writes code.
Useful depth across any language is not achievableCriticalShip one source and target pair. Tier support honestly and cap claimed confidence by tier.
Blocking freezes the programmeCriticalA precise dependency graph keeps blocks narrow. Blocks are explained and traversable, experiments provide an unblock path, and override is documented.
Question fatigue kills adoptionHighClustering, a per-person concurrency cap, the stakes line on every question, and session framing.
Sandbox cost per agent-hour destroys marginHighAggressive snapshotting, hibernation, per-task compute budgets, and cost shown live in the run view.
Enterprises refuse production accessHighDegraded modes with the cost of each gap stated. Snapshot ingestion. On-premises from day one.
Incumbents extend into this spaceMediumThe evidence join and the verification loop are the defensible parts. The editor never was.

Still open.

A product built on refusing to guess should not pretend its own design is settled.

Java with Oracle moving to a modern JVM stack has the largest market and the best existing tooling to build on. .NET Framework is the obvious second. Committing to one pair is what makes the depth claim honest, and choosing wrong costs a year.

Without runtime evidence the central join does not function, and the product degrades into a static analyzer with better prose. There is a level of instrumentation below which the platform should decline the engagement rather than deliver a weaker version of itself. Where that line sits is not yet decided.

A named owner with a date may be sufficient, and adding approval chains may simply reproduce the meeting culture the decision record was meant to replace. The counter-argument is regulated industries, where an unapproved architectural choice is not a choice at all.

Analyzer improvements and assertion patterns get better with every system seen, and none of that may leak anything customer-specific. The separation between a generalisable detector and a customer's business rule needs to be structural, not a review step.

Per system assessed, per seat, per agent-hour, or per verified task. Each one drives very different product behaviour, and per verified task is the only one whose incentives point the same direction as the safety metrics.

Phase one, as a working prototype.

Read-only assessment, clarification, and a task board generated from the model.