How We Helped a Top U.S. Healthcare Provider Integrate a Newly Acquired Health Organization Without Disrupting Patient Care
When one healthcare organization acquires another, the press release is the easy part. The hard part comes later, on an ordinary morning. A nurse at a newly acquired clinic sits down at a workstation, a patient is already waiting, and she has to log in to a system she has never used.
A top healthcare provider in the United States had just completed an acquisition and was facing exactly that. The leadership teams had agreed on a shared future. Now the people doing the work, including clinicians, front-desk staff, and administrators, needed to join the Provider’s systems, and that had to happen without a single missed appointment or locked-out provider along the way.
The Provider asked BroadDigix to help deliver the first phase of that integration. The goal was a secure, controlled path into the Provider’s identity, email, EMR, and network, ready by Friday, September 4, and live for production on Monday, September 7, 2026, which was Labor Day.
| Client | A top healthcare provider in the United States |
| Industry | Healthcare |
| Scope | Identity, Microsoft 365 email, MFA, EMR access, network & Wi-Fi enablement |
| Approach | Six-phase, pilot-first, staged change windows |
The situation: two organizations, one set of patients
The acquired organization came with its own tenant, its own local network built on UniFi, its own IT service provider, and staff whose routines were built around all of it. The Provider needed those staff to become Provider users quickly. Each person needed a new identity, a Microsoft 365 mailbox, multi-factor authentication, the right level of EMR access, and a way to reach approved Provider resources from the acquired clinics.
The pressure pushed toward doing everything at once: migrating every mailbox, merging the networks, and rebuilding endpoints in one push. We advised against that. In healthcare, a big-bang cutover moves risk onto the people least able to absorb it, the clinicians and their patients.
So Phase 1 was deliberately narrow. The job was to give approved people secure access to what they needed on day one and defer everything else. Historical email and file migration, endpoint management, tenant redesign, legacy retirement, and full network merging were explicitly excluded from Phase 1. Each of those was left for a separate, deliberate decision later.
Our approach: six phases, each one earning the next
We divided the work into six phases. Each phase had defined deliverables, and each had to be complete before the next could build on it.
What to actually do this week
Discovery came first, because every later phase depended on the user roster. Before creating any account, we worked with the acquired organization’s IT service provider to confirm an authoritative list of approved active users, their locations, their EMR requirements, and whether they needed email on their phones. We also named an owner for every area: business, technical, application, network, site, and support. Every one of the hundreds of later decisions needed a person who could approve it, so this step mattered. The deliverables were an approved roster with an exception list, a dependency register, and an implementation plan everyone had agreed to.
Identity and Microsoft 365 were the foundation. We provisioned Provider accounts only for users on the approved roster. We assigned licenses, security groups, and distribution lists, and we enabled mailboxes. MFA enrollment and Conditional Access validation were built into provisioning from the start rather than added later. Every provisioning run produced a report of successes, failures, skips, and exceptions, so nobody fell through the cracks without anyone noticing.
EMR access was handled separately. A clinical system cannot be treated like a mailbox. We confirmed the EMR’s authentication model, licensing, and role structure. After provisioning, the business owner validated the access. Validation meant more than checking that a user could log in. It meant confirming that a medical assistant saw what a medical assistant should see and nothing more. EMR access was complete only after user acceptance testing (UAT) sign-off.
Network and Wi-Fi came last and received the most caution. The two organizations did not need a fully merged network on day one. They needed a small set of specific traffic flows. We designed the connectivity as an explicit, approved matrix covering routing, firewall rules, DNS, VPN, VLANs, DHCP, and a Provider SSID broadcast at approved acquired locations on an isolated segment.
What the architecture looks like
The key design principle was least access by default. Users at the acquired organization reach the Provider’s cloud services directly through Entra ID, protected by MFA and Conditional Access. Only approved flows cross the site-to-site link, and the Provider’s Wi-Fi at the acquired clinics is isolated from the legacy network.
This design matters for security and for the future. An acquired network is an unknown network, and isolating it limits the damage if something in it has been compromised. Keeping the integration narrow also leaves Phase 2 open. When the Provider later decides how far to merge infrastructure, it can make that decision without first undoing shortcuts taken in a hurry.
Pilot first, then production in batches
No change reached the whole organization until it had worked for a small group first. We selected representative pilot users, a mix of clinical and administrative roles, at one approved acquired location. With them, we tested the complete day-one experience: sign-in, email, MFA, EMR, VPN, DNS, routing, Wi-Fi, and the support process when something breaks.
We also followed a rule that sounds obvious and is often broken under deadline pressure: never combine identity, MFA, EMR, VPN, Wi-Fi, and endpoint changes in the same change window. If sign-in fails on a Tuesday morning, you need to know which change caused it. Separate windows let us roll back one change without undoing the rest.
The challenges and how we planned for them
Integration projects rarely fail because the technology is hard. They fail because of details nobody examined early enough. These are the challenges we anticipated, and in a healthcare M&A integration you should expect them too.
The roster is never as clean as it looks. Former employees still have active accounts. Contractors appear with no end date. Two people share a name, and one person has three spellings of theirs. Provisioning from an unvalidated export copies every one of those errors into the new environment. We treated the approved roster as a formal sign-off artifact with a separate exception list, and no account was created without a match on that list.
Much depends on a third party you don’t control. The acquired organization’s IT was run by a service provider, so exports, firewall changes, and UniFi configuration all relied on their availability and cooperation. We logged every change on the acquired side as a named dependency with an owner and a date. We also agreed early on whether they would make changes themselves or grant controlled access for us to make them.
MFA meets clinical reality. Clinicians often use shared workstations and move between rooms, and some staff don’t want an authenticator app on a personal phone. An MFA policy that works well in an office can stall a clinic. We planned enrollment sessions around shift schedules, identified users who needed alternative methods before go-live, and tested Conditional Access against real clinical workflows. Blocking a physician at the point of care is itself a patient-safety incident, even if it is technically a correct security decision.
Conditional Access can lock out the people it protects. Location-based and device-based policies written for the Provider’s own sites may not recognize the acquired organization’s network or devices. We validated every policy with pilot users before production so that “access denied” surfaced during testing and not at 8 a.m. on go-live day.
EMR roles don’t map one-to-one. Job titles differ between organizations. A “clinical coordinator” in one organization may correspond to a different role in the other. Granting too much access creates compliance exposure, and granting too little stops work. We used a role-assignment checklist signed off by the business owner rather than inferring access from job titles.
Networks from two organizations often collide. Acquired networks frequently use the same private IP ranges, which breaks routing across a VPN until someone resolves the conflict with re-addressing or NAT. DNS causes similar problems when internal names must resolve correctly from both sides. We documented every required flow in a connectivity matrix before configuring anything, and each network change had a written rollback plan.
The calendar worked against us. Go-live fell on Labor Day, with readiness due the Friday before. Holiday weekends mean thin staffing on both sides, including the vendor. We made the September 4 readiness date a firm gate, arranged escalation coverage in advance, and made sure hypercare was staffed from the first hour.
Scope creep is well meant but real. As soon as staff have new accounts, they ask about their old emails, their files, and their Teams chats. Those were explicitly out of scope for Phase 1. We communicated that clearly and early so it wasn’t a surprise, and we directed each request to a change request or a follow-on SOW rather than absorbing it quietly.
People need reassurance as much as they need access. An acquisition is unsettling for staff, and a new login screen can feel like a small loss of identity. We treated onboarding help and plain-language communication as project deliverables with the same weight as the firewall rules.
The results
By go-live, 165 approved users across 04 acquired locations had Provider identities, active Microsoft 365 mailboxes, and completed MFA enrollment. EMR access was validated role by role and signed off through UAT. The isolated Provider SSID was live at 04 approved sites, and all approved traffic flows passed network validation.
Most importantly, patients were seen as scheduled, and no clinical downtime was recorded during the transition.
What we’d tell any organization going through an acquisition
Keep Phase 1 small enough to finish well. Treat the user roster as a controlled document. Test with real clinicians before anyone else depends on it. Separate your changes so a failure points to one cause. Plan for the holiday, the third-party vendor, and the doctor who won’t install an authenticator app.
An integration succeeds when the nurse at the new clinic logs in on the first morning, sees what she needs, and starts her day. For her, nothing noticeable changed, and that was the goal.
BroadDigix helps healthcare and mid-market organizations integrate identity, Microsoft 365, clinical applications, and networks after mergers and acquisitions. If you’re planning an integration, talk to our team
Get in touch: Broaddigix