Development Documentation
View as:

Go-Live Checklist

This page documents the complete procedure for switching business users from the legacy PySpark workspace to the new dbt-managed workspace. The core safety principle: the old production system is NEVER modified. Rollback means pointing users back to the old system — nothing more.

Pre-Cutover Validation Checklist

All items must be checked off before proceeding to cutover day.

Data Pipeline Validation

  • Parallel run comparison passed: scripts/compare_parallel_runs.py shows all tables match
  • Production dbt build pipeline (dbt-prod-schedule.yml) running successfully for at least 48 hours
  • No unresolved FAIL results in recent dbt builds (WARN=10 baseline is acceptable)

Workspace Readiness

  • New workspace created and populated: semantic models deployed, reports deployed
  • All semantic models in new workspace are in DirectLake mode (not Import fallback)
  • Column references validated: scripts/validate_semantic_deployment.py exits 0 (no orphans)
  • geris_fabric_admin@geris.nl is Admin on the new workspace
  • sp-fabric-data-worker has Contributor role on the new workspace

Consumer Discovery

  • Consumer discovery scan completed: python scripts/discover_gold_consumers.py
  • Migration gaps reviewed and resolved (or documented with justification)
  • Direct SQL endpoint consumers identified and notified
  • Power Apps and Power Automate connections checked

Stakeholder Sign-Off

  • Daan has reviewed and approved readiness
  • Pre-cutover announcement sent to business users (1 week before)
  • Cutover date confirmed with stakeholders

GO-LIVE BLOCKERS

These must be resolved before cutover. See the ADR Decision Log for full context on each.

BlockerStatusWhat Needs to Happen
Export UI auth not enabledAuth checks commented outCreate App Registration, enable Easy Auth, uncomment auth checks, set ALLOWED_GROUP_IDS
Email sender not configuredMI lacks Mail.SendCreate shared mailbox, grant scoped Mail.Send to MI, admin-consent, update sender config
CU monitoring blockedTrial capacityProvision paid F2+ capacity, add MI as Capacity Admin

Cutover Day Procedure

Execute these steps in order on cutover day.

Step 1: Final Pre-Flight Checks

# Final parallel run comparison
python scripts/compare_parallel_runs.py --config docs/parallel_run_config.yml

# Check for new consumers since last scan
python scripts/discover_gold_consumers.py --new-workspace-id <NEW_WORKSPACE_ID>

# Pre-flight validation
python scripts/validate_cutover.py \
    --workspace-id <NEW_WORKSPACE_ID> \
    --config deployment/prod-workspace-config.yml \
    --mode preflight

All three must pass before proceeding.

Step 2: Grant Business User Access

Grant Viewer access to business users on the new workspace via security groups:

  • Portal: Workspace Settings > Access > Add people > Viewer role
  • API: POST /v1/workspaces/\{id\}/roleAssignments with group object IDs

Use security groups (not individual users) for simpler management.

Step 3: Send Cutover Notification

Send the cutover day email to all business users with the new workspace URL and Workspace App link. Use the template in docs/cutover-communication-template.md.

Step 4: Update Bookmarks and Links

  • Update shared Power BI app links to point to new workspace reports
  • Update bookmarked dashboard URLs
  • Update Teams tabs and SharePoint embedded reports

Step 5: Run Full Validation

python scripts/validate_cutover.py \
    --workspace-id <NEW_WORKSPACE_ID> \
    --config deployment/prod-workspace-config.yml \
    --mode full

Step 6: Monitor (2 hours)

  • Monitor for user-reported issues
  • Spot-check reports in the new workspace (manual)
  • If issues arise: execute rollback (see below)
  • If clean after 2 hours: cutover is considered successful

Step 7: Confirm

  • Send post-cutover confirmation email
  • Old system continues running — do NOT decommission

Rollback Procedure

Rollback Triggers

Execute rollback if ANY of these are true:

  • Multiple reports showing incorrect or stale data
  • Semantic models stuck in Error or Import fallback mode
  • Gold tables not refreshing on schedule
  • More than 3 user issues that cannot be resolved within 30 minutes
  • Daan decides to rollback for any reason

Rollback Steps (achievable within 1 hour)

  1. Communicate: Send rollback email — "Reverting to previous system, please use old workspace links"
  2. Revoke access: Remove Viewer access from new workspace (prevents confusion)
  3. Verify old system: Open 3-5 reports in old workspace, confirm data is fresh
  4. Verify old pipeline: Check the Gate pipeline schedule is still running
  5. Confirm: Send "Rollback complete" email

Why Rollback is Simple

The old system was never modified (side-by-side deployment). Old notebooks, pipelines, semantic models, and reports continue running unchanged. Users switch back to old workspace URLs. No data migration, schema changes, or code rollback needed.

Post-Cutover Monitoring (2 Weeks)

  • Old notebook pipeline continues running (no automatic teardown)
  • New dbt pipeline runs on schedule
  • Daily: compare row counts between old and new Gold tables
  • Weekly: full parallel run comparison (scripts/compare_parallel_runs.py)
  • Monitor user-reported issues
  • After 2 weeks with no issues: Daan decides whether to decommission old system

Decommissioning (Future)

Decommissioning is a MANUAL decision by Daan only, minimum 2 weeks post-cutover with no issues.

Steps when approved:

  1. Disable old orchestration pipeline schedule
  2. Remove business user access from old workspaces
  3. Archive (do NOT delete) old notebooks and pipeline definitions
  4. Keep Lakehouse_Gold and Lakehouse_Bronze intact — Bronze is immutable
  5. Document decommission date and reason

Old Bronze data (Lakehouse_Bronze) must NEVER be deleted — it is the immutable source of truth.

Related Pages