Any row written during the migration window must survive it. This is not a preference and it is not negotiable by this work — the data is the product.
What that rules out immediately: any approach involving a read-only window, an export/import, or a "quiet period" chosen because traffic is usually low. Traffic being usually low is a statement about the average, and the whole risk lives in the exception.
What it costs: the dual-write period is strictly more complex than a stop-the-world cutover would be, and it introduces a class of bug that does not otherwise exist — the two writes disagreeing. That is a real price, paid deliberately, and the mitigation is the comparison job rather than hoping.
The constraint also sets the rollback bar: rolling back must not lose writes either, which means the old schema stays populated until the new one has been verified, not until the deploy is green.