What a MigrateForge evidence report shows
What the report covers before cutover — responses, database writes, outgoing API calls, and the journeys that were actually recorded.
The evidence report is the document that decides whether a wave can cut over. It lists what was verified.
The three comparisons
For each recorded journey the report covers:
- Responses. What the PHP system returned, and what the Java system returned.
- Database writes. The rows the PHP system changed, and the rows the Java system changed.
- Outgoing API calls. The messages the PHP system sent, and the messages the Java system sent.
A journey is verified when those three match. The same rule blocks cutover: replay both systems in a deterministic sandbox, and do not switch a wave over while a recorded journey still differs.
How to read a pass
A pass means the recorded journeys in that wave matched. In the work published so far, four migrated waves across two PHP applications reached 100/100/100 parity on 858 verified journeys, and every data write was verified. InvoicePlane’s public benchmark reached 100% parity on waves 1 and 2. A pass is not a statement about journeys that were never recorded.
What the report leaves out
It does not say that every possible behaviour of the old system was exercised. If a journey was not recorded, it is not in the report. The honest next step is to record it, replay it, and let the gate do its job.
What else you keep
The report sits with three other outputs: the Java Spring Boot code, the defects the checker found, and requirements reverse-engineered from the running PHP application. The defects are the mismatches. They are the reason a wave waits.