The new service answered every request identically to the old one. I diffed them for weeks.
Then a scheduled job ran twice overnight.
What I was replacing was an inherited monolith with a payment layer bolted on over years. I did the careful version of the migration: mapped the HTTP surface, replayed real traffic against both systems, compared responses field by field. The API was the part I could see, so the API was the part I verified.
What I could not see was the half of the system that no request touches. Periodic tasks. Retry policies. A job that assumed the nightly import had already finished, because on the old box it had, run after run. In the new deployment the workers came up in a different order, and that assumption quietly stopped holding.
Nothing crashed. A notification fan-out fired twice, and state had to be walked back by hand. That is the expensive kind of repair: you are not reading an error, you are reconstructing what the system meant to do.
So my first question before a rewrite is no longer about the code. It is this: what runs here while I am not watching? Each periodic task, its cadence, its retry behavior, and whether it is safe to run twice. A non-idempotent scheduled job isn't a job. It's a landmine with a timer.
The other four questions I ask are ones I only earned by getting this one wrong, and I wrote them up on my blog: https://polycratia.com/c/b4672e53
Somewhere in your system there is probably a scheduled job that hasn't been read in two years...