“Turn it off and turn the new one on” sounds brave in a deck and terrifying on a Tuesday.
A support lead once told me he could “hear” the alerts before they pinged. Their login service was a museum piece. Everyone was scared of it. The CFO said, “No downtime.” The team said, “No way.” We chose a different path: grow the new system around the old one until the old quietly fades.
The garden version (no jargon)
- Identify a small branch where customers feel pain.
- Grow a new branch next to it that solves that pain.
- Reroute a trickle of traffic to the new branch.
- Watch it closely. Prune. Strengthen. Expand.
- Repeat until the old branch is no longer needed. Remove it.
Where to start
Pick a seam where:
- You can measure success quickly
- The data you need is accessible
- The blast radius is small if something goes wrong
- One team can own it end-to-end
A quiet win that changed everything
We started with password resets—high pain, low complexity. 5% of traffic went to the new path behind a feature flag. Two weeks later: zero critical incidents and a faster time-to-reset. We moved to 25%, then 50%. Six months later, we deleted the old code. No ceremony. Just relief.
Metrics that matter
- Success rate (does the new path work?)
- Time to complete (is it faster?)
- Support tickets (is it calmer?)
- Opt-in demand (are teams asking to use it?)
Avoid these traps
- Big-bang cutovers “because we’re tired”
- Mixing old and new responsibilities in one place
- Hiding progress from stakeholders (silence breeds fear)
- Skipping observability (“we’ll add logging later”)
What to tell stakeholders (plain language)
- What changed: “Password reset is now handled by the new service for 25% of users.”
- Why it matters: “Fewer resets fail; faster for customers; lower support load.”
- How we’re watching: “Dashboard on success rate and time-to-reset; on-call rotation updated.”
- How to reverse: “Flip flag to 0%; old path still works.”
Modernization doesn’t need a hero moment. It needs steady movement and small wins that add up.