Choose the parallel-run form deliberately
"We'll run in parallel" means three different things, with very different costs. Pick by what you need to prove:
| Form | What it proves | What it costs |
|---|---|---|
| Read-parallel | The new platform computes the same answers from the same events — balances, bets, bonus state | An event feed and a comparison harness; no player risk at all |
| Staged-parallel | The new platform operates real players correctly, on the least risky brand or market first | Two of everything for the overlap: support flows, reconciliations, reporting |
| Live-live shared wallet | In theory, zero-downtime migration | In practice, a distributed-consistency problem across two vendors' systems; almost never worth it |
Read-parallel is underused because it feels indirect, yet it is the cheapest way to burn down the largest risk — computational disagreement between platforms — weeks before any player is exposed. Staged-parallel then covers the operational risk on a slice. The combination is stronger than either alone, and both are covered by rehearsals whose durations you have measured, which is what makes the freeze window a fact rather than an aspiration.
The go/no-go: criteria before the meeting
The go/no-go fails as a ritual when the criteria are being invented in the meeting. Write them when everyone is calm, keep them to one page, and make each one binary:
- Reconciliation: the balance report at zero unexplained difference on the final rehearsal.
- Protections: exclusions, limits and flags verified on the target, independently of the main data run.
- Risk checklist: every item in the checklist at proven status — not "in progress", not "should be fine".
- Window: final rehearsals completed inside the committed freeze window, consecutively, not once.
- Rollback: executed in rehearsal within its stated duration, with the point of no return defined.
- People: named approvers present, support briefed, communication drafts staged for every branch — success, overrun, rollback.
One person chairs with the explicit authority to say no. If the date is politically unmovable regardless of the criteria, you do not have a go/no-go — you have a countdown, and the criteria are set dressing.
The window, hour by hour
The plan for the night is a timeline, not a task list — each entry with an owner, an expected duration from rehearsal, and the decision that follows if it overruns:
| Stage | What happens | The overrun decision |
|---|---|---|
| Freeze entry | Maintenance page up, sessions drained, in-flight transactions resolved per the agreed policy | Late entry compresses everything after it — the chair decides whether the full window still fits |
| Final delta | Data changed since the last snapshot migrated; identity map deltas applied through the controlled process | A delta larger than rehearsed is a signal, not a nuisance — investigate before proceeding |
| Reconciliation | The full balance and state comparison, at account level | Any unexplained difference stops the line; this is the criterion that is never waived at 3am |
| Smoke on the target | Real login, deposit, bet, withdrawal per market; protections re-checked as the final gate | A failed smoke is a rollback conversation, not a debugging session inside the window |
| Traffic switch | DNS or routing moved, redirects live, partners' endpoints confirmed | Partial switches need a defined state — half-moved traffic is its own incident |
| Point of no return | First real transactions accepted on the new platform | Declared out loud and logged; the rollback plan changes shape past this line |
Rollback, honestly
Before the point of no return, rollback is mechanical: revert routing, lift the freeze, schedule a new attempt — embarrassing, cheap, and rehearsable. After it, rollback means migrating newly created transactions backwards into a platform you were leaving, which is a second migration performed under pressure without rehearsal. That asymmetry is why the point of no return is placed as late as the design allows, stated in the plan, and treated as the real decision of the night. Most "failed cutovers" that turn into extended incidents are cases where the team debugged forward past that point because nobody had named it.
Stabilisation: the week that is part of the migration
- Baseline watch. Approval rate, login success, bet settlement, support volume and event counts against pre-migration baselines — reviewed daily, by name, not by dashboard existence.
- Change freeze continues. The migration is not done at traffic switch; unrelated deploys wait until the baselines hold.
- Defect triage separates migration from noise. A dedicated tag and a daily review, so the long tail of small defects gets burned down instead of dissolving into the normal queue.
- The evidence pack closes. Snapshots, reconciliation reports, the decision log, the timeline as it actually ran — archived while memory is fresh, because that record is what the first regulator question and the first dispute will be answered from.
Continue reading: The migration guide — the full sequence this night concludes. Enterprise operator solution — how Turbo Stars runs replatforms with the freeze window as a design constraint.