Cloud Migration Checklist for Healthcare Practices in Central Florida

Why Central Florida Healthcare Practices Are Moving to the Cloud

The short answer is that the ground is shifting under their feet. But the longer answer is more interesting, because it is not just one thing pushing practices toward the cloud — it is several things happening at the same time.

First, there is the compliance pressure. The 2026 HIPAA Security Rule changes make encryption, MFA, and 72-hour disaster recovery mandatory for every covered entity. If your data lives on local servers, meeting those requirements means buying hardware, configuring software, maintaining it, testing it, documenting it, and paying someone to watch it. If your data lives in the cloud with a HIPAA-compliant provider, most of those controls come baked in. You still have to configure and verify them — this is not a "set it and forget it" situation — but you are starting from a much better foundation.

Second, there is the disaster recovery problem, and in Central Florida this is not abstract. Hurricane season runs June through November. Every year. If your practice is in Daytona Beach or New Smyrna Beach or anywhere along the coast, you know exactly what I am talking about. A local server sitting in your office is one storm surge, one power grid failure, one roof leak away from taking your entire patient records system offline. The cloud does not care about hurricanes. Your data is replicated across multiple geographic regions. The building can flood and your patients' records are still accessible from wherever you set up temporary operations.

Third, there is the operational reality. Small practices in Volusia County — and I mean practices with five to twenty employees — do not have dedicated IT departments. They have someone on staff who "knows about computers" and an MSP they call when something breaks. Managing on-premise servers, applying security patches, running backups, monitoring for intrusions, maintaining HIPAA audit logs — that is a full-time job. It is not a side task you hand to your office manager between scheduling appointments and processing insurance claims.

The cloud does not eliminate the need for IT expertise. But it shifts the burden. Instead of managing hardware, patching operating systems, and replacing failing drives at 2 AM, you are managing configurations, access policies, and vendor relationships. That is a fundamentally different — and more manageable — workload for a small practice.

And fourth, there is telehealth. The expansion of virtual care that accelerated during COVID has not reversed. Practices across Central Florida are seeing patients remotely, sharing records electronically, and integrating with systems that expect cloud-based connectivity. If your infrastructure is entirely on-premise, every telehealth integration becomes a custom bridge project. In the cloud, it is just another API connection.

The 2026 HIPAA Requirements That Make Cloud Migration Urgent

I covered the full scope of 2026 HIPAA changes in our compliance checklist, but here is what specifically matters for cloud migration.

The elimination of the "addressable" vs. "required" distinction is the big one. Under the old rules, encryption was technically "addressable" — meaning you could document a reason for not implementing it and substitute an alternative. Many small practices interpreted this as optional. Under the 2026 rule, that ambiguity is gone.

What is now mandatory:

• AES-256 encryption at rest for all electronic protected health information (ePHI). Every database, every file system, every backup. If it stores patient data and it is not encrypted, you are out of compliance.

• TLS 1.2 or higher for data in transit. Every connection that moves patient data — between your systems, to your cloud provider, to your EHR vendor — must use current encryption standards.

• Multi-factor authentication for all ePHI access. Every user, every login, no exceptions. A username and password alone no longer meets the standard.

• 72-hour system restoration capability. If your systems go down — ransomware, hardware failure, hurricane — you need a documented, tested plan that proves you can be operational again within 72 hours. Not "we think we can." Proven.

• Vulnerability scanning every six months and annual penetration testing. Your systems need to be actively tested for weaknesses, with documented results and remediation plans.

• Annual compliance verification from every business associate. Your cloud provider, your EHR vendor, your billing service — every vendor that touches patient data needs to provide written verification that they are HIPAA compliant. Every year.

Here is why cloud migration makes these requirements more achievable: major cloud providers like Azure and AWS already meet most of these standards at the infrastructure level. Azure encrypts all data at rest by default. AWS provides AES-256 encryption across all storage services. Both offer MFA through their identity platforms. Both maintain SOC 2 Type II reports and HIPAA compliance attestations. Both will sign a Business Associate Agreement.

You still have to configure everything correctly. You still have to enforce policies. But you are not building compliance from scratch on bare metal — you are configuring it on a platform that was designed for it.

HIPAA penalties in 2026 range from $145 to $2,190,294 per violation, per identical provision. That is not a theoretical risk for a small practice. It is an existential one.

Your Complete Healthcare Cloud Migration Checklist

Here is the checklist, broken into five phases. Each phase builds on the previous one. Do not skip ahead — the temptation to jump straight to migration is strong, but assessment and planning are where most failures are prevented.

Phase 1: Assessment and Risk Analysis

Before you touch anything in the cloud, you need to know exactly what you have and where the risks are.

Map your current infrastructure. Document every server, workstation, network device, and application that stores, processes, or transmits ePHI. Include your EHR system, billing software, scheduling platform, email, document storage, backup systems, and any connected medical devices. Do not forget printers and scanners — they cache data too.

Identify all ePHI data flows. Where does patient data enter your system? Where does it move? Where does it leave? Trace it from the moment a patient provides information through every system that touches it. This is your data flow map, and you will need it for both the migration and your HIPAA documentation.

Conduct a risk assessment. Use the HHS Security Risk Assessment Tool or an equivalent framework to identify threats and vulnerabilities. Document everything. This is not optional under HIPAA, and it becomes your baseline for measuring whether the migration improves your security posture.

Inventory your software and licenses. Some applications run fine in the cloud. Others need modifications. A few will not work at all. Identify which category each application falls into before you start planning the migration architecture.

Assess your internet connectivity. Cloud-dependent operations require reliable bandwidth. A small practice with five to ten users needs at minimum 50-100 Mbps symmetrical for comfortable cloud-based EHR access. If your current connection cannot support this, factor an ISP upgrade into your timeline and budget.

Run the readiness script I have included in the tech section below to get an automated baseline of your infrastructure status.

Phase 2: Cloud Provider Selection and BAA

Not all cloud providers are created equal when it comes to healthcare.

Evaluate Azure, AWS, and Google Cloud for healthcare. All three offer HIPAA-eligible services and will sign Business Associate Agreements. Azure integrates natively with Microsoft 365, which most small practices already use. AWS offers the broadest service catalog. Google Cloud is strong on data analytics but has a smaller healthcare-specific ecosystem. For most small practices in Central Florida, Azure is the path of least resistance because you are probably already paying for Microsoft 365.

Sign a Business Associate Agreement before anything else. This is non-negotiable. Do not upload a single byte of patient data to any cloud platform without a signed BAA in place. Azure and AWS make this process straightforward — you can request and execute a BAA through their portals. But you need to do it explicitly. It does not happen automatically.

Verify HIPAA-eligible services. Not every service within Azure or AWS is covered by their BAA. Both providers maintain lists of HIPAA-eligible services. Stick to those services for anything that touches ePHI. If you use a non-eligible service for patient data, your BAA may not cover you.

Establish your cloud account structure. Create a dedicated resource group or account for healthcare workloads. Tag everything with compliance metadata. This sounds bureaucratic, but when audit time comes — and it will come — you want to be able to point at your infrastructure and say "here is everything that handles ePHI, and here is how it is segregated from non-regulated workloads."

Phase 3: Infrastructure Design and Security Controls

This is where the Terraform snippet comes in. You are building the cloud environment that your ePHI will live in.

Enable encryption everywhere. AES-256 at rest for all storage. TLS 1.2 minimum for all connections. Use your cloud provider's key management service — Azure Key Vault or AWS KMS — to manage encryption keys centrally. Enable infrastructure encryption (double encryption) for defense in depth.

Configure identity and access management. Set up Azure AD (now Entra ID) or AWS IAM with MFA enforced for all users. Implement role-based access control so staff members can only access the data they need for their job function. The receptionist does not need access to billing records. The billing specialist does not need access to clinical notes.

Set up audit logging. Every access to ePHI must be logged. Azure Log Analytics or AWS CloudTrail can capture these events, but you need to configure them to retain logs for the duration required by HIPAA — the regulation does not specify a minimum, but six years is the widely accepted standard because that is the HIPAA enforcement statute of limitations.

Configure backup and disaster recovery. This is where your 72-hour restoration requirement gets addressed. Set up geo-redundant backups — your data should exist in at least two geographic regions. Configure automated backup schedules. And critically, test your restoration process before you go live. A backup you have never tested is not a backup.

Network security. Use network security groups to restrict traffic. No ePHI system should be directly accessible from the public internet. Configure a VPN or Azure ExpressRoute / AWS Direct Connect for secure access from your practice's physical location.

Here is the Terraform snippet that provisions a HIPAA-compliant Azure starting point:

# Automate & Deploy — automateandeploy.com
# Terraform 1.9+ | AzureRM Provider 4.64+
 
terraform {
  required_version = ">= 1.9.0"
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.64"
    }
  }
}
 
provider "azurerm" {
  features {}
}
 
variable "practice_name" {
  description = "Short name for your practice (lowercase, hyphens only)"
  type        = string
  validation {
    condition     = can(regex("^[a-z0-9-]+$", var.practice_name))
    error_message = "Practice name must be lowercase alphanumeric with hyphens only."
  }
}
 
variable "location" {
  default     = "eastus2"
  description = "Azure region — eastus2 is closest to Central Florida"
}
 
locals {
  prefix = "${var.practice_name}-hipaa-production"
  common_tags = {
    Environment = "production"
    ManagedBy   = "Terraform"
    Compliance  = "HIPAA"
    DataClass   = "ePHI"
    Practice    = var.practice_name
  }
}
 
resource "azurerm_resource_group" "hipaa" {
  name     = "${local.prefix}-rg"
  location = var.location
  tags     = local.common_tags
}
 
# Audit logging — HIPAA requires 6-year retention
resource "azurerm_log_analytics_workspace" "hipaa_logs" {
  name                = "${local.prefix}-logs"
  location            = azurerm_resource_group.hipaa.location
  resource_group_name = azurerm_resource_group.hipaa.name
  sku                 = "PerGB2018"
  retention_in_days   = 365
  tags                = local.common_tags
}
 
# Network isolation — ePHI on its own subnet
resource "azurerm_virtual_network" "hipaa_vnet" {
  name                = "${local.prefix}-vnet"
  address_space       = ["10.0.0.0/16"]
  location            = azurerm_resource_group.hipaa.location
  resource_group_name = azurerm_resource_group.hipaa.name
  tags                = local.common_tags
}
 
resource "azurerm_subnet" "ephi_subnet" {
  name                 = "ephi-workloads"
  resource_group_name  = azurerm_resource_group.hipaa.name
  virtual_network_name = azurerm_virtual_network.hipaa_vnet.name
  address_prefixes     = ["10.0.1.0/24"]
  service_endpoints    = ["Microsoft.Storage", "Microsoft.KeyVault"]
}
 
# Encrypted storage — AES-256 at rest, TLS 1.2+, GRS
resource "azurerm_storage_account" "hipaa_storage" {
  name                            = "${replace(var.practice_name, "-", "")}hipaasa"
  resource_group_name             = azurerm_resource_group.hipaa.name
  location                        = azurerm_resource_group.hipaa.location
  account_tier                    = "Standard"
  account_replication_type        = "GRS"
  min_tls_version                 = "TLS1_2"
  https_traffic_only_enabled      = true
  allow_nested_items_to_be_public = false
  shared_access_key_enabled       = false  # Force Entra ID auth
  blob_properties {
    versioning_enabled = true
    delete_retention_policy { days = 365 }
  }
  network_rules {
    default_action             = "Deny"
    bypass                     = ["AzureServices", "Logging", "Metrics"]
    virtual_network_subnet_ids = [azurerm_subnet.ephi_subnet.id]
  }
  tags = local.common_tags
}
 
# Key Vault — purge protection prevents accidental key loss
data "azurerm_client_config" "current" {}
 
resource "azurerm_key_vault" "hipaa_kv" {
  name                        = "${replace(var.practice_name, "-", "")}hipaakv"
  location                    = azurerm_resource_group.hipaa.location
  resource_group_name         = azurerm_resource_group.hipaa.name
  tenant_id                   = data.azurerm_client_config.current.tenant_id
  sku_name                    = "standard"
  enabled_for_disk_encryption = true
  purge_protection_enabled    = true
  soft_delete_retention_days  = 90
  network_acls {
    default_action             = "Deny"
    bypass                     = "AzureServices"
    virtual_network_subnet_ids = [azurerm_subnet.ephi_subnet.id]
  }
  tags = local.common_tags
}

Let me walk through what this creates and why each piece matters.

The resource group is your container. Everything lives here, tagged with Compliance = HIPAA and DataClass = ePHI. During an audit, your compliance officer can query Azure Resource Graph by these tags to verify every ePHI resource has the right controls. Missing a resource is how practices fail audits.

The virtual network and subnet provide the network segmentation the 2026 rule now requires. Your ePHI workloads sit on an isolated subnet with service endpoints for Storage and Key Vault — meaning those services communicate over Azure's backbone, not the public internet. This is a detail most generic tutorials miss, and it is the difference between "technically in the cloud" and "properly isolated in the cloud."

The storage account is where the 2026 requirements really show. min_tls_version = "TLS1_2" enforces the mandatory encryption-in-transit standard. shared_access_key_enabled = false forces Entra ID authentication instead of shared access keys — shared keys cannot enforce MFA or role-based access, which makes them a compliance gap under the new rule. Geo-redundant storage (GRS) replicates your data to a paired Azure region, which is how you meet the 72-hour disaster recovery requirement when a hurricane takes out local infrastructure.

The Key Vault holds your encryption keys with purge protection enabled. If someone accidentally — or maliciously — deletes a key, it sits in a soft-deleted state for 90 days before permanent removal. Without purge protection, a deleted key means permanently unreadable data. That is a disaster you never want to have.

The Log Analytics workspace captures audit events with 365-day built-in retention. HIPAA wants six years, so you will need to set up an archive policy for longer-term storage, but this gets the foundation in place.

To deploy, install the Azure CLI, sign into your subscription (az login), and run:

terraform init
terraform plan -var="practice_name=your-practice-name"
terraform apply -var="practice_name=your-practice-name"

The whole thing provisions in about two minutes. After deployment, you still need to enable MFA for all users in Entra ID, configure RBAC role assignments, set up Azure Backup with 72-hour recovery testing, and replace the NSG source IP with your practice's actual IP range. But the foundation — encrypted storage, network isolation, key management, and audit logging — is the hardest part to get right, and now it is done.

Phase 4: Data Migration Execution

This is the phase where most practices get nervous. Understandably so — you are moving patient data, and downtime is not just inconvenient, it is potentially dangerous.

Migrate non-critical systems first. Start with email, document storage, scheduling — anything that does not directly involve clinical records. This lets you test your cloud configuration, verify connectivity, train staff on new access patterns, and build confidence before you touch the sensitive stuff.

Use a phased approach for ePHI. Do not try to move everything in a single weekend. Migrate one system at a time, starting with the least complex. Run the old and new systems in parallel for at least two weeks. Verify data integrity at every step. Have a documented rollback plan for each phase — if something goes wrong, you need to be able to return to the previous state within hours, not days.

Encrypt data during transfer. All data in transit must be encrypted with TLS 1.2 or higher. Use your cloud provider's migration tools — Azure Data Box or AWS Snowball for large datasets, or direct encrypted transfer for smaller volumes. Never transfer ePHI over an unencrypted connection. Not even once. Not even for testing.

Validate data integrity. After each migration phase, compare source and destination data. Check record counts, run checksums, verify that applications can read and write correctly. Document everything. This documentation becomes evidence for your compliance audit.

Decommission old systems securely. Once a system has been successfully migrated and verified in the cloud, the old hardware needs to be properly decommissioned. That means securely wiping drives (NIST 800-88 guidelines), documenting the decommission, and updating your asset inventory. Do not just unplug the old server and leave it in a closet. That closet server still has ePHI on it, and it is still your responsibility.

Phase 5: Post-Migration Validation and Compliance Audit

You are not done when the data is in the cloud. You are done when you can prove it is in the cloud correctly.

Run a full HIPAA compliance audit. Walk through every requirement — administrative, technical, physical, and organizational safeguards — and verify that your cloud environment meets each one. Document how you meet each requirement, what controls are in place, and what evidence supports your claim.

Test your disaster recovery. Actually test it. Not a tabletop exercise where everyone agrees it would probably work. Simulate a failure. Restore from backup. Time it. Can you be operational within 72 hours? If not, fix the plan and test again.

Conduct a vulnerability scan. Scan your new cloud environment for misconfigurations, open ports, weak access controls, and other vulnerabilities. Address anything that comes up before you consider the migration complete.

Update your policies and procedures. Your existing HIPAA policies reference on-premise systems. They need to be updated to reflect your new cloud-based architecture. This includes your risk management plan, your incident response plan, your business continuity plan, and your workforce training materials.

Train your staff. New systems mean new workflows. Your team needs to know how to access the cloud-based systems, how MFA works, what to do if they cannot connect, and who to call if something seems wrong. Untrained staff is the single largest source of HIPAA breaches, and a migration that confuses your team is a migration that increases your risk.

What Cloud Migration Actually Costs a Small Practice

Let me give you real numbers, because "it depends" is not helpful when you are trying to make a budget decision.

For a small healthcare practice in Central Florida with five to ten employees, here is what you are looking at for monthly cloud costs on Azure:

For the full migration project — assessment through validation — a practice doing the work with an IT consultant is looking at:

If you are technically capable and willing to use the Terraform templates and scripts in this post, you can cut those one-time costs by 50 to 70 percent. The infrastructure setup that costs $3,000–8,000 with a consultant becomes a couple hours of your time running Terraform commands and configuring settings.

Compare those numbers to the alternative: maintaining on-premise servers that meet 2026 HIPAA requirements. New server hardware with enterprise-grade encryption runs $3,000–8,000. A proper backup system with off-site replication is $2,000–5,000. Ongoing maintenance, patching, and monitoring — either your time or your MSP's — runs $500–1,500 per month. And when something breaks at 2 AM on a Saturday, that is your problem, not Microsoft's.

The cloud is not always cheaper on a pure monthly cost basis. But when you factor in hardware replacement cycles, maintenance labor, disaster recovery capability, and the compliance controls you get out of the box, most small practices come out ahead within 18 to 24 months.

Hurricane Season and the Case for Cloud

This section is specifically for Central Florida practices, because this is a conversation I have had dozens of times with practice managers in Daytona Beach, Ormond Beach, Port Orange, and all along the coast.

Hurricane season runs June through November. Every year. If you have been in Volusia County long enough, you have seen what a direct hit — or even a near miss — does to local infrastructure. Power goes out for days. Buildings flood. Roads become impassable. And if your patient records are on a server in your office, those records are offline until your office is operational again.

That 72-hour restoration requirement in the 2026 HIPAA Security Rule? It was practically written for this scenario. And for a practice relying on local infrastructure, meeting it after a Category 3 hurricane is somewhere between extremely difficult and impossible.

Cloud infrastructure changes the equation entirely. Your data is in Azure's data center in Virginia, replicated to a secondary region. The hurricane hits Volusia County, your office floods, and your patient records are exactly where they were before the storm. Your staff can access the EHR from a laptop at their home, from a temporary location, from anywhere with an internet connection and their MFA token.

I have seen practices lose weeks of productivity after storms because they could not access their systems. I have seen patient care delayed because records were inaccessible. These are not hypothetical scenarios in Central Florida — they are annual risks. Cloud migration does not just check a compliance box. For coastal Florida practices, it is a genuine patient safety measure.

When to DIY vs. When to Call for Help

You have read the checklist. You have seen the Terraform snippet and the readiness script. The question is: can you do this yourself?

The honest answer depends on your practice.

DIY makes sense if you have someone on staff who is comfortable with command-line tools, can follow technical documentation, and has time to dedicate to the project. The assessment and planning phases are entirely doable in-house. The Terraform snippet gets your infrastructure stood up. The post-migration validation is mostly following a checklist.

You need professional help if your EHR system requires custom integration work for cloud deployment, you have complex network configurations, you are migrating from a heavily customized on-premise setup, or nobody in your practice has the technical background to configure cloud security controls correctly. A misconfigured cloud environment can be worse than an on-premise one — open to the internet, improperly encrypted, with access controls that look right but are not.

The worst possible outcome is a migration that feels successful but leaves security gaps. If you are not 100 percent confident in your ability to verify the compliance controls, that is the point where outside expertise pays for itself.

We help healthcare practices across Central Florida with exactly this kind of migration — from assessment through validation. If you want a conversation about what your practice specifically needs, reach out to us. No pressure, no jargon. Just a straightforward assessment of where you are and what it will take to get where you need to be.

For practices in New Smyrna Beach, Daytona Beach, and surrounding areas, we offer on-site assessments as well as fully remote migration support.

What the Custom-Built Version Looks Like

The Terraform snippet and readiness script in this post give you a solid starting point. But the production version we deploy for healthcare clients goes significantly further:

• Terraform state locking with Azure Storage backend so multiple team members cannot overwrite each other's changes
• Automated drift detection that alerts you when someone makes manual changes to your HIPAA-tagged resources
• HIPAA audit log forwarding to a SIEM with full 6-year retention and automated breach notification workflows
• EHR vendor API integration for automated patient data migration with field-level validation and rollback
• Active Directory hybrid sync connecting your on-premise identity to Entra ID without disrupting existing logins
• PACS and imaging system migration with DICOM validation ensuring no imaging data is corrupted in transit
• Automated compliance remediation that reverts non-compliant configuration changes before they create exposure
• 24/7 monitoring with alerting for failed login attempts, unusual data access patterns, and off-hours ePHI access

The gap between DIY and production-grade is where most practices underestimate the effort. Azure HIPAA compliance has over 150 individual controls — the Terraform snippet above covers about 15. That is not a criticism of the DIY approach. It is an honest description of what "fully compliant" actually requires.

Want us to build this for you? Schedule a free discovery call — we will assess your current infrastructure, map out the migration path, and give you a realistic timeline and budget. No obligation, no jargon.

Not sure what to automate first? Take our free automation quiz to find out which processes in your practice would benefit most from automation.

FAQ: Healthcare Cloud Migration in Central Florida

What is a healthcare cloud migration checklist?

A step-by-step guide covering risk assessment, cloud provider selection, data mapping, security controls, phased migration execution, and post-migration compliance validation for moving healthcare systems to the cloud while maintaining HIPAA compliance. The checklist in this article covers all five phases from assessment through audit.

How much does cloud migration cost for a small medical practice?

For a small practice with five to ten employees, monthly cloud costs typically run $140–285 on Azure. The one-time migration project costs $10,500–28,000 with professional help, or significantly less for DIY-capable practices using Infrastructure as Code templates.

Is Azure or AWS better for healthcare?

Both offer HIPAA-eligible services and sign BAAs. Azure integrates natively with Microsoft 365, which most small practices already use, making it the path of least resistance. AWS offers a broader service catalog and can be more cost-effective for compute-heavy workloads. The best choice depends on your existing infrastructure and EHR vendor requirements.

How long does healthcare cloud migration take?

A typical small practice migration takes 12 to 22 weeks from assessment to completion. That breaks down to 2–4 weeks for assessment, 2–3 weeks for planning, 2–4 weeks for pilot migration, 4–8 weeks for phased production migration, and 2–3 weeks for validation and optimization.

What are the 2026 HIPAA requirements for cloud?

The 2026 HIPAA Security Rule requires AES-256 encryption for all ePHI at rest and in transit, MFA for all ePHI access, 72-hour system restoration capability, vulnerability scanning every six months, annual penetration testing, and annual vendor compliance verification. These are mandatory, not addressable.

Do I need a BAA with my cloud provider?

Yes. Absolutely. Non-negotiable. Do not upload any patient data to any cloud platform without a signed Business Associate Agreement. Azure and AWS both offer BAA execution through their portals. Sign it before you create your first resource.

Can I migrate to the cloud in phases?

Yes, and you should. Phased migration is the recommended approach. Start with non-critical systems like email and document storage, then move to more sensitive systems one at a time with parallel operation periods and documented rollback plans for each phase.

This article is part of our Healthcare & HIPAA cluster, covering compliance, automation, and IT strategy for Central Florida healthcare practices. For local practices exploring cloud migration, see also our guide to why Holly Hill and Daytona Beach practices are moving to the cloud.