Most rewrite checklists ask what your code does. The question that decides the cutover is which of its effects you cannot take back.
Inside your boundary everything is replayable. Re-run a job, re-import a table, diff two responses against the same request.
Outside it, nothing is. A capture on a card rail. A settlement instruction. A KYC check consumed at a provider. A carrier label bought. An on-chain transfer. A signed document. Each one becomes a fact in someone else's system the moment it leaves yours.
That asymmetry is what turns a clean rewrite into an incident. Running both systems in parallel is the safest cutover pattern there is, right up until both of them send. A webhook the old service already acknowledged is a webhook the new one does not see, and the payment sits unattributed. A notification goes out twice because the dedupe key lived in the code you replaced.
So map the boundary before you map the modules: every outbound call and every consumer-acknowledged event, which of them are idempotent on the provider's side and not just on yours, what the natural key is, and which ones have no reversal at all, only a compensating action that can fail on its own.
Then decide which system owns sending during the overlap. One of them. Not both.
Internal behavior you verify by diffing. External effects you verify only by not having duplicated them.
More on the payments and compliance side of this here: https://polycratia.com/c/b1a40859
If you have cut over a system with live money moving through it, you probably already know what owned the outbound side while both were running...