Recorded journeys are the cutover gate

A PHP application that has been in production for years is a record of decisions. Some of those decisions are obvious in the code. Many are not. A new Java Spring Boot application can compile, start, and still charge a different amount, skip a message, or write a different row.

A line-by-line conversion does not answer the question the business actually has: when this person does this work, does the new system do what the old one did?

What a journey is

A recorded user journey is one pass through the real product. It includes the response the person received, the database changes that followed, and the messages the system sent. Those three are the behaviour a customer can feel, a ledger can show, and a downstream system can receive.

We record journeys from the running PHP application. A guessed happy path is not a substitute for a journey somebody actually took.

Replay, then compare

The journeys are replayed against the PHP system and the Java system in a deterministic sandbox. Deterministic means the comparison is not at the mercy of a clock, a random value, or a live third party that answers differently the second time.

The checker compares responses, database writes, and outgoing API calls. If they match, that journey is in the evidence report. If they do not, cutover stays blocked.

Where this stops

The report covers recorded journeys. It does not cover a path nobody recorded. We do not treat a recorded match as a description of every behaviour the old system could ever have shown. The gate is exact about its boundary, which is what makes it usable.

Where AI fits

AI can help the people doing the migration. It is not the gate. Generated Java is not evidence. The evidence is the replay: the same responses, the same database changes, the same messages sent, on the journeys that were recorded, before you switch over.