1. Executive Summary

Zivankh is a mid-to-large healthcare services organization providing electronic health record (EHR) management, telemedicine infrastructure, patient data analytics, and medical imaging services across multiple hospital networks and outpatient clinics. Prior to this engagement, Zivankh operated fragmented, aging on-premises server infrastructure spread across three co-located data centres — a legacy environment that was generating escalating costs, compliance risk, and innovation bottlenecks.

As the designated AWS Migration Acceleration Program (MAP) partner, our firm conducted a structured migration engagement — spanning discovery, architecture design, migration execution, and modernization — to move Zivankh's entire workload portfolio to Amazon Web Services. The project was completed within a 52-week program timeline, resulting in a 42% reduction in total IT infrastructure costs, elimination of all 23 open HIPAA compliance findings, and a disaster recovery posture that reduced Recovery Time Objective (RTO) from 18–24 hours to under 30 seconds.

2. Company Profile

Zivankh is a privately held healthcare services organization operating across 12 facilities. The organization delivers a broad spectrum of digital health services to over 500,000 active patients and employs approximately 2,400 clinical and administrative staff.

2.1 Application Workload Portfolio

The following core application workloads were in scope for migration:

•       Electronic Health Record (EHR) Core Platform — clinical workflows, patient records, prescriptions

•       PACS / Medical Imaging System (DICOM) — radiology image storage and retrieval

•       Telemedicine Platform — real-time video consultations and asynchronous messaging

•       Claims Processing System (legacy IBM AS/400)

•       Patient Self-Service Portal — appointment booking, results viewing, messaging

•       Analytics & Business Intelligence (BI) Reporting — population health and operational dashboards

•       Machine Learning (ML) Clinical Decision Support

•       HIPAA Audit Logging & Compliance Reporting

•       Identity & Access Management (IAM) — SSO for clinical staff

•       HL7 v2 Integration Engine — 120+ interfaces to payers, labs, and pharmacies

3. Pain Point Discovery & Assessment

Our team conducted a structured 6-week discovery engagement using AWS Application Discovery Service (ADS), AWS Migration Evaluator, and in-depth stakeholder interviews across IT leadership, clinical operations, compliance, and finance teams. Seven critical pain points were identified and formally documented

Assessment Methodology

Tools used: AWS Application Discovery Service (ADS) for server dependency mapping, AWS Migration Evaluator for TCO analysis, structured stakeholder interview workshops, HIPAA compliance audit review, and manual infrastructure inventory across all 3 data centres.

3.1 Identified Pain Points

PP-01  Fragmented On-Premises Infrastructure Without Unified Governance

Zivankh's workloads were distributed across VMware vSphere on-premises infrastructure in three aging co-located data centres with no unified management plane. IT teams spent over 40% of their working capacity managing infrastructure inconsistencies, patching cycles, and hardware failures rather than delivering value. Hardware end-of-life events were creating unplanned capital expenditure requests annually.

P-02    Critical HIPAA Compliance Gaps & Security Vulnerabilities

An independent compliance audit identified 23 unresolved HIPAA findings, including unencrypted Protected Health Information (PHI) at rest in legacy databases, inadequate role-based access controls, incomplete audit trail coverage, and network segmentation failures. The fragmented infrastructure made maintaining valid Business Associate Agreements (BAAs) with third-party integrated systems operationally complex and legally exposed the organization to significant regulatory risk.

PP-03  High Fixed Infrastructure Costs with Zero Elasticity

On-premises compute was provisioned to handle peak demand periods (annual wellness campaigns, flu season surges), leaving 60-70% of compute capacity idle during normal operations. Annual hardware refresh cycles, software licensing (VMware, Oracle Database, Windows Server CALs), and data center colocation costs totaled $8.2M/year with no mechanism to scale capacity up or down in response to demand. The organization was paying for maximum capacity 12 months per year.

PP-04  Inadequate Disaster Recovery & Business Continuity Posture

The organization's documented Recovery Time Objective (RTO) was 18-24 hours and Recovery Point Objective (RPO) was 4-8 hours — entirely unacceptable for a clinical environment where a system outage forces staff to revert to paper-based workflows with direct patient safety implications. Of the last three annual disaster recovery drills, two failed to complete within the target window. The organization had no tested failover path for its primary EHR database.

PP-05  Slow Application Deployment Cycles Impeding Clinical Innovation

New feature deployments required a 6–8-week cycle involving manual server provisioning requests, change advisory board (CAB) review meetings, environment preparation, and coordinated testing across shared infrastructure. No CI/CD (Continuous Integration / Continuous Deployment) pipeline existed. DevOps maturity was assessed at Level 1 (ad-hoc). Competitor healthcare organizations were delivering new telemedicine capabilities in weeks; Zivankh required 4-6 months for comparable features.

PP-06  Limited Analytics Capability and No Machine Learning Infrastructure

Patient outcome analytics and population health reporting ran nightly batch jobs on a single on-premises SQL Server instance, producing reports 24-48 hours stale. Clinical leadership could not access real-time operational data. The data science team had no self-service compute infrastructure — each ML model training experiment required a formal infrastructure request and a 2-3 week provisioning wait. No production ML inference capability existed.

PP-07  Legacy Integration Engine Creating Interoperability Bottlenecks

Integration with insurance payers, laboratory systems, pharmacy networks, and government reporting portals was managed through a custom Enterprise Service Bus (ESB) built in 2009 — a single point of failure managing 120+ HL7 v2 message interfaces. Adding a new payer integration required 3-5 months of custom development. The system had no support for modern FHIR R4 APIs mandated by the CMS Interoperability and Patient Access rule, putting the organization at regulatory compliance risk for federal reporting requirements.

4. Solution Design & AWS Services Selected

The solution architecture was designed using the AWS 7Rs Migration Strategy framework (Rehost, Replatform, Refactor, Repurchase, Retire, Retain, Relocate) to determine the optimal migration path for each workload. Each AWS service was selected based on its ability to directly address one or more of the identified pain points, its HIPAA eligibility under the AWS Business Associate Agreement, and its long-term operational fit for a healthcare organization.

5. Why AWS? Decision Rationale & Alternative Evaluation

Prior to committing to AWS as the target platform, the partner team and Zivankh's IT leadership conducted a structured evaluation of all viable alternatives. The evaluation criteria were weighted across compliance coverage, purpose-built healthcare services, disaster recovery capability, total cost of ownership, and partner ecosystem maturity.

5.1 Alternatives Evaluated

Alternative 1 — Expand Existing On-Premises Infrastructure (VMware Refresh)

A hardware refresh of the VMware vSphere environment was quoted at $4.1M CapEx with a 5-year hardware lock-in. This option was rejected because it would deliver no improvement in agility, disaster recovery, or compliance automation. The TCO analysis showed that a continued on-premises strategy would cost 2.3 times more over a 5-year horizon than the AWS alternative. Critically, a hardware refresh cannot address the HIPAA compliance gaps, the FHIR interoperability mandate, or the deployment velocity issues — which are architectural, not hardware, problems.

Alternative 2 — Retain On-Premises + Add a Cloud Overlay

A hybrid architecture retaining on-premises infrastructure while adding cloud burst capacity was evaluated. This was rejected because it would perpetuate the existing fragmentation, require maintaining two separate governance frameworks, and add complexity rather than reducing it. The primary goal of the engagement was consolidation — a hybrid overlay would undermine that objective and increase, not decrease, operational overhead for the IT team.

Alternative 3 — Replace On-Premises with Managed Hosting / Colocation Upgrade

Upgrading from self-managed co-location to a managed hosting provider was considered. This option was rejected because managed hosting cannot deliver the elastic scaling, DevOps toolchain integration, or purpose-built healthcare services (HealthLake, HealthImaging, SageMaker HIPAA-eligible endpoints) that were core requirements. Managed hosting also provides no native path to FHIR R4 compliance or advanced analytics.

5.2 Why AWS Was Selected Over All Alternatives

AWS was selected as the target platform based on a combination of factors that no alternative could match in aggregate:

6. Target AWS Architecture

The target architecture is a multi-region, defense-in-depth, HIPAA-compliant AWS cloud environment. All workloads are deployed within a multi-layer VPC architecture with strict subnet segmentation, and the entire infrastructure is managed as code using AWS CDK. The architecture follows the AWS Well-Architected Framework across all five pillars: Operational Excellence, Security, Reliability, Performance Efficiency, and Cost Optimization.

6.1 Architecture Overview

The architecture spans two AWS regions for active DR capability:

•       Primary Region: us-east-1 (US East — N. Virginia) — all production workloads

•       DR Region: us-west-2 (US West — Oregon) — warm standby for all critical systems

6.2 Network Architecture

All workloads are deployed within a multi-layer Amazon VPC using the following subnet segmentation model:

6.3 Data Flow Architecture

The clinical data flow through the architecture follows a strict, audited path from ingestion to storage to analytics:

•       Clinical Staff & Patient requests enter via CloudFront → WAF → Application Load Balancer → EKS microservices

•       PHI data written by EKS services is persisted to Aurora (transactional) and HealthLake (FHIR R4 canonical store)

•       Medical imaging (DICOM) is ingested directly to AWS HealthImaging with metadata indexed in S3

•       AWS Glue ETL pipelines replicate de-identified analytics data from Aurora to Redshift for reporting

•       SageMaker accesses Redshift and S3 training datasets via VPC endpoints — no PHI leaves the private data subnet

•       All API integrations with external payers, labs, and pharmacies route through API Gateway → EventBridge → HealthLake FHIR APIs

•       All data replication to the DR region (us-west-2) is encrypted in transit using TLS 1.2+ and at rest using AWS KMS Customer Managed Keys (CMKs)

6.4 Disaster Recovery Architecture

The DR architecture uses an active-warm standby model with the following components deployed in us-west-2:

7. Migration Methodology & Project Timeline

The migration followed the AWS MAP three-phase methodology. Each phase had defined entry and exit criteria, go/no-go checkpoints, and formal deliverable sign-offs between the partner team, Zivankh's IT leadership, and the AWS Migration Success Manager.

7.1 Workload Migration Strategy (7Rs)

7.2 Phase-by-Phase Timeline

Phase 1: MAP Assess (Weeks 1–6)

Deploy AWS Application Discovery Service (ADS) agents across all servers and databases. Run AWS Migration Evaluator to build a detailed TCO analysis. Conduct HIPAA gap assessment. Map all application dependencies using ADS Service Map. Produce the Migration Readiness Assessment (MRA) report. Identify 7R disposition for each of the 80+ application components in scope. Obtain stakeholder sign-off on migration business case and target architecture.

Phase 2: MAP Mobilize (Weeks 7–18)

Deploy AWS Control Tower to establish the multi-account landing zone with HIPAA-compliant guardrails via Service Control Policies (SCPs). Configure AWS Organizations, AWS Config rules baseline, and CloudTrail. Establish VPC topology, Transit Gateway, and AWS Direct Connect circuits to all 12 facilities. Stand up Security Hub, GuardDuty, and Macie. Execute Wave 1 pilot migration: Patient Portal and File Servers. Conduct first DR drill. Train Zivankh IT team on AWS operations tooling.

Phase 3A: Migrate & Modernize — Core (Weeks 19–36)

Execute Wave 2: Rehost EHR VMs to EC2, then replatform to EKS containers using AWS Application Migration Service (MGN). Migrate Oracle Database to Aurora PostgreSQL using AWS Database Migration Service (DMS). Deploy HealthLake and begin FHIR R4 data ingestion. Deploy Aurora Global Database DR replica. Establish CI/CD pipelines in CodePipeline for all EHR microservices. Decommission on-premises data centers 1 and 2.

Phase 3B: Migrate & Modernize — Advanced (Weeks 37–52)

Execute Wave 3: Migrate PACS/DICOM imaging to AWS HealthImaging. Stand up Redshift data warehouse and migrate historical analytics. Deploy SageMaker ML pipelines and migrate data science workloads. Replace legacy ESB with EventBridge and HealthLake FHIR APIs. Repurchase IBM AS/400 claims system with AWS Marketplace SaaS. Decommission final data center. Execute comprehensive Well-Architected Review with AWS Solutions Architect. Final compliance audit and HIPAA attestation.

8. Measured Benefits & Business Outcomes

The following results were measured 12 months after the final cutover to AWS. Metrics were captured using AWS Cost Explorer, Amazon CloudWatch, AWS Security Hub, and Zivankh's internal IT operations reporting systems.

8.1 Key Performance Metrics

8.2 Detailed Before & After Comparison

9. Compliance & Regulatory Coverage

All AWS services deployed within Zivankh's environment are HIPAA-eligible and covered under the AWS Business Associate Agreement (BAA). The following regulatory frameworks are satisfied by the target architecture: