Legacy modernization

The risk comes from behaviour that is undocumented, that the business relies on, and that nobody currently at the company remembers. The dangerous moment is the switch to the new system, when a hidden behaviour the old system happened to have goes missing from the new one and nobody notices until it affects a customer or a report.

We read the whole existing system before changing any of it, which is one task AI tooling handles well: a codebase that would take a person weeks to understand fully can be described in days. That reading finds the hidden behaviour the business relies on that nobody wrote into a process document, which is exactly the part a rewrite is most likely to lose.

It is a set of tests that captures what the old system actually does, built by observing the running system rather than by reading its documentation, then treated as the specification the new system has to meet. Building it first, before the new system exists, means the replacement is being measured against real behaviour instead of against someone's memory of what the old system was supposed to do.

The new system has to pass the behavioural test suite before anything is switched over, and after that the old and new systems run in parallel with their outputs compared until they agree. That parallel-run period is what turns 'we believe it matches' into a measured fact, since disagreements show up as clear output differences rather than as a feeling that something might be wrong.

Eight to sixteen weeks depending on surface area is the range we scope to, not a measured average, since this describes an engagement pattern rather than a record of past projects. Surface area, meaning how much of the old system's behaviour actually needs to be reproduced, is the main factor, more than the age or size of the codebase on its own.

No, the point of running the old and new systems in parallel with output comparison is specifically to avoid a sudden stop. The business keeps using the system it already trusts while the new one is validated against real, live behaviour, and the switch happens once the comparison shows they agree rather than on a fixed calendar date.

That is the normal starting condition for this kind of project, and it does not stop the project. Reading the system directly, rather than relying on what past staff remembered, which may no longer exist, is why we characterise the codebase from its actual behaviour first. The behavioural test suite becomes the durable record of what the system does, which the team did not have before.

Not necessarily, and that judgment happens during the read-the-whole-system phase before any rebuild decision is made. Some systems need a full replacement because the underlying platform is the problem; others need the logic the business relies on taken out and rebuilt, with the rest left alone. The behavioural test suite is useful either way, since it documents what has to be preserved regardless of how much is rewritten.