The rewrite shipped clean. Three days later a payout sat in a state nothing could move it out of, and I spent that evening writing SQL against production.
The old system had a button for exactly that. I hadn't ported the button.
It was in no spec. The inherited admin panel carried maybe a dozen strange actions piled up over years: force re-attribution of a payment that arrived with mangled requisites, re-send a verification request after the provider silently dropped it, close out a document stuck waiting on a signature that was never coming. I read all of it as legacy clutter from people who hadn't modelled their domain properly.
It wasn't clutter. It was the recovery layer: the written record of every way that system had actually failed in production, encoded as buttons for the people who had to clean up.
The new service was tidy and had none of that. So for the first week after launch, recovery meant me, by hand, on a database holding money and signed documents. No review, no audit trail, no second pair of eyes. That is a far worse risk than the ugly admin panel I replaced.
Now I ask five questions before I touch an inherited system, and none of them are about architecture:
What does the operations or compliance team do by hand today, and how often?
Which of those actions touch money or a legally binding document?
Which exist only because an external provider fails or goes quiet?
When a record gets stuck between two states, who unsticks it, and with what tool?
If the answer there is "nobody yet", what happens in week one?
My take: the old admin panel is the incident history of the system. Read it before you delete it.
I write up more of how I de-risk inherited systems on my blog, if that's useful: https://polycratia.com/c/6c4bfa83
If you're planning a rewrite, go find the one manual fix your ops people would miss on day one, before the cutover rather than after...