A rewrite is a data migration with a code change attached. Most people plan only the code change.
The new codebase is the part you control. The data is the part that already happened: written by versions of the system nobody has read in years, by admin tools, by one-off SQL patches, by jobs that still run on a schedule.
So before a rewrite I ask five questions about the data instead of the architecture.
-
Can the new schema hold every row that already exists, not the rows you would design for today? Old rows violating new invariants is the normal case, not the edge case.
-
What writes to this table that is not this codebase? A background job, an internal panel, a neighboring service, a human with psql. Each one is a second source of truth you now have to port or cut off.
-
Which fields are load-bearing only in history? Live code ignores them. Reconciliation, ledger exports and compliance reviews do not. Dropping a column is cheap right up until someone has to explain a payment from two years ago.
-
Where does the data disagree with the model? Columns the ORM calls nullable that are required in practice, enums that grew values nobody declared. The real constraints live in the rows, not in the definitions.
-
What happens to a row you cannot migrate? Block it, quarantine it, or fix it by hand: decide that before the cutover, because during the cutover you will pick whatever is fastest.
Green tests mean your code is right. Data that agrees means the rewrite is actually done.
I go deeper into the data side of legacy modernization on my blog: https://polycratia.com/c/59b0f116
If you've been through one, I'd guess most of the work ended up in the data rather than the code...