The client asked for a maintenance window and we told them we did not need one. That turned out to be the harder promise to keep, not the easier one.
Why there was no good window
The store's traffic follows influencer posts, not a clock. A "quiet Tuesday at 3am" is not quiet if someone with an audience mentions the product that evening. Discovery settled the constraint early: whatever we built had to run alongside the existing checkout logic until we were certain, then switch over in a moment nobody could distinguish from normal operation.
Running two systems in parallel
We shipped the new pricing and discount engine behind a feature flag, reading the same order data as the old one, writing nothing. For eleven days it computed prices silently and logged where it disagreed with the live system.
- Every disagreement got investigated, not just the large ones — a one-penny rounding difference told us more about an edge case than a pound-sized one did.
- The flag flipped per customer segment, smallest first, so a mistake affected a hundred orders rather than all of them.
- Rollback was one flag, not a deploy. We tested the rollback path itself before we needed it, which is the step teams skip when they're confident.
What actually went wrong
One thing: a currency conversion for international orders rounded differently between the two systems, by less than a cent per order, invisible until we added up a day's totals. It would not have shown up in per-order testing. It showed up because we compared the sums, not just the samples.
Parallel running is not a way to avoid mistakes. It is a way to find them while they are still free.
The switch itself
Full cutover took under a minute and generated no support tickets, which was the actual goal — not zero downtime as an abstract metric, but zero customers who noticed.
What we would do differently
Start the parallel run a few days earlier. Eleven days caught the currency issue on day nine; a slower sales week might not have surfaced it in time to fix before a planned peak.