Cloud readiness and managed-services strategy for a regional healthcare system

The situation

A regional U.S. healthcare system, multi-state with multiple facilities, was looking at end-of-life infrastructure and a small internal IT team that could not realistically operate a full datacenter alongside the move to a cloud-managed services model. The strategic intent was clear: shrink on-premises footprint, move appropriate workloads to a managed cloud platform, and rebuild disaster recovery as a tested capability rather than a binder of procedures.

But this is healthcare. Every workload assessment had a HIPAA dimension. EHR integration, patient-data flows, audit trails, and PHI segregation requirements meant a generic cloud-readiness checklist was not going to be sufficient. The technical leadership wanted the assessment grounded in their actual operational state, not aspirational best-practice from a slideware deck.

What we did

1. Cloud Readiness Assessment grounded in operational reality. Interviews with technical leadership and delivery teams. Mapped the current state of the IT environment against software-defined-infrastructure (SDI) and managed-services best practices. Identified the gap between current operations and a cloud-managed target state, scored across capability dimensions.
2. Application discovery and dependency mapping. Application Dependency and Rationalization Assessment SOW: cataloged production applications with dependencies, integration points, and data sensitivity. For regulated workloads, captured the audit and PHI-flow implications of any move to cloud.
3. Journey-to-Cloud detailed report. Per-application cloud target state, including which workloads should stay on-prem (and why), which should move with re-platforming, and which were candidates for SaaS replacement. Sized infrastructure, network, and identity changes required for each tier.
4. Disaster recovery target-state with ASR-based failover. Designed Azure Site Recovery protection groups with mapped on-premises networks to Azure VNets, configured recovery plans with detailed automation, and documented test- and full-failover playbooks. DR moved from a paper plan to a tested, repeatable capability.

Outcomes

• Cloud-readiness baseline produced with prioritized gap-closure list
• Application portfolio cataloged with dependency map and PHI-handling annotations
• Per-application cloud target state, explicit "stay / migrate / replace" decisions with rationale
• Disaster-recovery design with tested Azure Site Recovery failover plans, not just documentation
• Operating-model recommendations for the in-house IT team alongside a managed-services partner

What was hard

The deliverable that took the most effort was not the cloud-readiness scoring. It was the per-application "stay vs migrate vs replace" decision, because each one depended on understanding the workload's integration with the EHR and the PHI flows around it. We had to slow down repeatedly to make sure we were not optimizing for cloud-native elegance at the expense of audit traceability.

The DR work was also harder than expected. Documenting an ASR design is one thing; getting the test failover to actually run cleanly across the VNet mappings and on-prem network configuration was where most of the engineering time went. Every healthcare system has accidental dependencies that only surface during a real test, and ours did too.

Selected artifacts

• Cloud-readiness diagnostic for regulated workloads. SDI-aligned assessment with HIPAA dimensions
• Application Dependency & Rationalization Assessment. Dependency mapping and PHI-flow annotations
• Journey-to-Cloud detailed report template. Per-application stay / migrate / replace decision framework
• ASR DR runbook. Test-failover and full-failover playbooks with automation hooks

Public-cleansed templates and frameworks drawn from engagements like this one are in our resources library.