Parallel running without tears
Run old and new side by side, compare everything, believe the diffs. The discipline that removes drama from cutovers, and its three costs.

Parallel running is the closest thing modernization has to a cheat code: the new system does the work, the old system does the work, and a comparator tells you where they disagree before any customer does. It removes the cliff from the cutover entirely. It also has three costs, and pretending otherwise is where the tears come from.
The pattern, in its working form:
- Mirror the inputs. Same requests, same batch files, same feed, to both systems. Production traffic, not synthetic; synthetic traffic validates your imagination, not your estate.
- The new system's outputs go nowhere at first. Shadow mode: compute, record, compare, discard. GitHub built a whole library culture around this move (Scientist, for in-process experiments), and the shape generalizes to whole systems: candidate runs alongside control, results measured, customers untouched.
- Diff everything, then triage the diffs into the only three buckets that exist: new system wrong (fix it), old system wrong (the fun bucket: you have been shipping this bug for years, now with evidence), and definition drift (rounding, ordering, timezone; decide the canonical answer and write it down).
- Promote by evidence: when the diff rate for a slice holds at zero across a full business cycle, that slice earns real traffic. Not before.
Now the three costs, priced without varnish.
Compute is the cheap one: yes, you run two estates for months. Compare that line to one bad cutover weekend and sign it.
The comparator is the real engineering. Building a comparison harness that handles volume, tolerates known drift, and produces a readable morning report is a project, with an owner. Shops that assign it to "whoever has time" get a comparator nobody trusts, which is worse than none, because it manufactures false confidence at scale.
Side effects are the dangerous one. Two systems both sending the invoice email is not a parallel run, it is an incident. Every outbound effect (emails, payments, EDI, webhooks) needs an explicit policy: suppressed, stubbed, or routed to a sink, per effect, reviewed by someone who knows what the partner on the other end does with duplicates.
One more rule from scar tissue: put a calendar limit on the parallel phase before it starts. Parallel running is comfortable, and comfort is how shops end up running two estates for three years, paying double and calling it prudence. The comparator's zero-diff month is a green light, not a lifestyle. Take the exit.