Checklists for a rewrite usually ask what the code does. The question that actually breaks rewrites is a different one: which of your identifiers already live in systems you don't control.
Payment references sit in bank statements. Order numbers sit in carrier labels, and in customer inboxes. Document IDs sit inside signed artifacts, where the signature covers the ID itself. Wallet addresses sit in other people's address books, and deposits keep arriving at them long after you stop issuing them.
None of that is in your repository. All of it is a contract.
A rewrite that reissues keys, changes their format or restarts a sequence is not a refactor. It is a silent break in attribution. Money arrives with a reference the new system cannot match. A settlement period stops reconciling. A signed document can no longer be tied to the deal it closed.
The second half of the same question is history. Behavior parity gets you today's requests. Reconciliation, disputes and compliance ask about last year's. If the new system cannot reproduce a past state (the amount as it was attributed then, the status as it stood at the moment of signing), you have replaced an auditable system with one that merely works.
So before you settle the stack, the timeline or the test coverage: list every identifier that has left your boundary, name who holds it, and decide explicitly whether the new system keeps it unchanged or carries a mapping forever. Mapping tables are boring, and they are probably what makes a cutover survivable.
I write more about this kind of trade-off here: https://polycratia.com/c/c19e8ded
Some of your identifiers you would only discover were load-bearing after the cutover...