{"id":137,"date":"2026-06-03T11:23:54","date_gmt":"2026-06-03T11:23:54","guid":{"rendered":"https:\/\/elva.ai\/articles\/?p=137"},"modified":"2026-06-03T11:23:55","modified_gmt":"2026-06-03T11:23:55","slug":"acquisition-playbook-any-pms","status":"publish","type":"post","link":"https:\/\/elva.ai\/articles\/acquisition-playbook-any-pms\/","title":{"rendered":"Your Next Acquisition Can Run Your Playbook on Day One \u2014 Whatever PMS It’s On"},"content":{"rendered":"

Every acquisition a DSO makes is also an integration project, and the hardest part is almost never the clinical side. It’s getting the new practice to operate<\/em> like the rest of the group. Standing in the way is a problem that has nothing to do with how the practice is run and everything to do with what it happens to run on: the practice you just bought is on a different practice management system than the rest of your group. If you want a new acquisition to follow your operating standard on day one \u2014 on any PMS \u2014 the premise to question is the one everyone accepts without noticing: that your standard depends on your software.<\/p>\n

One location is on Open Dental. Another came in on Dentrix Ascend. The practice you closed last quarter is on Dentrix Classic. Each was a sensible choice at the time. But to the team integrating acquisitions, that heterogeneity is a recurring tax \u2014 because operating standards have always felt tied to the software.<\/em> “How we do things” gets implemented inside a specific PMS, so a location on a different system can’t simply inherit the standard. It has to be re-implemented, worked around, or \u2014 the expensive option \u2014 the practice gets migrated onto the group’s system, with all the cost, downtime, data risk, and staff disruption that entails.<\/p>\n

So corporate development faces a bad menu on every deal: migrate the new practice (slow, costly, disruptive) so it can follow the standard, or leave it on its own system and accept that it runs differently from the rest of the group. Integration becomes a bottleneck, and the bottleneck limits how fast you can acquire.<\/p>\n

The standard lives in the Brain, not the PMS<\/h2>\n

This is where two parts of ELVA’s architecture combine into something more useful than either alone. The first is where the operating standard lives.<\/strong> The Brain holds your operating rules in its Three Minds governance layer<\/a> \u2014 Corporate, Local, Universal \u2014 and applies them when it acts and answers. Critically, those rules live in the Brain<\/em>, not inside any PMS. The corporate playbook is a property of the Brain, not of the software underneath it.<\/p>\n

The second is where the Brain sits.<\/strong> The Brain isn’t a PMS and doesn’t replace one. It’s an intelligent layer that operates on top of<\/em> whatever each location runs (the architecture is in the Practice Brain piece<\/a>). It connects down to the PMS for data, but the operating logic lives above it.<\/p>\n

Put those together and the conclusion follows directly: because the standard lives in the Brain, and the Brain sits above the PMS, the standard is portable across any PMS.<\/strong> A corporate guideline applies the same way whether the location underneath is on Open Dental, Dentrix Ascend, or Dentrix Classic \u2014 because the guideline was never a function of the PMS in the first place. The software is the substrate where the data lives; the Brain is the layer where the operating standard lives, and that layer is uniform across your whole group.<\/p>\n

\n

Under the hood \u2014 why the substrate doesn’t matter to the standard.<\/strong> Corporate rules are encoded and resolved within the Brain’s governance layer, not stored in or executed by the PMS. ELVA’s integration layer connects to each PMS and normalizes its data into the Brain; the governance layer that applies your rules sits above that integration layer and is identical across all of them. Change the substrate and the rules don’t change.<\/p>\n<\/blockquote>\n

What this changes for acquisition integration<\/h2>\n

A new practice joins your operating standard on day one \u2014 without a migration.<\/strong> You don’t have to move it onto the group’s PMS to get it onto the group’s playbook. ELVA connects to the system it already runs, and your corporate guidelines apply on top. The practice keeps its software; it adopts your standard. The two decisions are decoupled, where they used to be the same decision.<\/p>\n

Integration stops being a bottleneck on how fast you can grow.<\/strong> When “get the new practice onto our standard” no longer requires “first migrate it onto our PMS,” the operational lift of each acquisition drops sharply. The thing that used to slow a roll-up \u2014 every deal carrying a heavy systems-integration project \u2014 is largely removed. You acquire on the merits of the practice, not the convenience of its software.<\/p>\n

And \u2014 connecting back to the earlier pieces \u2014 day one is also when the new practice’s own knowledge gets captured into its Brain<\/a>, and when you decide, through the Three Minds precedence settings, exactly which corporate standards apply and which local ways it keeps. The acquired practice doesn’t just inherit your standard; it does so on terms you set, regardless of the PMS it came in on.<\/p>\n

The honest version of the claim<\/h2>\n

A technical evaluator will rightly probe this, so here’s the precise version. The operating-standard layer<\/em> is genuinely PMS-independent \u2014 your guidelines apply the same across systems because they live in the Brain. What is tiered per system is the depth of integration<\/em> with each PMS \u2014 how much ELVA reads from and writes back to Open Dental versus Ascend versus on-premise Dentrix Classic, which are genuinely different to integrate with. The portable standard is real and uniform; the integration depth is what we handle per system. That distinction is worth stating plainly, because it’s the honest version \u2014 and the honest version is still that your playbook travels to any location, on any PMS, on day one.<\/p>\n

You can now run one operating standard across practices on different systems, and bring new acquisitions onto it without migrating them. The remaining question is the other half of running a heterogeneous group: not just operating it consistently, but seeing<\/em> it \u2014 one current view across all those different-PMS locations at once. That’s the visibility problem<\/a>, and it’s where the series goes next.<\/p>\n

This is problem four of seven structural problems every multi-location group hits<\/a>.<\/p>\n

Frequently Asked Questions<\/h3>\n

Can a new dental acquisition follow our operating standard without migrating its PMS?<\/h4>\n

Yes. Because ELVA holds your operating rules in the Brain \u2014 a layer that sits on top of the PMS, not inside it \u2014 your corporate standard applies the same way whether the new practice runs Open Dental, Dentrix Ascend, or Dentrix Classic. ELVA connects to the system it already runs; the practice keeps its software and adopts your playbook on day one.<\/p>\n

Why has integrating acquisitions on different PMS systems been so hard?<\/h4>\n

Because operating standards have traditionally been implemented inside a specific PMS, so a practice on different software couldn’t simply inherit them. That left a bad menu: migrate the practice (slow, costly, disruptive) or leave it running differently from the group. ELVA removes that menu by keeping the standard above the PMS.<\/p>\n

Does the operating standard really apply identically across every PMS?<\/h4>\n

The operating-standard layer is genuinely PMS-independent \u2014 your rules apply the same across systems because they live in the Brain, not the PMS. What’s tiered per system is integration depth: how much ELVA reads from and writes back to each PMS. The portable standard is uniform; integration depth is handled per system.<\/p>\n

How does this speed up a roll-up?<\/h4>\n

When adopting the group’s standard no longer requires first migrating onto the group’s PMS, the operational lift of each acquisition drops sharply. Integration stops being the bottleneck that limits acquisition pace, so you can acquire on the merits of the practice rather than the convenience of its software.<\/p>\n

Do we still control which standards apply to an acquired practice?<\/h4>\n

Yes. Through the Three Minds precedence settings, you decide on day one which corporate standards apply and which of the practice’s local ways it keeps \u2014 so the acquired practice inherits your standard on terms you set, regardless of the PMS it came in on.<\/p>\n

Bring every acquisition onto your playbook on day one.<\/strong> See how the standard sits above the PMS in the architecture of the Practice Brain<\/a>, or explore ELVA for multi-location groups<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"

Every acquisition is an integration project, and the practice you just bought is on a different PMS than the rest of your group. Here’s why your operating standard never actually depended on the software \u2014 and how a new acquisition can run your playbook on day one, whatever PMS it’s on, without a migration.<\/p>\n","protected":false},"author":1,"featured_media":138,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[24],"tags":[43,67,36,30,64],"class_list":["post-137","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-dso-multi-location","tag-dso","tag-opendental","tag-pms-integration","tag-practice-acquisition","tag-standardization"],"_links":{"self":[{"href":"https:\/\/elva.ai\/articles\/wp-json\/wp\/v2\/posts\/137","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/elva.ai\/articles\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/elva.ai\/articles\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/elva.ai\/articles\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/elva.ai\/articles\/wp-json\/wp\/v2\/comments?post=137"}],"version-history":[{"count":1,"href":"https:\/\/elva.ai\/articles\/wp-json\/wp\/v2\/posts\/137\/revisions"}],"predecessor-version":[{"id":139,"href":"https:\/\/elva.ai\/articles\/wp-json\/wp\/v2\/posts\/137\/revisions\/139"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/elva.ai\/articles\/wp-json\/wp\/v2\/media\/138"}],"wp:attachment":[{"href":"https:\/\/elva.ai\/articles\/wp-json\/wp\/v2\/media?parent=137"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/elva.ai\/articles\/wp-json\/wp\/v2\/categories?post=137"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/elva.ai\/articles\/wp-json\/wp\/v2\/tags?post=137"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}