Running zero-tolerance financial checks and managing executive sign-offs — I didn't improvise any of this, because nothing here is worth gambling on.
De-risking trust before I needed it
I run both platforms in parallel and reconcile daily through every wave, not just in a final test window. By the time cutover arrives, the target has already matched the source for weeks — so the switch removes the old system instead of gambling on the new one.
I want trust earned before go-live, not asked for after. A big-bang cutover means the first real test happens in front of the business; dual-run means I've already seen weeks of clean reconciliation before anyone else even notices the switch happened.
I open an elevated-support window at go-live: a daily war-room I run myself, fast-track defect SLAs, and champions fielding questions inside each function. I set the exit criteria myself too — defect rate below threshold and adoption climbing — before I let hypercare close and support go back to normal.
Row counts alone don't prove a migration; matching business aggregates does. So reconciliation runs on three tiers — structural, then financial, then human sign-off — and all three have to pass before cutover.
The gate I wouldn't move on
I agree every go/no-go criterion before the meeting happens, so the decision is reading the evidence, not debating the bar. I keep one named decider — the executive sponsor — but the numbers have to pass before it ever reaches them.
Agreeing the bar after the evidence is in is how "close enough" quietly becomes the new standard under deadline pressure. Setting the criteria before the meeting is what lets me hold the line on one pending UAT sign-off instead of waving it through.
| Criterion | Threshold I set | Status |
|---|---|---|
| Financial reconciliation | Zero variance on all financial metrics | Pass |
| Open defects | No Sev-1 / Sev-2 open | Pass |
| Report parity | 100% of in-scope reports signed off | Pass |
| Rollback tested | Rehearsed in a non-prod dry run | Pass |
| UAT sign-off | All function SMEs signed | 1 pending |
| Support readiness | Hypercare team & runbook staffed | Pass |
Every step sequenced against a T-clock, with an owner and a checkpoint. The freeze protected data integrity; the reconciliation gate was my point of no return.
Cutover weekend is the worst possible time to improvise a decision. A minute-by-minute runbook with a pre-agreed rollback trigger meant nobody had to find me to ask permission when the reconciliation gate mattered most.
| T-clock | Step | Owner | Checkpoint |
|---|---|---|---|
| T-48h | Comms sent; freeze announced; support on standby | Change Lead | Acknowledged |
| T-2h | Source freeze — no writes to legacy EDW | Data Eng | Freeze confirmed |
| T-0 | Final incremental load; catch-up to freeze point | Data Eng | Load complete |
| T+1h | Final reconciliation — revenue to the penny | Testing / me | Go point |
| T+2h | Re-point reports & connections to Snowflake | BI Lead | Smoke test pass |
| T+3h | Open access to users; announce live | Me | Live |
| Any | Rollback trigger I set: reconciliation fails or Sev-1 found → revert to legacy, unfreeze, stand down | Me | Legacy restored |
Golden thread · go-live
At the T+1h gate, CLOSE_AMOUNT_USD reconciled to the penny against the frozen source — the same field that ran 6% high in test now matched exactly, because I'd already fixed the grain and definition upstream. That single green check is what let the sponsor say go.
What actually fought me
A clean reconciliation framework doesn't mean a clean run. Two problems cost real velocity before I got ahead of them.
Several critical reports depended on nested, recursive T-SQL stored procedures that didn't translate one-to-one into Snowflake SQL. It stalled sprint velocity for about two weeks.
Refactored the recursive logic into modular dbt / Snowflake views rather than force a literal translation — rebuilding the logic to be cloud-native instead of carrying the legacy pattern forward.
The reports came back with their numbers intact, on a model that was actually maintainable in Snowflake afterward.
During parallel testing, unoptimized BI extract queries collided at month-end and caused compute-warehouse contention in Snowflake — slow dashboards exactly when finance needed them.
Segregated workloads into dedicated virtual warehouses for ETL versus ad-hoc BI consumption, and tuned the auto-suspend and scaling policies so the two stopped competing for the same compute.
Extract performance recovered under peak load, and the separation kept ETL jobs and analyst queries from throttling each other going forward.
The judgment call
What I Decide Here
Decision: In week 2 of the 4-week dual-run, business reconciliation surfaces a trailing-12-month renewal discrepancy — traced to a UTC/timezone offset between the on-prem SQL Server sources and the cloud ingestion layer. I hold the cutover gate until it is root-caused and patched, not just flagged.
Friction: The fix sits on the critical path to a cutover planned ahead of quarter close. Raw staging was already inside our 0.003% automated anomaly threshold, so it would have been easy to call it “close enough” and move on.
Outcome: I isolate the root cause in the transformation layer, patch the timezone handling, and re-run the dual-run to exact parity on ARR and renewals before greenlight — keeping the planned cutover date without trading away the sign-off Finance and Sales Ops require.