# Managed Private Cloud for Healthcare Imaging: AWS Migration

> URL: https://www.atlantic.net/hipaa-compliant-hosting/healthcare-imaging-managed-private-cloud-migration/ | Published: 2026-10-30 | Author: Richard Bailey

A technology business reviewing a healthcare imaging platform approached Atlantic.Net recently about its Amazon Web Services (AWS) infrastructure. Their existing environment included Windows and Linux virtual machines (VMs), SQL Server, container workloads, block storage, and a substantial medical imaging archive.

The customer wanted to assess either a full migration or a compute-first move while retaining selected AWS services independently. We discussed our[HIPAA-compliant hosting](https://www.atlantic.net/hipaa-compliant-hosting)and managed private cloud capabilities, then requested a resource inventory before preparing a budget estimate.

Join us for the latest source deep-dive and real-world proposals, where we discuss how we help onboard new customers to the Atlantic.Net cloud platform.

## Keep The Resource Categories Separate

The customer-provided inventory listed persistent VM allocations and average container capacity separately. Before sizing the physical servers, the assessment needed to check whether these allocations overlapped and how demand would vary over time.

The allocated virtual CPUs (vCPUs) and memory were just a starting point. The final design had to account for actual usage, peak demand, how workloads are scheduled, and redundancy requirements.

| **Area** | **Customer’s Preliminary Inventory** | **What to Check** |
| --- | --- | --- |
| Persistent VMs | Approximately 13 VMs and 60 total vCPUs | Utilization, placement, and redundancy requirements |
| VM memory | Approximately 360 GiB | Per-VM working sets and reserve requirements |
| Local/block storage | Approximately 23 TB | Used capacity, I/O characteristics, and expected growth |
| Snapshots | Approximately 12 TB | Retention, purpose, and future protection design |
| Object storage | Approximately 920 TB across active and archive classes | Access patterns, API dependencies, and recovery scope |
| Container capacity | Average of approximately 49 vCPUs and 132 GiB | Peak demand, concurrency, overlap with the VM inventory, runtime dependencies, and target platform. |

The customer explained that these figures were estimates based on invoices, and its DevOps team was still checking the resource inventory. They provided a useful starting point for a budgetary assessment, but the final physical server design needed to reflect confirmed resource usage, capacity needs, and redundancy requirements.

Object storage also needs careful consideration, particularly given the volume of data involved. The required storage, how the data is accessed, and which storage interfaces the applications depend on will influence the proposed architecture and migration plan. Assess these requirements separately from VM compute requirements.

## Define The Hosting And Management Scope

Our discussions with the customer focused on a managed private cloud, with bare-metal hosting outside the proposed scope. Atlantic.Net’s[Managed Private Cloud](https://www.atlantic.net/dedicated-server-hosting/managed-private-cloud/) provides dedicated virtualization infrastructure, supported hypervisor options, and managed services.

We confirmed that Windows and SQL Server were supported and explained that our management responsibilities extend to the operating system level. We would need further discussion on the scope of support for applications, medical imaging software, container deployments, and specialist database administration. We would also need to review the customer’s existing SQL Server Web workloads, including their versions, editions, and licensing terms, to confirm their suitability for the proposed environment.

As the platform handles electronic protected health information (ePHI), we would also need to establish the scope of the[HIPAA Business Associate Agreement (BAA)](https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html) and clearly define each party’s security and compliance responsibilities.

## Assessing Object Storage Requirements

Our initial response confirmed that Atlantic.Net supported object storage. We had not yet provided the technical specifications, supported API operations, storage classes, or a design suitable for the scale of the customer’s archive.

To establish compatibility, we needed a better understanding of how the imaging platform accessed and managed its files. This included the existing archive classifications, retrieval patterns, access controls, and any dependencies on specific storage APIs.

Object storage was therefore an important part of the technical assessment. Before recommending a configuration, we needed to confirm that the proposed storage service could accommodate the archive’s capacity and access requirements and integrate with the imaging software.

## Assessing The Compute-First Migration

Our initial proposal focused on a managed private cloud rather than a hybrid AWS service. During subsequent discussions, the customer clarified that it intended to retain and manage certain AWS services independently, while Atlantic.Net would manage the new hosting environment.

This introduced additional migration considerations. We needed to establish which workloads would move, how they would communicate with services remaining in AWS, and where operational responsibilities would sit. We also had to consider connectivity, authentication, application dependencies, data transfers, and incident management.

Storage performance was particularly important for the imaging platform. If the application continued to access data in AWS, network latency and data transfer costs could affect both performance and the financial benefits of moving its compute workloads.

We therefore identified the need to test representative application workloads and storage access patterns before confirming whether the proposed arrangement would meet the customer’s requirements.

## Planning Backup And Disaster Recovery

The customer also requested local and off-site backups, geographic redundancy, disaster recovery, and uptime commitments. Our initial response covered backup and replication capabilities, although a detailed recovery architecture and workload-specific recovery objectives had not yet been agreed.

Our[Managed Veeam Service](https://www.atlantic.net/managed-services/veeam-services/) offered a potential approach to protecting supported server workloads. The imaging archive required separate consideration. Its size, storage architecture, rate of change, and recovery requirements would determine the most appropriate protection strategy.

For geographic redundancy, our[Disaster Recovery service](https://www.atlantic.net/disaster-recovery/) offered off-site backup and replication options. During the assessment, we distinguished between restoring data from backup, maintaining replicated copies, and recovering the application after an infrastructure failure. Each approach carried different requirements for recovery times, data availability, and operational management.

We also needed to review the applicable service-level agreement (SLA), including the services covered and any exclusions. The imaging platform’s recovery objectives, along with responsibilities for services remaining in AWS, required a separate agreement.

## Reviewing Migration Requirements And Costs

During the initial discussions, we explained that a detailed AWS migration assessment would require a conference call with our senior technical team. Our[Migration Services](https://www.atlantic.net/managed-services/migration-services/) provided a framework for evaluating the work involved, including workload dependencies, migration sequencing, and any specialist support required for the healthcare platform.

Reducing infrastructure expenditure was one of the customer’s primary objectives, as long as the migration did not introduce unnecessary operational risks.

To evaluate the financial benefits, we needed to consider more than the cost of replacing AWS compute resources. The assessment also had to account for software licensing, storage, backup and disaster recovery, network traffic, initial deployment, and migration services. Any AWS workloads the customer intended to retain needed to be included separately to establish the running costs.

A phased migration approach also warranted consideration. Testing representative application workloads, validating storage performance, and confirming backup and recovery procedures would help establish whether the proposed environment met the customer’s operational requirements.

At this stage, the anticipated savings remained estimates. A reliable comparison depended on validating the resource inventory, confirming the technical design, and understanding the full costs of each migration scenario.

The discussions helped establish requirements for a managed private cloud deployment and highlighted areas needing further technical review. The customer subsequently chose to proceed with Atlantic.Net after assessing its infrastructure requirements, existing AWS dependencies, and long-term hosting objectives.

If you are looking to migrate away from AWS, consider Atlantic.Net as your next hosting provider. We have over 32 years of experience providing modern solutions to the healthcare industry and beyond. [Contact the team to learn more.](https://www.atlantic.net/about-us/corporate-contact/)