Rewrites rarely fail on the code. They fail because the only authoritative specification of the old system is the data already sitting in production.
Inherited systems carry years of decisions that went undocumented. The code tells you what runs today. The stored rows tell you what was actually accepted over time, and those are two different documents.
So the five questions I ask before anyone writes a line of the new thing are all about recovering that unwritten spec.
One. Which behaviours are intentional, and which are accidents that something downstream now depends on? In the source they look identical.
Two. What does the data actually contain, versus what the schema claims? Columns that are nullable and never null. Status values the enum permits that nothing has produced in years. Free-text fields quietly carrying structure, because a deadline said so.
Three. Which operations are irreversible: money moved, a document signed, a token minted? You cannot replay those against the new system to compare outputs, so they need a different verification strategy entirely.
Four. Who else reads the old shapes? Exports, reconciliation reports, partner integrations. The database is rarely a private implementation detail.
Five. How will you prove equivalence on real traffic before cutover, rather than on fixtures you wrote from your own reading of the code?
The scope of a rewrite comes from the obligation of the new system to accept the old system's history, not from the code you dislike.
If you have done one of these, I am curious which of the five you found out about late...