DSO Technology Strategy: What to Standardize First and in What Order

Office four came with a server in a closet, an imaging program nobody else in the group uses and one front-desk login that six people share. Office five runs a cloud system the seller chose years ago. Email lives in three places. When a lender asks which practice software the group uses, the honest answer is that it depends which door you walk through.

This guide is for whoever runs operations or integrations at a dental group that has outgrown one office's setup and has another opening or acquisition on the calendar. It gives you the order and the reason for it, a one-page plan you can fill in, a 90-day sequence for an acquired office, a way to model cost per location, and the questions to put to whoever runs your IT. Vendor and regulatory wording is quoted from each source's own page, read on 12 November 2026.

What should a dental group standardize first?

Standardize identity and email first, then backup and security, then the network, then practice management software and imaging, and phones last. That order moves from the layers that carry the most risk and interrupt patients the least toward the layers that touch every appointment, so the hardest changes happen on a foundation that is already uniform.

The usual instinct runs the other way. Leadership wants one practice software and one set of reports, so the first project is a data conversion at an office whose backups have never been tested and whose staff still share a password. The order below keeps the clinical systems alone until the group can sign in, restore and see every office.

Two notes on reading the table. The order is about where to start, not about finishing one layer everywhere before touching the next: an office with a failing server may need layer four early. And the "done when" column is the part to copy. A layer is finished when a test passes, not when the project budget is spent.

What goes into a one-page DSO technology strategy?

A one-page DSO technology strategy records eight decisions: the group standard for each of the six layers, who runs the plan, and how exceptions are approved. Each line carries a default, a named owner and a review date. If a decision does not fit on one line, it has not been made yet.

The page is short on purpose. A regional manager should be able to read it before an office visit, and a seller should be able to read it before closing and know what will change and when.

The document that holds the detailed standard for each layer, and the routine for detecting drift from it, is a different thing from this page. Our guide to what DSO IT services cover has that matrix; this page is the layer above it, the part leadership signs.

How does the technology plan change as the group grows?

The plan changes at four moments, and none of them is an office count: opening the second office, closing the first acquisition, hiring the first regional manager, and taking outside capital. Each adds one or two decisions that were optional before. Making them all at office two wastes money; leaving them until office ten makes every one a migration.

The ADA Health Policy Institute, which tracks practice size every year, says "The latest data indicate that dentist affiliation with large group practices and DSOs continues to grow, especially among early career dentists." More groups are reaching these moments, and most reach them with the technology of a single office.

If office two is a new build, most of this is easier, because the standard can be designed into the floor plan. That work sits with dental startup IT, and the published office counts of the groups that have done it at scale are in our list of the largest DSOs in the US.

Why do identity and email come before everything else?

Identity comes first because every other layer depends on knowing who a person is. One directory with one account per person lets you grant access to practice software, imaging, backup consoles and payer portals by role, see who signed in, and remove someone from every office in one step on the day they leave.

In a group built by acquisition, each office usually arrives with its own Microsoft 365 or Google account, its own email domain and a few shared logins. Bringing those together is real work. Microsoft's own documentation opens its guide to moving mailboxes between organizations with the words "During mergers or divestitures, you might need the ability to move your users' Exchange Online mailboxes into a new tenant." Plan it as a project per office, not as a setting.

Decide four things on this layer:

1. 1. One directory. Every employee, at every office, has a named account in the group's directory. Clinical staff who float between offices keep the same account.
2. 1. Email domain policy. Either every office moves to the group domain, or each office keeps its brand domain inside the group's account. Both work; mixing them without a rule does not.
3. 1. Multi-factor sign-in for everyone. Microsoft already requires it for sign-ins to its own admin tools: "Starting in February 2025, MFA enforcement gradually begins for sign in to Microsoft 365 admin center." Front-desk and clinical accounts deserve the same protection, because they open the same patient records.
4. 1. Joiners, movers and leavers. One request form, one person who acts on it, and a same-day target for removing access.

The licensing and setup detail is in our guide to Microsoft 365 for dental offices. The logins that sit outside the directory, such as insurance portals that only allow one user per office, are their own problem; see shared payer portal logins and MFA in dental groups.

What must be the same at every office for backup, security and the network?

Every office needs the same minimum: a backup with a second copy off site and a dated test restore, the same security tools reporting to one console, supported versions of Windows, and a network built from one template. The products can differ during a transition. The minimum and the evidence that it is met cannot.

The usual way a group finds out it has skipped this is a failed server at one office and a cloud backup that stopped updating weeks earlier. Nobody had looked, because nobody owned the question across offices.

The HIPAA Security Rule frames the same minimum as safeguards. It asks for "an accurate and thorough assessment of the potential risks and vulnerabilities" to electronic patient information, and for a data backup plan: "Establish and implement procedures to create and maintain retrievable exact copies of electronic protected health information." This guide does not interpret the rule for your group; it points out that a per-office minimum with evidence is what makes those two sentences answerable for twenty offices instead of one.

Operating systems are where an acquired office most often fails the minimum on day one. Microsoft's lifecycle pages give the dates: Windows 10 was retired on October 14, 2025, updates for Windows Server 2016 end on January 12, 2027, and Windows Server 2019 follows on January 9, 2029. Put every office's servers on one calendar; our guide to Windows Server 2016 end of support covers the first of those deadlines.

Each of these items has its own owner page on this site: dental data backup for the copy and the restore test, dental cybersecurity services for the tools and monitoring, and dental office network setup for the template.

Should every office run the same practice management software?

Not on day one, and sometimes not at all. One system gives the group one set of reports, one training program and one integration to maintain. A conversion also costs staff time and carries data risk. The workable rule is a single group system for new offices and a written keep, align or convert decision for each acquired one.

"Align" is the option most plans forget. An office can stay on its current software and still be brought to the group's supported version, backup, sign-in rules and report definitions. That removes most of the risk without a conversion, and it buys time to convert when the calendar is quiet.

If the group chooses one database for several offices, read what the vendor says about running it that way. Open Dental's manual describes its Clinics feature in one sentence: "The Clinics feature allows multiple locations to be run from one database while keeping locations separate for reporting." The same manual is blunt about the alternative of keeping a database at each office synchronized: "It takes a very skilled database administrator to keep the synchronization running smoothly and to properly handle a downed network." A single database then depends on every office's connection to it, which is why the network layer comes before this one.

Cloud practice software removes the server from each office and moves the dependency to the internet connection and the vendor. It suits groups that open often. It is not automatically smoother: a switch made without checking each office's connection, imaging bridge and training time can leave the front desk slower than it was before. Our comparison of cloud-based dental practice management software and the guide to server replacement versus cloud migration cover that choice, and the dental software migration checklist covers the conversion itself.

Whichever way the decision goes, someone has to look after the servers, services and bridges underneath it. That is dental practice management software support, and it should be named in the plan.

How should a group handle imaging across locations?

Standardize the imaging software and where images are stored before you standardize sensors. Sensors, panoramic units and cone beam machines are expensive, clinically chosen and long-lived, so they usually stay. The software that captures and stores the images, and the bridge that opens the right patient from the practice software, is what the group can make uniform.

Imaging is where two offices that look the same on paper turn out to differ. Both run the same practice software, but one stores images on a server in the building and the other in a vendor's cloud; one opens images from the chart with a click and the other needs the patient searched by name. The plan needs three lines:

• • Approved imaging software per practice software. Name one, or at most two, and record which sensor and device families each supports.
• • A storage rule. Where images live, how they are backed up, and how an image taken at one office is seen at another.
• • A device policy. Existing sensors and units stay until end of life unless the approved software cannot drive them; replacements come from the approved list.

When an acquired office's images have to move into different software, treat it as a conversion with its own test: pick twenty patients, and confirm every image opens from the chart with the right date and tooth numbers before the old system is switched off. The faults that follow a rushed move are in our guide to dental imaging integration troubleshooting.

When should phones join the plan?

Phones join the plan last, as each office's contract ends. A group phone design gives you one call flow, shared overflow between offices and consistent recording rules, and those are worth having. But phones rarely block another layer, and breaking a contract early usually costs more than waiting a few months for it to end.

Write three things down now so the later move is easy: every office's contract end date, who owns each phone number (the practice, the seller or a carrier reseller), and whether the phone system connects to the practice software for caller pop-ups or reminders. Number ownership is the one that causes trouble after an acquisition; confirm it in writing before closing. The service page for dental phone systems and our guide to VoIP phone systems for dental offices cover the design choices.

How do you integrate an acquired dental office in 90 days?

Work in four stages: take control in the first week, move identity and email by day 30, bring backup, security and the network to the group minimum by day 60, and decide and date the application changes by day 90. Each stage ends with a test. Practice software conversion is scheduled inside the plan, not forced into it.

Ninety days is a planning frame, not a promise. An office with supported equipment and a cooperative seller can move faster, and one with an out-of-support server and no documentation will not. The order holds either way. What you learn before closing decides how hard each stage will be, and that work is in our guide to dental practice acquisition IT due diligence.

Four habits keep the 90 days from stretching:

• • Schedule every change that touches the front desk or an operatory against the appointment book, and tell the office manager a week ahead.
• • Change one thing at a time at each office. A new sign-in and a new network in the same week makes every problem hard to trace.
• • Keep the old system readable until the new one has passed its test. Nothing is switched off on the day its replacement goes live.
• • Close the project with a written handover: what changed, what did not, and what is scheduled.

What does technology cost per location, and how do you model it?

Model technology cost per location in three columns: one-time integration cost, recurring cost per office, and recurring cost per user. Keep them apart. The first is paid once per office and belongs in the acquisition or opening budget; the other two are the run rate, and they are what should fall as offices come onto the standard.

This guide gives no dollar figures, because the honest range across offices is too wide to help. What stays constant is the list of lines. Fill it in for one office that is on the standard and one that is not; the gap between them is the cost of the exception, and it is the number that makes the case for the next project.

Three rules make the model useful. Budget replacement as an annual line, not as a surprise: a list of dental servers and workstations by age turns emergency spend into a schedule. Ask every vendor whether its fee is per office, per provider or per user before you add an office, because that decides how the line grows. And review the recurring columns office by office each quarter; where they do not fall after integration, something was added without anything being removed. The method for finding those lines is in our guide to hidden IT costs in dental groups.

Who should own the technology plan: an internal lead, an outside provider, or both?

The plan needs one named owner inside the group at every stage, even when an outside provider does all of the technical work. Decisions about what offices share, what exceptions are allowed and what gets funded belong to the group. Building, monitoring and fixing can be outsourced; deciding cannot.

The office counts below are a rough guide, not thresholds; the trigger is how much coordination the group needs.

Whatever the split, offices need one route for help, and the agreement should say who answers it. If "managed service provider" is a new term, our explainer on what an MSP does for a dental office defines it, and the guide to what a managed IT plan covers for a dental practice lists what is normally inside the monthly fee. If the group is ready to compare agreements, the service page for managed IT services for dental practices is the place to start.

How do you know the strategy is working?

The strategy is working when four numbers move in the right direction each quarter: the count of open exceptions falls, the days needed to bring a new office to the group minimum fall, every office shows a recent test restore, and support requests per office converge. If those are flat, the plan is a document and not yet a practice.

Review the scorecard quarterly with the same people who review the financials. Technology plans drift when they are reviewed only by the people who run the technology.

The IT side: what your provider should be doing while the plan runs

While leadership decides what to standardize, the provider's job is to make each office visible and each change reversible. That means an asset inventory that updates itself, alerts from every office in one place, a tested backup before any change, and a written rollback step for every piece of work that touches a server, a firewall or the practice software.

Ask for these as routine outputs, not special projects:

1. 1. A monthly report by office: devices and ages, operating system versions, security coverage, backup results and the last restore test.
2. 1. A change calendar that shows what will be done at which office and when, agreed with each office manager.
3. 1. A site document per office, updated after every change.
4. 1. A record of every exception and its review date.
5. 1. A handover note at the end of each integration.

Day-to-day requests need the same clarity. Staff at every office should have one number and one process, and know what the help desk handles and what goes to a software vendor; our guide to what a dental IT helpdesk handles sets out that split. The service that sits underneath all of it, for one office or thirty, is dental IT support.

What to ask your IT provider about a multi-office plan

Ask about four things: the order of work and the written standard, the first week at an acquired office, which fees grow per office and which per user, and how staff at every office reach support. A provider with a real multi-office method answers each with a document, a report or a date, not with a description.

If you are comparing providers on these answers, our guide on how to choose a dental IT company gives a scoring method, and our review of the best dental IT companies compares the national firms side by side.

How Legend Networking works with growing groups

Legend Networking is a Dallas-based dental IT company that has served over 3,500 practices since 2004. Legend provides 24/7 monitoring with in-house engineers; no outsourced first-level triage. Support is remote-first nationwide, with onsite dispatch by appointment across served dental markets. Legend supports the IT environment for the practice software Dentrix, Eaglesoft, Open Dental and Archy, and for the imaging systems DEXIS, Vatech, Carestream, Planmeca/Romexis and Dolphin Imaging, which are the two layers where a group's offices most often differ. The group-level service is described on the DSO IT support page.

The author, Ian Lynch, has 22 years in dental IT and oversees the NOC, onsite dispatch and client technology roadmaps. Legend holds a 4.8 rating from 173 Google reviews. For an example of the opening-a-second-office moment, see a group's second office opening in downtown Austin. If your offices are spread across several markets, start from the dental IT in your city pages to find each one.