Most rewrite estimates are built as if the old system will politely wait while the new one is built. It will not. It keeps taking support tickets, keeps needing security patches, and keeps changing underneath the migration plan.
The two workstreams nobody prices separately
A rewrite is really two projects running at once: building the replacement, and keeping the original alive and correct while that happens. Estimates that only price the first one are consistently wrong, in the same direction, by roughly the same margin — because the second workstream does not disappear just because it was not on the plan.
What we now price explicitly
- Parallel maintenance — bug fixes and urgent changes to the old system during the build, estimated as ongoing capacity, not treated as a rounding error.
- Data drift — the old system's data keeps changing shape as it is used, and the migration has to account for a moving target, not a snapshot taken at the start.
- Feature parity creep — stakeholders discover requirements the old system quietly satisfied that were never written down anywhere, because nobody had to write them down while the system already did them.
Why we now build a comparison harness early
Rather than migrating everything and testing at the end, we build a way to run both systems against the same input and compare outputs, as early as the new system can produce any output at all. This turns "does the rewrite match the original" from a single terrifying question at the end into a running number the team watches throughout.
A rewrite is not finished when the new system does everything the old one did. It is finished when nobody needs the old one to check whether the new one is right.
The conversation this makes possible with a client
Naming both workstreams up front lets us have an honest conversation about the actual timeline, rather than a comfortable one that gets revised downward every month once the parallel maintenance cost becomes visible. Clients generally prefer the honest conversation once they have been through the alternative once.
What determines whether a rewrite is worth it at all
The size of the parallel-maintenance cost is itself useful information. If keeping the old system alive during a build turns out to require more effort than expected, that is often a sign the rewrite should be staged — replacing the system in pieces — rather than attempted as one long parallel effort with a single cutover at the end.