Sales Snapshot
4+ wks
RTO at Engagement Start
Azure Canada East DR Landing Zone not built or tested — estimated 4–10 week recovery time for Azure Production in a regional outage
<3 hrs
Recommended RTO
Option 1 (recommended): Azure DR Landing Zone + IBM DB2 HADR + ASR → industry-standard RTO; RPO 15 min
2
Assessment Phases
Phase 1: Backup Assessment & Analysis · Phase 2: DR Strategy — both delivered by July 15, 2022
SOW
Executed
SOW No. 0000035803 · Effective April 28, 2022 · Onica Technologies Canada (Advisory) · Contractor: Eric Sippel (15+ yrs, named)
20%
Assets in Cloud at Start
~20% of estate migrated to Azure at time of engagement; active migration from Kamloops DC underway; goal: exit Kamloops by end of 2022
The Unique Angle — Why Provincial Government Agency Matters as a Reference
Provincial Government Agency is a B.C. provincial government agency — the workers' compensation board for British Columbia. They operate under a provincial legislative charter, answer to external auditors annually, and have a specific compliance obligation: their DR and backup posture must be documented, tested, and defensible to regulators, not just IT. When Advisory was engaged, the agency was mid-migration from two on-premises datacenters to Microsoft Azure — approximately 20% migrated — and had realized that the DR environment for their Azure Production workloads in Canada East had never been built. The estimated RTO in a regional outage was 4+ weeks, possibly 10 weeks. The production datacenter DR was well-tested; the cloud DR had been entirely overlooked.
The engagement spanned two phases: a Backup Assessment analyzing the current hybrid strategy (on-prem + Azure) against documented retention policies, RPO/RTO specifications, and compliance standards; and a DR Strategy assessment covering the full hybrid estate including IaaS, PaaS, SaaS (M365, Dynamics 365, SharePoint Online), and a unique IBM DB2 Windows environment that was failing replication and operating as a single node. We produced a DR Maturity Scorecard, a 3-option DR strategy with financial TCO, and an executed recommendation for Option 1: Azure Canada East DR Landing Zone build-out with IBM DB2 HADR replication and Azure Site Recovery for all non-DB2 IaaS assets.
Use this when selling to: Government agencies, crown corporations, regulated utilities, or any public sector organization migrating to Azure that needs a defensible DR posture for regulatory review. Also strong for any mid-migration organization that started moving workloads before their cloud DR architecture was validated — a common gap at the 20–40% migration stage.
Client Environment — What We Were Working With
Infrastructure & Migration State
- Two on-premises DCs: Mississauga (Primary Domain Controller, extended infrastructure) and Kamloops (primary production datacenter) — mandate given in 2021 to exit Kamloops by end of 2022
- ~20% migrated to Azure: Active migration in progress via Azure Migrate; Workload Transition Team ("Cloud Group") tasked with move — originally modernize-then-migrate path, pivoted to lift-and-shift after 2 years of delays
- CapEx → OpEx mandate: Management decision to transition capital-heavy DC costs to Azure operational model
- Azure regions: Canada Central (Primary Azure Region) + Canada East (DR target — not yet built)
- Kamloops DC DR: well-tested, mature SOP, hardware in place — robust legacy DR posture
- Azure Production DR: DR Landing Zone in Canada East not built; tabletop testing only; no tested failover SOP
Key Technical Complexity
- IBM DB2 on Windows: DB2 not successfully replicating — operating as a single node server; deeply integrated across all WorkSafe applications and data; high engineering effort required for any backup/DR testing; DB2 HADR licenses already purchased but not implemented
- DB2 deployment challenges: Migration of DB2 to Azure faced persistent disk I/O latency problems — a known constraint on the cloud migration critical path
- No application stack dependency mapping: "Try, see what happens, roll back with new knowledge" — no formal CMDB-backed dependency analysis; migration approach was ad hoc
- SaaS layer: M365 (Exchange Online, SharePoint Online), Dynamics 365 CRM — Microsoft Shared Responsibility Model gaps identified; cloud-to-cloud backup (3rd party) recommended for business data layer
- Compliance constraints: Annual external IT audit, Internal Audit & Risk requirements, provincial charter obligations — DR posture must be auditable
- Backup/DR never fully tested: Backup and DR procedures had never been "fully" verified end-to-end; 2016 policy change removed non-prod workloads from retention, requiring full rebuilds of Dev/Test from scratch on recovery
Three DR Options Evaluated
DR Maturity Scorecard — Assessment Dimensions
The DR Maturity Scorecard assessed Provincial Government Agency across both Backup and DR dimensions on a 0–4 scale per sub-dimension (total available score: 284). Each dimension was scored at baseline and a target improvement level identified. Key findings from the workshop sessions are captured in the scorecard notes.
Backup
Retention Policies & Procedures
Backup retention policies documented; 2016 management decision removed non-prod — forces full Dev/Test rebuild on recovery. Annual external audit confirms compliance.
Backup
Database Backup Strategy
DB2 not successfully replicating — single node. Backups executed on 24-hour snapshot basis only. High engineering effort for any DB2 restore. RPO: 24 hrs. Critical gap.
Backup
Testing & Business Alignment
Backup/DR procedures never "fully" tested end-to-end. Business doesn't have "realistic expectations" about DR capabilities. Budget driven by IT infrastructure needs, not business objectives.
Backup
Monitoring & Automation
Logs reviewed but backup failures not always alerted. Some automation present but not holistic. False positive alert fatigue causes important alerts to be missed.
DR
Testing Tiering
Kamloops DC: tabletop + production testing — mature, well-documented. Azure Production: tabletop testing only — DR Landing Zone never built; recovery time open-ended.
DR
Boot Order & Failover Automation
Kamloops has mature SOP with documented boot order and hardware pre-positioned. Azure Canada East has no landing zone — failover automation cannot exist without the landing zone foundation.
DR
CMDB Compliance
~50% CMDB accuracy; no firm policy to ensure currency. No application stack dependency mapping — migration approach is "try, see what happens, roll back." Impacts wave planning and DR sequencing.
DR
RTO Expectations & Business Alignment
Business expectations misaligned with actual DR capability. Maintenance windows for batch jobs overlap with backup windows — creates out-of-sync backup states and complicates recovery consistency.
SOW Scope — Two Milestone Phases
Phase 1
Backup Assessment & Analysis
- Evaluate current hybrid backup strategy (on-prem + Azure) against existing Provincial Government Agency recommendations and reports
- Identify gap findings — missing information, undocumented procedures, untested scenarios
- Review backup policies for all data classes: IaaS, PaaS, SaaS (M365, Dynamics 365, SharePoint Online), DB2, on-premises VMware
- Assess current backup tools: Avamar, ASR, SnapMirror, Zerto — identify overlap, gaps, and cost optimization opportunities
- Review retention policies, backup timing, security/encryption, monitoring, and automation maturity
- Short report with findings, adjustments, agreements, and recommendations — Deliverable: July 15, 2022
Phase 2
Disaster Recovery Strategy
- Confirm in-scope assets across on-prem and Azure; conduct workshops with WSBC DR subject matter experts
- Review current DR strategies: SRM, SnapMirror, Zerto, ASR; validate runbooks and DR test plans
- Evaluate DR classifications by RPO/RTO: Active/Active, Hot Standby, Pilot Light, Backup/Restore
- Develop high-level DR architecture options including network failover scenarios (on-prem ↔ Azure hybrid)
- Identify cost reduction opportunities: replace expensive tools, automate failover, rightsize DR target, modernize
- High-level design/architecture document, validation report against industry best practices, risk and impact analysis — Deliverables: July 15, 2022
Forward Opportunity — What Follows the Assessment
Landing Zone Build-Out
Azure Canada East DR
Option 1 was recommended but not implemented under the assessment SOW. The natural follow-on is a Phase 2 engineering SOW: detailed solution design, cost modeling refinement, high-level design for the Landing Zone, and hands-on build-out of the DR environment. IBM DB2 HADR configuration and ASR replication setup are the two critical workstreams.
DR Testing Program
Ongoing Validation
WSBC's DR had never been fully tested — a systemic gap. Post-build, a structured DR testing program is the next engagement: tiered test plan (tabletop → non-prod → pre-prod → full production failover), documented remediation process, and annual test cycle aligned to external audit requirements. This is a recurring revenue opportunity for a regulated government client.
Managed Operations
Post-Migration Azure Ops
Provincial Government Agency was at ~20% migrated when the engagement ran. As the Kamloops DC exit progresses, the Azure estate grows and operational complexity increases. Advisory Managed Azure — covering monitoring, backup management, DR automation maintenance, and incident management — is the steady-state managed services opportunity once migration is substantially complete.
Talk Track — Using Provincial Government Agency as a Reference
Government, Public Sector, and Mid-Migration DR Gap Conversations
"We're in the middle of migrating to Azure and we haven't figured out our DR strategy for the cloud yet. Our on-prem DR is fine."
We've seen this exact scenario. A B.C. provincial government agency — workers' compensation board, regulated under provincial legislation, annual external IT audit — was about 20% migrated to Azure when we engaged them. Their on-premises DR was well-tested and mature, with hardware pre-positioned and documented SOPs. Their Azure Production DR environment had never been built. Canada East was supposed to be the DR region. The landing zone had never been set up, and the estimated RTO in a regional outage was 4 to 10 weeks — open-ended because it had never been tested. The on-premises investment gave leadership false confidence that DR was "covered." Moving to cloud doesn't inherit your on-prem DR posture. We ran a two-phase assessment — Backup Analysis and DR Strategy — and produced a DR maturity scorecard, a 3-option analysis with TCO, and a recommended architecture: Azure Canada East Landing Zone with IBM DB2 HADR (which they'd already purchased but not implemented) and Azure Site Recovery for all IaaS assets. The recommended RTO dropped from 4+ weeks to under 3 hours.
"We have a legacy IBM DB2 environment that's causing problems in our cloud migration — no one seems to have experience with it."
DB2 on Windows was the single hardest problem in the Provincial Government Agency engagement. Their DB2 was not successfully replicating at all — it was operating as a single node, which meant their database RPO was 24 hours on a snapshot basis and any DR test required "heroics" from the engineering team. DB2 is deeply integrated across all their applications and data, so you can't sequence any migration wave without understanding the DB2 dependency first. The disk I/O latency in Azure was the key blocker — DB2 in cloud requires careful storage configuration that standard Azure documentation doesn't address well. The solution was IBM DB2 HADR (the High Availability Disaster Recovery replication feature), which WSBC had actually already licensed but hadn't implemented. We scoped the HADR implementation as the DR database workstream — near-real-time replication to Canada East, less than 3-hour RTO on the DB tier. If you have DB2 in your migration scope, it needs its own workstream and its own DR approach from day one.
"Our regulators and auditors are asking about our cloud DR posture and we don't have a good answer."
That's exactly the position Provincial Government Agency was in — an annual external IT audit, Internal Audit & Risk oversight, and provincial charter compliance requirements. The audit question isn't just "do you have DR?" It's "can you demonstrate a tested, documented DR capability with specific RPO/RTO commitments tied to your business criticality tiers?" WSBC couldn't answer that for their Azure environment. The backup assessment found that DR procedures had never been "fully" tested end-to-end, the business had unrealistic expectations about what the DR environment could recover, and maintenance batch jobs were running in the same windows as backups — creating out-of-sync backup states. We produced a DR Maturity Scorecard across 8 dimensions — retention policies, testing, DB strategy, monitoring, automation, CMDB, failover automation, and business alignment — with 0–4 scoring and specific action items for each. That scorecard becomes the documented roadmap for the next audit response: "here's where we were, here's the improvement plan, here's the timeline."
My Role on This Engagement
Named in Executed SOW
Cloud Solutions Architect — Eric Sippel, 15+ years experience · One of two named CSAs in SOW No. 0000035803 (alongside Robert McMahon; PM: Kaitlin Rogers)
DR Strategy Options
Developed the 3-option DR strategy comparison (Landing Zone Build, No Action, Legacy DC as DR) with RPO/RTO analysis, pros/cons, and financial TCO — including 35% DR cost formula
Backup Assessment
Phase 1 Backup Assessment — reviewed hybrid backup strategy, identified gaps in DB2 replication, retention policy coverage, SaaS backup gaps (M365, Dynamics 365), and monitoring/automation maturity
DR Maturity Scorecard
Built and scored the DR Maturity Scorecard (0–4 scale, 284 available points) across 8 backup and DR dimensions — workshop notes captured from June 3, 2022 sessions
Data Collection Observations
Produced "WorkSafe Data Collection — Observations and Recommendations" — structured findings from client interviews, documentation review, and SME workshops across DR and backup dimensions
Assessment Report
Co-authored "WSBC DR-Backups Assessment" (July 18, 2022) — executive summary, 3-option analysis with architecture diagrams, TCO table, recommended Option 1 with IBM DB2 HADR + ASR + Landing Zone
Context & Reference Notes
Client: Provincial Government Agency — Workers' Compensation Board of British Columbia. B.C. provincial government agency established under provincial legislation. Anonymized as "B.C. Provincial Government Agency" or "Government / Public Sector" in external references. Engagement: DR and Backup Strategy Assessment, April–July 2022. SOW No. 0000035803, executed April 28, 2022. Contractor: Onica Technologies Canada Inc. (Advisory). Governing agreement: IT Professional Services MSA #0000033595 (Sep 2018, originally with Trinimbus Technologies Inc., renamed Onica Technologies Canada Inc. Sep 26, 2018). Personnel: Cloud Solutions Architect Robert McMahon (15+ yrs), Cloud Solutions Architect Eric Sippel (15+ yrs — named), Project Manager Kaitlin Rogers (10+ yrs). SOW fee: Not extracted from available files (PDF format); time-and-materials engagement at minimum 10 hrs/week during SOW Term (April 28–July 15, 2022). Geography: Azure Canada Central (primary) + Azure Canada East (DR target). On-prem: Mississauga (domain controller) + Kamloops (primary DC, exit target). Use "B.C. Provincial Government Agency" in external references unless otherwise confirmed with account team.