Telling a modernization team they cannot have a planned outage changes the nature of every decision they make, starting with the architecture of the rollout itself. It rules out the most familiar pattern in software delivery, the clean cutover, and forces a different approach: running old and new in parallel, routing a small and growing share of real traffic or load to the new system, and confirming equivalence at every step before the share increases further.
The technical version of this is well understood: shadow traffic, canary releases, feature flags that can be reversed in seconds rather than redeployed over hours. The harder version is operational. Someone has to be willing to run two systems at once for longer than feels comfortable, absorbing the cost of that duplication, because the alternative, moving faster than the validation supports, is the path that actually produces an outage.
The organizations that pull this off tend to treat the parallel-running period as the actual project, not as overhead standing between them and the real work. They build monitoring specifically designed to catch subtle behavioral differences between old and new, not just outright failures, because in a live-public-system context, a subtly wrong answer delivered reliably is often worse than an obvious failure that's immediately noticed and routed around.
It's slower than most stakeholders want it to be, and that's the wrong place to compress. The schedule risk of moving carefully is a delayed go-live. The schedule risk of moving quickly is an incident, with everything that follows from it, in a system the public has no alternative to and no patience for.