In a staged cutover between two case-management products, why must the authoring freeze sit on exactly one side, and which side should carry it?

## What a dual run actually is A staged cutover keeps both products alive for a period. That is not indecision — it is the only way to avoid a big-bang switch where nobody can read last month's library because the load slipped. The rule that makes a dual run safe is simple and easy to state: > **Both sides readable. Exactly one side writable.** Everything else in a cutover plan is scheduling detail around that sentence. ## Why two writable sides fails It fails because nothing exists to repair the divergence: - **An export is a snapshot, not a sync.** Running the export again does not merge — it produces a fresh serialisation of the source, and re-importing it either duplicates cases or overwrites the target's edits wholesale. - **The two products share no identity for a definition.** The target minted its own identifiers on import; the source still has its own. There is no key both sides agree on to line two edits up against. - **Neither product offers a three-way merge.** These are not version-controlled text files with a common ancestor and a diff tool. A case edited in both places yields two prose descriptions and a human deciding which one is real. - **Divergence is silent and cumulative.** Nothing alerts anyone. It is discovered weeks later, by which point the number of divergent cases is unknown and every one needs a person to look at it. And why zero writable sides also fails: a freeze on both is just an outage. Authoring stops, the release the team is actually working on stalls, and the pressure to make an exception starts on day one — which is how a two-sided freeze quietly becomes a zero-sided one. ## Which side freezes, and what exactly is frozen The **source** freezes, at the moment its final delta export is taken. The target is where the team is going, so it must be the place new work lands. Freezing the target instead would mean the new product cannot be used and the whole cutover has no end. The freeze is on **authoring**, not on everything: | Activity | Source (old) | Target (new) | |---|---|---| | Reading definitions | Allowed for the agreed read-only window | Allowed | | Creating or editing definitions | Blocked at the freeze | The only place it happens | | Finishing a cycle already in flight | Allowed until it closes | Not started there | | Starting new work | Not allowed | Required | That middle row is the part people miss. A cycle that was half executed when the freeze landed should finish where it started; migrating a live cycle mid-flight loses partial results and confuses whoever is running it. New work begins in the target. ## Sequencing the cutover 1. **Bulk load early.** Move the whole library into the target well before the freeze, while the source is still fully writable. This is the rehearsal that finds the real problems: collapsed fields, missing attachments, flattened blocks. 2. **Fix in the target, not the plan.** Re-create constrained fields and shared blocks, correct the folder shape, verify by sampling — while there is still time to reload. 3. **Announce the freeze date, then hold it.** A date that slips twice is not a freeze; people stop believing it and keep authoring in the source. 4. **Take the final delta and freeze in the same operation.** Export what changed since the bulk load, import it, and remove authoring from the source in the same window. A gap between those two steps is exactly where lost edits live. 5. **Make the freeze technical.** Remove the ability to author in the source rather than asking people not to. A freeze enforced by goodwill is enforced by nobody, and the exceptions never come back to be reconciled. 6. **Set the read-only window's end date now.** The source stays readable for an agreed period and then goes; without a stated end it stays forever and the team runs two libraries indefinitely. ## Where cutovers actually go wrong - **The unofficial exception.** One team keeps authoring in the source because their release is mid-flight. Their work is invisible to the migration and is discovered after the source is retired. - **The gap between delta and freeze.** Edits made in the hours between the last export and the lock are the ones nobody knows to re-enter. - **No stated end.** With no retirement date the dual run becomes permanent, and now every question has two answers. - **Freezing execution instead of authoring.** Blocking a cycle already in flight creates pain for no benefit — it is definitions that diverge, not results already recorded against the old cycle. - **Announcing the freeze in a channel nobody reads.** The freeze needs to be visible where people work, and enforced where they would otherwise type. A cutover is judged by one question after the fact: can anyone name a case that was edited on the wrong side of the freeze? If the answer is a confident no, the freeze did its job.