Switching healthcare app vendors in 2026 without breaking HIPAA

TL;DR

Switching healthcare app vendors in 2026 is two projects at once: a technical handover and a change to your HIPAA control set. A vendor that handles protected health information on your behalf stays a business associate until that data is back with you or destroyed, and business associates were involved in 43% of healthcare breaches reported in the first half of 2026.

• Your outgoing vendor owes you return or destruction of patient data at termination, plus notice of any breach within 60 calendar days.
• Store accounts move slowest. Only an Account Holder can start an Apple app transfer, and the receiving side has 60 days to accept.
• No source code is a scoping problem, not a dead end. Pay for an analysis phase before committing to a rebuild.
• Update the risk analysis so it describes the vendor you have now.

Why a vendor switch is a HIPAA event

Most handover advice was written for a generic software project. Collect the files, collect the credentials, book a knowledge transfer session. In healthcare that is half the job, and the half nobody gets fined for.

The other half starts under one specific condition, and plenty of owners get it wrong. A development vendor is a business associate when it creates, receives, maintains or transmits protected health information on behalf of a covered entity or another business associate. Touching consumer health data is not the test. OCR's health app guidance puts a patient-directed app outside HIPAA, where the FTC Health Breach Notification Rule and state privacy law apply instead. Settle which side of that line your product sits on before you plan the exit, because it decides which obligations the handover has to satisfy.

Where the relationship does exist, the exposure is real. HIPAA Journal reads the OCR breach portal and finds business associate involvement averaging 20% of reported healthcare breaches from 2009 to 2017, 34% from 2018 to 2026, and 43% in the first half of 2026.

On March 5, 2026, OCR settled with MMG Fusion, a software vendor acting as a business associate, over a breach reaching roughly 15 million individuals. Two of the findings: no accurate and thorough risk analysis, and no notice to the affected covered entities, who still had to notify their patients.

The dates that decide who can ship your app

Two calendars run during a handover, and neither of them is yours.

From September 30, 2026, Google's developer verification reaches users in Brazil, Indonesia, Singapore and Thailand: an app must be registered by a verified developer before it will install or update on certified Android devices there. The requirement goes global in 2027. Verification binds an app to a verified identity and to its signing key. Whose entity holds the Play account, and who can produce the key?

The second date is regulatory. The Security Rule rewrite proposed in January 2025 is still a proposal, and the Unified Agenda lists final action for July 2027 under RIN 0945-AA22. Its third-party provisions would ask business associates to certify in writing that their safeguards meet it.

How we built this checklist

One test applies to every item below. If the outgoing vendor stopped answering tomorrow, could you ship a release and answer a regulator?

• Regulatory items come from the rule text at eCFR and from OCR enforcement documents.
• Platform items come from Apple and Google documentation, because store mechanics are neither negotiable nor guessable.
• Engineering items come from what we reconstruct after inheriting somebody else's codebase, and Mercury Development is a vendor too, so point every item here at us.

The handover at a glance

What your outgoing vendor still owes you

The contract ends. The obligations do not. Most of them sit in a business associate agreement you signed years ago and have not read since.

45 CFR 164.504 requires that agreement to say the vendor will, at termination and where feasible, return or destroy all protected health information it holds and keep no copies. Where that is not feasible, the protections extend to whatever remains. That exception is where backups live. Ask which systems hold copies and when retention expires.

HHS sample provisions point at 45 CFR 164.410 for breach reporting: notice to affected covered entities within 60 calendar days of discovery. They bind the vendor's subcontractors to identical terms too, so ask for that list.

One clause cuts the other way. If you know of a pattern of activity that materially breaches the agreement, you take reasonable steps to cure it, and where those fail you terminate the contract if termination is feasible. That is the whole of the current requirement. The report-to-the-Secretary alternative that survives in many older agreement templates is no longer in the codified text, so do not plan an exit around it. Termination is the remedy the rule names, which makes the switch the compliant move rather than the drastic one.

45 CFR 164.316 holds security documentation for six years from creation or last effect. The expired agreement and the destruction certificate belong in your file.

The assets to take before the last invoice

Code ownership comes from your development agreement, not from HIPAA. Ours is work-for-hire, with the customer owning the code and all underlying IP. Check whether yours assigns on payment or on final acceptance. Under the second wording, a project abandoned mid-phase leaves you owning nothing.

Then take what makes the code usable:

• The repository with its full history, not a zip of the current branch. A squashed export is a rewrite in disguise.
• A release runbook with exact tool and SDK versions, written for a stranger.
• An inventory of every secret, then rotation of all of them.
• An environment map: what runs where, in whose tenant, on whose card.
• A data export somebody has actually restored once.

The deliverable is not a folder. It is a build. If your incoming team cannot produce a running application from what you were handed, without asking the old team a question, the handover has not happened.

Store accounts and signing keys move slowest

Apple allows one Account Holder per organization, and only an Account Holder can start an app transfer or accept one. The receiving side has up to 60 days to accept, and completion takes up to two business days after that. If that person has left the outgoing vendor or died, reassigning the role needs Apple Developer Support.

A transfer is not an outage. The app stays on sale while it moves, keeps its ratings and reviews and its Bundle ID, and users go on receiving updates. The trap is auto-renewable subscriptions: the sending side generates an app-specific shared secret and passes it over before initiating, or receipt validation breaks while the store looks fine.

A Play transfer needs the registration transaction ID for both accounts, each registered and active, and Google replies to transfer requests within two business days. Decide whether the target keeps the existing upload key and app signing key. The delay here is never the platform. It is finding whoever still holds the account.

When there is no source code, buy an analysis phase

In healthcare the blocker is rarely refusal. It is that the buyer cannot produce what the incoming vendor needs.

What we see in scoping conversations: a partial repository, code samples offered in place of a codebase, a staging environment locked because a release is in flight. Sometimes no source code will be provided during development at all. That does not make the work impossible. It makes it unpriceable, and a fixed quote issued anyway is a fiction both sides pay for later.

What works is a separately priced analysis phase with one deliverable: a written answer on what can be salvaged, what has to be rewritten, and where patient data flows. That last part feeds your updated risk analysis anyway.

Element Labs came to us with configuration software its hardware supplier had handed over with no source code. We rebuilt it as a cross-platform application on a shared C++ core, and the relationship outlived Barco's acquisition of the client in 2010.

Keeping production alive during the cutover

Overlap, do not cut over. Both teams hold access for a defined window, the outgoing team is scoped down before it is revoked, and the revocation date is named in writing. Move the pipeline before the people: if the incoming team cannot deploy to staging on day one, knowledge transfer is theatre with a calendar invite.

Minimum necessary applies during a transition too. The incoming team needs the schema, the integrations, a realistic data volume. Seeding staging from a live patient database is the fastest way to turn a handover into a breach report.

Which switch you are actually running

Four situations, four opening moves.

A cooperative vendor is the cheap case. Buy their time. Paid transition hours from the people who wrote the code are the cheapest engineering you will ever purchase, and they expire when that team is reassigned.

A silent vendor is the account case. Everything depends on what already sits in your name, so start with the registrar and the billing roots.

A forced switch is the documentation case. Write the cure attempt down as you go, because somebody reviews that sequence later.

A partial switch, where the old vendor keeps some modules, is hardest. Two business associates, two subcontractor chains, and each agreement has to name which data that vendor may touch.

What our own case pages say about inherited code

Mercury Development publishes its case studies openly, and around 30% of them describe work that began as somebody else's codebase. Taking over a live product is an ordinary engagement shape here, not a rescue operation.

The entry points differ every time. A legacy Windows 8 client inside the long-running Fitbit engagement. Legacy Mac and Windows support at MiMedia that grew into the primary developer role. An already-shipped media player reviewed for FireCore, architecture left alone. Existing iOS and Android code entered at Tonal.

The medical billing platform we built for Precision Practice Management has run since 2006 and is on its fourth major release, described there as 100% HIPAA compliant.

The handover test that predicts the rest

Buyers ask the wrong question at the wrong time. "Will you support a handover?" gets a yes from every vendor alive, including the one that stops answering email in eighteen months.

Run a drill instead, in a quiet quarter when nothing is wrong. Ask for four things inside five business days: an archive of the main branch, the signing keys and distribution certificates, a DNS zone export, and the build runbook as it stands. A vendor with a real handover practice replies in a day, because none of it has to be created first.

Then apply the healthcare version. Ask where protected health information lives, which subcontractors touch it, and what would be returned or destroyed if you gave notice on Friday. A vendor that answers the first and stalls on the second built you an app without a boundary, and the boundary is what you are buying.

Written by Alexey Rodionov, Lead Front-end Developer at Mercury Development since 2020. Alexey is a Google Developer Expert in Web Technologies and a Chromium contributor whose code ships in Chrome DevTools, Google's Bubblewrap and Microsoft PWABuilder. The inherited codebase reviews and app store constraints described here come from the front-end practice he leads.

Mid-handover and unsure what is missing? Start with a code and access audit

Tell us what you hold today: repository, environments, store accounts, and where the business associate paperwork stands. We will come back with what is missing, what a new team could build from tomorrow, and what has to be recovered from the outgoing vendor before you sign anything else.