You have seen how a build proves itself. This is why the conversation is happening this year rather than next.
That is the actual problem with a legacy application, and it is not the one most migration pitches address. Marcus reads your source — the screens, the schema, the rules buried in code nobody has opened in years — and turns it into a specification you can argue with before anyone writes a line of the replacement.

Why now
The timing argument is not ours — it is the vendors’. Some of these have already passed. Each one turns “we should modernise sometime” into a budget line with a date attached.
We will not pretend this applies to everyone. A support date only matters if you are on the version it affects — plenty of estates have years of runway and will know it. The honest question is which version you are actually running, and that is the first thing we ask.
How the engagement runs
We extract what your platform will give up — screens, schema, permissions, the rules buried in code — and hand back an inventory of what is recoverable and what needs a decision.
Credited toward onboarding if you proceed. If the answer is that we cannot help, the report says so and you keep it.
The assessment does not end with a range. It ends with a date for a working replacement, sized from what we actually found in your source.
Miss that date and the assessment fee comes back. We never name a calendar before reading the system — which is exactly what keeps the promise honest and the exposure small.
Functional parity against the specification you approved, your data migrated into a parallel environment, security tested for every role, and the evidence to show all of it.
You are running both systems side by side before anything is switched off.
The second application costs less than the first. The extraction path, the conventions and the shared model already exist by then.
Which is why the first one is worth doing properly rather than quickly.
What the clock does not cover. Cutover, single sign-on and network work, third-party licences, remediating source data that turns out to be wrong, and anything added after the scope gate. It also pauses when we are waiting on a decision from you — we answer within three business days, and time past that moves the date one for one.
Pick your platform
Each of these is specific — the extraction path, the honest comparison against the alternatives including doing nothing, and what typically goes wrong.
Including an honest account of why the vendor's own AI tooling will not convert it.
The design report is the most readable source of any platform on this list.
Green screens become web and mobile while RPG keeps doing what it is good at.
For an M365 shop whose forms and workflows just stopped being supported.
So the question is only what you rebuild onto, and how the in-flight work lands.
Reader and Author fields become real permissions, with tests that prove it.
Which makes rebuild the vendor-endorsed route, not the expensive alternative.
A spec-then-rebuild route, against the track record of transpilers.
Against modernise-in-place and against transpilers, not only against doing nothing.
The Z-transactions that clean core says to move out of the core, rebuilt.
The irony being that where you land is also Java — just one somebody else patches.
One extraction pipeline across the process formats, whichever suite they came from.
One rescue story, with a per-platform table of what can be recovered.

Not on the list? The approach is the same whatever the platform: get the machine-readable definition out, turn it into a specification you can argue with, and rebuild against that.
Tell me what you are running and you will get a straight answer about whether it is recoverable — including “no” if that is the answer.
Tell Marcus where you are — you will leave with a range, the assumptions behind it, and the answers that would narrow it.
Step 4 of 6 — Why now?
That is the pressure. What it costs to answer it is not one number — three things move it.