A rewrite rarely fails on code. It fails on state.
Code is the part you can read: diff it, test it, delete it. What kills a rewrite is everything the old system knows that stayed out of the code entirely. It lives in rows, in cron jobs, in the habits of the people who operate it.
So, the five questions I want answered before anyone writes a line:
-
Who writes to this database besides the application? Legacy systems collect writers: an admin script, a nightly job, a support tool, sometimes a human with psql. Every writer you can't list is an invariant your new code doesn't know it has to preserve.
-
Which business rules exist only as data? Status values few people can enumerate, a config table that changes behaviour, rows hand-corrected by support during an incident. Rewriting the code preserves none of that.
-
Who reads your tables directly? Reporting, analytics, another service that was not supposed to. Change the schema and you break consumers missing from the architecture diagram.
-
Which guarantees come from the runtime rather than the design? Ordering, single-worker assumptions, a lock that works because there is exactly one process. Services multiply processes, and accidental serialization is the first thing to go.
-
How will you prove the two systems agree? If the answer is not a comparison you can run continuously during a dual-run, you don't have a migration plan. You have a launch date.
In money systems the fifth one is not optional. Reconciliation between old and new is the only thing that tells you the rewrite is correct, and it has to exist before cut-over, not after.
I write about this in more depth on the blog, and this one is the long version: https://polycratia.com/c/2a908e4c
If you've been through a rewrite, you probably found something writing to your database that had slipped off the list...