Three weeks into rewriting an inherited service, I found a scheduled job nobody had mentioned, writing straight into the same tables.
Not through the API. Not through any code path I was replacing. A cron entry on a box, doing updates directly.
I had read the whole codebase: endpoints, models, queue consumers, all mapped. None of that told me a second writer existed outside the application I was replacing. My new service was correct in isolation and wrong in production, because it assumed it owned its own data.
That cost me a cutover. Not a catastrophic one, but the kind where records drift into a state neither version expects, and you spend days reconstructing what happened from logs instead of shipping.
So now, before I agree to a rewrite, I ask five things before I open the repo:
Who else writes to this data? Not calls the API. Writes.
What is the oldest record that still has to behave correctly? Legacy systems carry rows written under rules that no longer exist in the code.
How will I prove the new path agrees with the old one, when there is no spec? Usually the answer is running both and comparing outputs on real traffic, not tests written from my own reading of the code.
What has to keep running during the cutover, and can the two versions coexist for a while? If the answer is no, it is not a rewrite, it is a launch with no rollback.
And what happens in the first hour after real traffic hits it?
The pattern I keep seeing in inherited systems: the code is the part you can read, so it feels like the risk. The risk usually sits in the couplings nobody wrote down, a cron job, a report pulling directly from a replica, an integration keyed to a field you were about to rename.
I write up more of these migration and payments lessons here: https://polycratia.com/c/ee005aad
For those of you who have done a rewrite of someone else's system: what hidden dependency did you find too late?