Before a rewrite, the questions worth asking are about the overlap period, not about the new architecture.
The target design is the cheap part. You can draw it in an afternoon, and most senior engineers will draw something defensible. Rewrites die in the months where both systems are alive and the data has two authors.
So the five questions I actually ask:
-
During the overlap, which system authors each table? If both write, the invariant has to be enforced in exactly one place. Otherwise two correct state machines produce one incorrect ledger.
-
Can you compare outputs instead of trusting tests? Run the new path in shadow against real traffic and diff the results, including the inputs nobody designed for. Tests encode what you already understood.
-
Can you move one flow instead of the whole service? If the smallest shippable unit is "all of it", the seam is wrong. Pick a seam where one caller and one write path line up with one owner.
-
Can you reverse a flow after it has written rows? That means retained raw inputs and version-stamped derived data. Without those, rollback is a rewrite of its own.
-
What proves the old path is dead? Something has to count calls per caller. Otherwise an admin panel or a nightly job keeps writing through the code you believe you retired.
None of this is about code quality. It is about who authors data and how you observe divergence. Also whether you can undo a step.
I have run Python 2 to 3 migrations and monolith-to-services rewrites on systems handling money, and in every one the hard decisions were migration-order decisions rather than design decisions.
I wrote up how I sequence this, shadow-and-diff setup included, here: https://polycratia.com/c/c826fffe
If you have done a rewrite on a live system, tell me what finally told you the old path was safe to delete...