A rewrite is a data migration with a code change attached. Most rewrite checklists ask about the code, and the code is the part you already control.
Five things I check first, and none of them live in the repo:
Who else writes to this database. The application is almost never the only writer. There is an admin panel, a nightly job, an analytics process, a partner integration someone added years ago. Every writer you miss turns into a corruption path the moment both systems are live.
Where state lives outside the schema. Queued messages, scheduled retries, tasks already in flight. A Python 2 to 3 migration teaches you this fast: a queue full of payloads serialized by the old interpreter does not care that your new consumer is correct.
What the cutover unit is. If you cannot name a slice you can move and move back the same afternoon, you do not have a migration plan. You have a launch date.
How you prove the new path agrees with the old. On money paths that means a shadow run compared on the ledger, not on logs. Diff the balances, not the HTTP responses.
What happens to whatever is mid-flight at the instant you switch. An operation authorized by the old system and completed by the new one is where the gaps actually show up.
The code you can read. The behavior around it you have to go and find.
If you have cut over a payment path, I'd like to hear whether you froze the in-flight window or ran both and reconciled afterwards...