HIPAA Email Migration: A Healthcare IT Field Guide

A hospital inbox is not just an inbox. It carries lab results, referral letters, prior-auth approvals, and patient questions that the sender never should have put in email but did anyway. When you move that mailbox to a new platform, every one of those messages is regulated PHI and every hop is a moment where a covered entity can earn an OCR breach letter. This guide walks you through what changes when the data you are migrating is protected by HIPAA, and how to keep your audit trail clean while you do it.

What HIPAA actually says about email migration#

HIPAA does not name "email migration" anywhere in the Security Rule. It does, however, name the controls that govern it: access management, integrity, transmission security, and accountability. Every migration you run touches all four.

The Privacy Rule reaches your project the moment a message containing PHI is opened, copied, or transmitted by someone who is not the patient or their direct provider. A migration tool reading from a source server is, in HIPAA terms, performing a use and disclosure on your behalf. That is why your relationship with the migration vendor matters more than the technology stack.

The Security Rule then adds the technical safeguards. You owe encryption in transit, authentication of the parties, an audit trail of who touched what, and a documented process for closing access when the project ends. None of those obligations are new. What is new in a migration is that they all apply at once, to thousands of messages, over a compressed window.

The two paths PHI can take#

There are only two architectures that survive a HIPAA review. The first is a server-side migration where a vendor pulls from your source tenant, stores PHI on its infrastructure during the move, and writes it to the destination. That model only works when the vendor is itself a Business Associate and has signed a BAA with you. The second is a desktop migration where the tool runs on a workstation under your control, holds messages in memory or a local encrypted spool, and never relays PHI through a vendor-managed cloud. Both are valid. Both have trade-offs. What is not valid is running a free or "trial" cloud migration tool over PHI without a BAA because you wanted a quick test.

Sign the BAA before you sign the SOW#

A Business Associate Agreement is the contract that makes a vendor legally responsible for the PHI it processes. You need one with every entity that will see, store, or transmit your mail data. That includes the migration vendor, any sub-processors they use, and the destination platform itself.

The destination side is easier. Microsoft will sign a HIPAA BAA covering Exchange Online and Microsoft 365 commercial plans through the Online Services Terms. Google signs a BAA covering Workspace Business Plus, Enterprise, and Education editions through the admin console. Both are click-through agreements, but you must actively accept them. The default state for a brand-new tenant is not HIPAA-eligible because no BAA is on file.

If your migration touches Personal Gmail, Microsoft 365 Family, free Zoho, Yahoo, AOL, or any provider that refuses to sign a BAA, you have an unauthorised disclosure the moment PHI lands there. This sounds obvious until you find a clinician who has been forwarding patient mail to a personal Gmail account for two years.

Encryption in transit is non-negotiable#

The Security Rule treats encryption as "addressable" rather than "required," which has caused more confusion than any other word in HIPAA. In practice, OCR has treated cleartext transmission of PHI as a violation in almost every published enforcement case. Treat encryption in transit as required.

For an IMAP-based migration, that means every connection from the tool to the source server and from the tool to the destination server must be TLS 1.2 or higher with certificate validation. STARTTLS is acceptable on port 143 only if the implementation rejects the connection on TLS failure rather than falling back to plaintext. Implicit TLS on port 993 is the safer default.

If you see STARTTLS handshake failed in your migration log and the tool moves on without warning, stop the migration. That is a sign the tool is willing to negotiate downward, which is not what you want for PHI.

Where the tool stores messages matters#

Encryption in transit covers the wire. It does not cover the spool. If your migration tool buffers a mailbox to disk while it works, that on-disk buffer must also be encrypted. Ask the vendor where messages live during transit, in what format, and what removes them when the run ends.

Desktop tools that run on a workstation can take advantage of full-disk encryption you already deploy: BitLocker on Windows, FileVault on Mac, LUKS on Linux. Confirm those are enabled on the migration workstation before the first connection. A laptop that walks out of the hospital car park with a cleartext IMAP spool on it is a reportable breach, not an unlucky day.

Plan the audit trail before the first mailbox moves#

Auditors do not care that your migration went smoothly. They care that you can prove it went smoothly. The artefacts you need at the end of the project are easier to capture if you design for them on day one.

A defensible HIPAA audit log captures, per mailbox:

• The operator who initiated the move and how they authenticated.
• The source and destination addresses, with the source server hostname.
• Start and end timestamps in UTC.
• Total message count read from source.
• Total message count written to destination.
• Delta count, with reasons (duplicates suppressed, oversize, malformed).
• Any error code returned by source or destination, in full.

Many tools produce a per-run log file. Centralise these. A single CSV export per batch, written to a SIEM or to an encrypted SharePoint library with retention controls, is enough for most auditors. What is not enough is "we have it in someone's Downloads folder." See our audit logging guide for the schema we recommend for compliance-grade runs.

Office 365 vs Google Workspace for HIPAA destinations#

Both platforms are HIPAA-eligible. The choice rarely comes down to compliance and almost always comes down to clinical workflow.

Microsoft 365 holds the lead in mid-size and large hospital systems for three reasons: it ships with Microsoft Purview for retention and eDiscovery, it integrates with Active Directory and most EHRs that already federate, and it supports Information Rights Management for messages that must not be forwarded outside the organisation. The HIPAA-eligible plans are Business Basic and above on the SMB side, and any E or G plan on the enterprise side. The BAA covers Exchange Online, SharePoint, OneDrive, Teams, and Intune.

Google Workspace HIPAA-eligible plans are Business Plus, Enterprise Standard, Enterprise Plus, and Education Standard or Plus. The BAA covers Gmail, Drive, Calendar, Meet, Chat, Keep, Sites, Tasks, and Vault. The clinical pitch for Workspace is Vault, which provides robust retention and legal hold at a lower per-mailbox cost than Microsoft's equivalents. Smaller practices and FQHCs gravitate here.

If you are migrating between the two, our pillar migration guide covers the platform-agnostic mechanics. Layer the HIPAA rules in this post on top.

Retention on the old server#

A common mistake: decommissioning the source server the day after cut-over. HIPAA requires you to be able to produce records on request, and patients have a right of access to their own information for as long as you hold it. Keep the source server reachable, in a read-only state, until you have:

• Run a per-folder count reconciliation across the entire fleet.
• Sampled twenty mailboxes per department for message integrity.
• Confirmed that any in-flight legal hold or eDiscovery case has been transferred to the destination.
• Confirmed that on-prem archive PSTs or journal mailboxes have been imported.

Only then do you cut DNS, stop SMTP, and snapshot the source for cold storage. Plan for the snapshot to live at least as long as your stated retention period.

Cut-over windows in a 24/7 clinical environment#

Hospitals do not have weekends. They have quieter Tuesdays. Build your batches around clinical reality, not IT convenience.

Inpatient nursing stations and ED triage queues should be among the last to move. Outpatient clinics, finance, HR, and back-office functions move first. Resident and rotating staff inboxes need careful handling because the human is unlikely to be at a desk during your cut-over window.

A two-pass approach works well: a delta sync the night before cut-over, then a final delta after the user logs in on the destination the next morning. The second pass catches anything that arrived in the gap. The complete migration guide has the generic delta pattern; for HIPAA add a final integrity check that compares message counts per folder before signing off.

Handling shared and role-based mailboxes#

referrals@, records@, appointments@ — these mailboxes are where PHI piles up because patients use them without thinking. Treat them as their own project.

Shared mailbox migrations are harder than user mailbox migrations for three reasons. First, the permissions model is different on each platform and does not transfer cleanly. Second, the historical message volume is usually large. Third, there is no single human to sign off on the cut-over. Designate an owner per shared mailbox before you start, document the current delegate list, and re-create permissions on the destination as a deliberate step.

If you are running a hybrid environment during the project, route inbound mail to the destination first and forward to source while you finish. Reverse the flow as the last action of the cut-over. The 30 minutes that pattern saves you on every shared mailbox adds up.

Where compliance frameworks overlap#

If your organisation also holds SOC 2 attestation or is subject to GDPR for EU patients, the controls overlap more than they conflict. Our SOC 2 migration guide walks through the evidence collection that satisfies both. For EU-resident patient data, the GDPR migration article covers the Article 28 obligations that sit on top of HIPAA. The broader compliance-driven migration guide is the right starting point if you have not mapped your controls yet.

A minimal compliance checklist before you start#

Before the first mailbox moves, you should be able to tick every one of these:

• BAA signed with the destination platform and active on the tenant.
• BAA signed with the migration vendor, with a current sub-processor list reviewed.
• TLS 1.2 or higher enforced on both source and destination connections.
• Migration workstation has full-disk encryption enabled and is enrolled in MDM.
• Audit log destination identified, with retention configured.
• Source server retention plan documented and approved by your compliance lead.
• A communication plan for clinicians, with a non-IT helpline for the cut-over window.
• A breach-response plan rehearsed for the project.

The list is short. The work behind each line is the project.

What changes if you use a desktop migration tool#

A desktop tool like Mailbox Taxi simplifies parts of this analysis because PHI never reaches a third-party server during the move. The tool runs on your workstation, opens IMAP connections to source and destination, and transfers messages in process. There is no vendor cloud holding intermediate copies.

That does not remove your HIPAA obligations. You still need a HIPAA-eligible destination, you still need to authenticate users, you still need encryption in transit, and you still need an audit log. What changes is the BAA conversation: there is no vendor sub-processor list to worry about because there is no vendor sub-processor.

You also gain control over where the work happens. A migration workstation inside the hospital network, under your endpoint management, behind your firewall, leaves a smaller exposure surface than a cloud connector that has to reach into both tenants.

FAQ#