The technical work of migrating a medical or dental practice is much the same as any other business. What differs is everything around it: the agreements required before data moves, the constraints imposed by clinical software vendors, and a downtime tolerance measured against patients sitting in a waiting room.
Business Associate Agreements come first
Before any electronic protected health information reaches a cloud service, a Business Associate Agreement must be in place with that vendor. This is not a formality to complete afterwards.
The major cloud providers will sign BAAs, but with an important qualification: only specific services within their platforms are covered, and the agreement typically requires you to configure those services in defined ways. Using a service outside the covered scope, or misconfiguring a covered one, places you outside the agreement.
This applies to your IT provider as well. A provider with access to systems containing ePHI is a business associate and must sign. A provider unwilling to do so cannot manage your environment.
Practical step: build a complete list of every vendor that will touch ePHI post-migration, and confirm each has a signed BAA before cutover. Practices routinely find a service handling patient data with no agreement in place, and a migration is the natural moment to find and fix that.
The EHR vendor sets much of the agenda
Your practice management and clinical systems are the constraint everything else works around, and their vendors are less flexible than general business software vendors.
Establish early:
- Whether the vendor supports cloud hosting at all, and in which environments specifically. Some certify only named configurations.
- Whether they offer a hosted version, which is frequently a better path than lifting their on-premise product into your own cloud infrastructure.
- What their licensing permits. On-premise licences do not always allow cloud hosting.
- Whether they will support the environment afterwards. A vendor who declines to support a configuration they did not certify creates a serious operational gap.
- Their own migration process and lead time, which is usually theirs to run rather than yours.
The honest outcome for many practices is a hybrid arrangement: general infrastructure and productivity move to cloud, while the clinical system stays where the vendor supports it. That is a legitimate result rather than a failure, and planning for it is better than discovering it.
Clinical devices and modalities
The equipment that makes a healthcare environment different from an office:
- Imaging equipment with local storage and often an embedded, unsupported operating system that cannot be patched or moved
- Devices communicating over clinical protocols that assume a local network and behave poorly across a wider one
- Equipment with hard-coded server addresses that require a vendor engineer to change
- Systems where any modification voids certification or a support agreement
These frequently cannot move and often cannot be updated. The realistic approach is network segmentation — isolating them so their weaknesses are contained — rather than attempting to bring them into the new environment.
Downtime is a clinical constraint
A general business can absorb a slow Monday. A practice with a full schedule cannot see patients without access to records, and rescheduling a day of appointments has consequences beyond revenue.
What follows from that:
- Cutover windows must sit entirely outside clinical hours, with genuine contingency before the next session
- A documented downtime procedure — how the practice operates on paper if systems are unavailable — needs to exist and be understood before migration day, not improvised
- Rollback timing must be planned against the start of the next clinical session rather than against a generic maintenance window
- Read-only access to recent records during migration is worth arranging where the vendor supports it
The downtime procedure is worth having regardless of migration. It is a HIPAA contingency plan requirement, and practices that have one handle both planned and unplanned outages substantially better.
Compliance obligations that follow the data
- Update the risk analysis. The environment has changed materially, which is exactly the trigger the Security Rule contemplates for revisiting it.
- Confirm encryption at rest and in transit in the new environment, and document the configuration.
- Verify audit logging is enabled and that logs are retained and reviewable — a required specification, and easy to lose in a migration.
- Re-examine access controls. Migrations are a common point at which permissions get broadened for convenience and never narrowed again.
- Confirm backup and contingency arrangements in the new environment, and test a restore.
- Update documentation and policies to describe what now exists.
The first item is the one most often skipped and the most consequential. An analysis describing the pre-migration environment is, for regulatory purposes, close to no analysis at all — and it is the failure most frequently cited in enforcement actions.