Dashboard Migration Plan

Migration plan for the Cirius Group internal dashboard from the existing legacy VM in US Central to a new hub-spoke-architected VM in US West, with Cloudflare-fronted WAF and CDN. This document satisfies DECOMM-009.

Current State

• Host: DashboardVM20 in resource group rg-actdirap04 (or sibling RG; exact RG recorded in the VM inventory).
• Region: Azure US Central (single region, no paired DR).
• Network: flat VNet shared with legacy AD infrastructure; no hub-spoke segmentation; public inbound via VM NIC public IP protected by NSG only.
• Deployment: hand-built VM from a legacy Windows Server image; configuration drift relative to current baseline.
• TLS / Edge: direct inbound over HTTPS with a certificate renewed manually; no WAF; no CDN; no DDoS protection beyond Azure default.
• DNS: dashboard.ciriusgroup.com A record pointed at the VM public IP; registrar and authoritative DNS at U2 Web.
• Backup: Azure Backup on the VM; no tested application-level restore runbook for dashboard data.
• Identity: domain-joined to legacy on-prem AD through the actdirap04 domain controller path.
• Known issues: monolithic (app + web + data on one VM), region-locked, manual TLS, no WAF, no structured IaC, no CI/CD.

Target State

• Host: new Windows VM provisioned via the windows-server Terraform module into a hub-spoke VNet topology in Azure US West.
• Region: Azure US West (new primary). Disaster recovery region consideration left for a follow-up story; scope here is primary migration only.
• Network: dashboard VM sits in a workload spoke VNet; ingress via hub firewall; no public IP on the VM; outbound through hub for egress filtering.
• Deployment: Terraform-managed (module modules/windows-server), state versioned, pipeline-deployed.
• Edge: Cloudflare fronting the dashboard — WAF rules active, CDN for static assets, TLS terminated at Cloudflare edge with re-encryption to origin.
• DNS: dashboard.ciriusgroup.com managed via Cloudflare (nameservers delegated at U2 Web — see runbooks/cloudflare-terraform-integration.md). Origin hostname routed via Cloudflare tunnel or restricted origin IP allowlist.
• Backup: Azure Backup on the VM plus application-aware snapshot of the dashboard data store; documented restore drill.
• Identity: domain-joined to the managed AD path; service identity via gMSA where applicable.
• Observability: logs flowing to Sentinel; availability monitoring integrated with Arctic Wolf.

Dependencies

Migration cannot begin until the following are in place:

• DECOMM-010 — Cloudflare Terraform integration complete (free tier zone created, Terraform provider onboarded, delegation validated). See runbooks/cloudflare-terraform-integration.md.
• Hub-spoke network for US West available or provisioned as part of this effort.
• windows-server Terraform module version that supports the required OS baseline and domain-join workflow.
• DNS change window coordinated with stakeholders (internal users are the primary consumers).
• TLS certificate available via Cloudflare (Universal SSL is sufficient for the fronting path) and origin certificate minted for edge-to-origin encryption.
• Firewall rules on the hub-spoke firewall to permit origin traffic from Cloudflare IP ranges (or a Cloudflare tunnel endpoint).
• Application owner sign-off on the target configuration and the cutover window.

Migration Sequence

Executed as a sequence of named stages. Each stage has an exit criterion before the next stage begins.

Stage 1 — Provision

1. Create the new Windows VM via the windows-server Terraform module in the US West workload spoke.
2. Join the VM to the managed AD path.
3. Install prerequisites and the dashboard runtime baseline.
4. Verify that the VM is reachable only through the hub firewall — no public IP.
5. Provision the Cloudflare zone (or confirm DECOMM-010 has done so) and create an unrouted DNS record for the new origin.

Exit criterion: new VM healthy, domain-joined, no public IP, inventory records updated.

Stage 2 — Data migration

1. Snapshot the dashboard data on the source VM at a known-good point.
2. Copy application data and configuration to the new VM using the approved transfer method (AzCopy, offline media, or VM replication depending on data size).
3. Run the dashboard application against the migrated data on the new VM in a hidden / not-routed state.
4. Functional parity check: feature-by-feature walkthrough by the application owner; compare reports and row counts against source.
5. Run a second incremental sync close to the cutover window to minimize delta.

Exit criterion: dashboard on the new VM passes full parity check; delta window understood; rollback snapshot captured.

Stage 3 — DNS cutover

1. Final data sync (delta) during the change window.
2. Reduce TTL on dashboard.ciriusgroup.com to 60 seconds at least 24 hours in advance.
3. Update the Cloudflare record for dashboard.ciriusgroup.com to point at the new US West origin (proxied through Cloudflare).
4. Validate WAF rules are active and not blocking legitimate traffic (initial mode: permissive with logging, step up to blocking after observation).
5. Smoke test from multiple user networks and from an external vantage point.
6. Raise TTL back to steady-state (typically 5 minutes) once stable.

Exit criterion: traffic observed landing on new VM via Cloudflare; source VM traffic zero for the in-scope hostname over a sustained window.

Stage 4 — Decommission source

1. Hold the old VM online for a one-week observation period after cutover.
2. Revoke the source VM's public IP / any legacy DNS pointing to it.
3. After the observation period and application-owner sign-off, shut down the old VM.
4. Delete the VM, its managed disks, and associated NICs after a 30-day cold retention window on the snapshot.
5. Remove the legacy DNS record and any firewall exceptions referencing the old address.
6. Update IaC and inventory to reflect decommission.

Exit criterion: source VM removed, inventory and DNS clean, evidence attached to DECOMM-009.

Rollback Plan

Each stage has an explicit rollback.

Stage	Rollback Trigger	Rollback Action
1 Provision	New VM fails validation	Destroy new VM via Terraform; retain source untouched. No user impact.
2 Data migration	Parity check fails	Keep source as active; defer cutover; restore from rollback snapshot on the new VM; retune and retry.
3 DNS cutover	WAF blocks legitimate users or dashboard errors on new VM	Revert Cloudflare origin to source VM IP (TTL already short). Post-mortem required before re-attempting cutover. Source VM remains active throughout Stage 3, so rollback is a DNS flip.
4 Decommission	Issues discovered during observation window	Re-enable source and flip DNS back as in Stage 3 rollback. Defer decommission until issues resolved.

A full rollback is always possible while the source VM is still online. The decommission (Stage 4) is the point of no return, and is gated by the one-week observation period and application-owner sign-off.

Related Documents

• runbooks/cloudflare-terraform-integration.md — Cloudflare Terraform integration (DECOMM-010)
• runbooks/backup-architecture.md — backup and restore architecture
• runbooks/incident-response.md — incident response runbook
• compliance/tagging-standard.md — resource tagging standard applied to the new VM