I’ve overseen data migrations for Department of Defense systems - the kind where the wrong decision doesn’t cost a project timeline, it costs national security. When I talk to dental practices about switching their practice management software, I see the same category of risk handled with a fraction of the care.

Most IT vendors treat a PMS migration as a data transfer project. Move records from A to B, make sure the new system opens, done. But from a security standpoint, a PMS migration is one of the most dangerous moments in a dental practice’s operational life. Your patient data is in motion, your staff is distracted by a new system, your old system is still running in the background, and your vendor relationships are in flux.

That’s not a data transfer project. That’s an attack surface expansion.

Here’s how to get through it without becoming a cautionary tale.

Why PMS Switches Go Wrong

Dental PMS security is rarely discussed by the vendors selling you the system - but the migration window is when it matters most.

Before the checklist, it helps to understand the specific ways migrations fail - because most of the risks are predictable, and predictable risks have straightforward fixes.

1. Data loss during export

A dental practice data migration starts with one unavoidable problem: proprietary data formats. Your patient records, clinical notes, imaging data, and billing history don’t always move cleanly from one system to another. Dentrix exports require careful mapping to the target system’s schema. Eaglesoft’s X-ray data is stored in a proprietary format that cannot be bridged directly to Open Dental without a conversion tool and manual verification (Open Dental Eaglesoft Conversion Guide).

If you don’t audit the export before you decommission the old system, you may not discover the gaps until a patient asks for records you no longer have.

2. Exposure during transit

Data in motion is data at risk. During a migration, patient records travel across networks - sometimes to staging environments, sometimes to a vendor’s migration server, sometimes back again. If those transfers aren’t encrypted with current standards (TLS 1.2 or higher for in-transit data, AES-256 for data at rest), you’ve created a window where PHI is exposed (Censinet: Secure File Transfers in Healthcare).

Most IT vendors don’t default to the most secure option. You have to ask - and if they can’t answer specifically, that’s your answer.

3. Incomplete decommissioning

The old system keeps running. This happens more often than practices realize. The old system stays live for a “parallel run” period while staff get comfortable with the new one, and then nobody officially turns it off. Six months later, patient records exist in two systems. One of them is no longer receiving security updates. Both are PHI custodians under HIPAA.

In my experience auditing dental practices, shadow data - data that exists in systems your practice has forgotten about - is consistently one of the highest-risk gaps I find, and one of the least visible to practice owners.

4. Credential gaps

Your staff uses new credentials for the new system. What about the old one? If you haven’t explicitly revoked access to the prior PMS - and to every third-party integration that touched it - you’ve left doors open that should be locked. Former employees with standing credentials to a decommissioned system is a real threat pattern.

5. Vendor security you never verified

Every vendor that handles your patients’ protected health information must sign a Business Associate Agreement and must actually be able to back up the security posture that agreement implies. Most practices sign the BAA as a formality. A HIPAA-compliant migration requires that you assess the migration vendor’s security controls before the data moves, not after (MGMA: Security and Compliance in PMS).

The Security Checklist: Before, During, and After

This is the framework I use when I’m brought in to oversee a PMS migration. It’s not exhaustive - every practice’s situation is different - but it covers the critical decision points that determine whether a migration is a clean transition or a compliance event.

Pre-Migration (Before Anything Moves)

1. Complete data inventory Before you touch the old system, document everything it holds. Clinical records, billing data, imaging archives, patient communications, staff records. Know the scope of what you’re moving. This becomes your verification checklist post-migration.

2. Vendor security assessment Ask your new PMS vendor and your migration partner for documentation of their security controls: encryption standards, access controls, incident response plan, SOC 2 report if available. If your IT vendor can’t produce this, get a different IT vendor. The HIPAA Security Rule requires covered entities to select vendors who can demonstrate appropriate safeguards - it’s not optional, and a BAA signature alone doesn’t satisfy it.

3. Signed BAA in place before anything moves The Business Associate Agreement must be signed with every vendor that will touch ePHI during the migration - including the migration service, the temporary staging environment, and the new PMS vendor. Not after the migration. Before.

4. Encryption audit on both ends Verify that the source system, the destination system, and every staging environment in between support AES-256 encryption at rest and TLS 1.2+ in transit. If any part of the chain doesn’t meet that standard, the chain isn’t secure.

5. Identify integration dependencies Your PMS touches other systems: billing, imaging software, patient communication tools, insurance portals, payment processors. Map every integration before migration. Some may not be compatible with the new system. Some may have standing access that needs to be revoked. Know the full picture before you commit to a go-live date.

During Migration

6. Document chain of custody Every data transfer should be logged: who initiated it, when, from what system, to what system, via what method. In a DoD context, this is non-negotiable. In a dental practice context, it’s rare - but the HIPAA audit trail requirement applies to migrations just as it applies to normal operations. If something goes wrong, you need to be able to reconstruct what happened.

7. Encrypted transfer only No exceptions. No “we’ll encrypt it before we move it to the staging server.” The encryption travels with the data. If a migration step requires moving data outside an encrypted channel, that step needs to be redesigned.

8. Parallel run with defined end date Running the old and new system simultaneously is smart risk management - it gives you a fallback if something goes wrong. But the parallel run must have a defined end date, and that date must be enforced. Parallel runs that drift indefinitely become the shadow data problem described above.

9. Verify data completeness before cutover Before you decommission the old system, verify that every patient record, imaging file, and billing history transferred correctly. This means actually spot-checking records in the new system against the old one - not just trusting the migration vendor’s completion report.

Post-Migration

10. Revoke all access to the old system Every staff member’s credentials to the old PMS should be deactivated on the day you cut over. Every third-party integration should be disconnected. Then the old system should be formally decommissioned: data wiped to NIST 800-88 standards if the hardware is being disposed of, or the account closed and data deletion confirmed in writing if it was SaaS.

11. Credential rotation on the new system All administrative credentials for the new system should be rotated post-migration. This is basic hygiene, but it’s consistently skipped because “we just set up those passwords.” Rotate them anyway.

12. Access audit on the new system Verify that each staff member has only the access they need for their role. Clinical staff shouldn’t have billing admin access. Front desk staff shouldn’t have access to clinical notes they don’t use. The principle of least privilege applies here, and a fresh system is the right time to set it correctly rather than inheriting permissions that accumulated over years.

13. Backup verification Confirm that your backup system is working correctly against the new PMS. A migration that completes successfully but leaves you without a functioning backup isn’t a completed migration - it’s a delayed problem.

Ongoing: Who Owns Your Data?

This question doesn’t have a cutover date. It applies before you choose a new system, during the migration, and every day after.

Can you export your own data, in a standard format, at any time, without calling a vendor to do it for you? Can you leave the platform and take everything with you?

For most dental SaaS platforms, the honest answer is: not easily. Proprietary formats, data export fees, and migration costs are how vendors create stickiness. That’s not malice - it’s business model. But it means your practice’s clinical history can become a negotiating chip the moment you want to change vendors.

The Vendor Lock-In Problem

The dental software market is dominated by a few large players - Dentrix, Eaglesoft, Curve, and Open Dental, among others - and each has a different answer to the data ownership question.

Open Dental is open-source. Your data lives in a standard MySQL database. You can export it, move it, host it yourself, or migrate to another system without the vendor’s involvement. That’s a meaningful difference.

Most cloud-based dental SaaS operates differently. Your data lives on the vendor’s servers, in the vendor’s format, subject to the vendor’s policies. Monthly fees are the cost of access. When you stop paying, access ends - and getting your data out becomes a project. Rough implementation estimates I’ve seen for moving from Dentrix to another platform range from $3,000 to $15,000; from Open Dental, $2,000 to $8,000 depending on record volume and migration complexity. (Source: ai.dentist)

This isn’t just a financial issue. It’s a security issue. Multi-tenant SaaS environments mean your patient data sits alongside thousands of other practices’ data on shared infrastructure. A breach targeting the platform affects every tenant, not just the ones whose staff clicked a phishing link.

The client-owned infrastructure model Solas AI builds is different by design. Your workflows, your integrations, your patient data - all of it runs on a dedicated server that belongs to your practice. You have root access. You have the backups. If you ever leave, you take everything with you. There’s no vendor holding your data hostage, and there’s no multi-tenant breach risk. That’s what gives practice owners genuine peace of mind: not a vendor’s promise, but architecture they actually control.

Questions to Ask Before You Sign

Whether you’re evaluating a new PMS or a migration vendor, these are the questions that sort serious security posture from marketing copy.

  1. Where will my data be stored, and who has access to it? The answer should include specific infrastructure details, not “our secure cloud.”

  2. What encryption standards do you use for data at rest and in transit? AES-256 at rest, TLS 1.2 or higher in transit. If they can’t answer this specifically, that’s a red flag.

  3. Do you have a signed BAA, and can I see your SOC 2 Type II report? A SOC 2 Type II report means an independent auditor has reviewed their security controls over time, not just at a point in time.

  4. How do I export my data if I leave, and what does that cost? Get this in writing before you sign anything.

  5. What happens to my data if I stop paying? How long is it retained? In what format? What’s the process to get it out?

  6. Has your company experienced a data breach in the last three years? If yes, how was it disclosed, and what changed?

  7. Who do I call if something goes wrong at 2am? Not the sales rep. The actual incident response contact.

The vendor who handles these questions well is worth taking seriously. The vendor who deflects or gives vague answers is telling you something important about how they’ll handle your patients’ data.

Regulations Are Tightening

Data ownership isn’t just a best practice - it’s becoming a regulatory baseline. New regulatory frameworks like the EU AI Act signal that regulators globally are moving toward mandatory transparency requirements for AI systems handling patient data. The proposed 2025 HIPAA Security Rule update in the US follows the same trajectory, with stricter requirements for encryption, multi-factor authentication, and audit logging (HHS: HIPAA Security Rule NPRM).

Practices that build their infrastructure around data ownership now - where they hold the keys, they hold the backups, they control the vendors - will have a much easier time adapting to tightening requirements. That structure also makes ongoing compliance straightforward: you know where your data is, you control who can access it, and audits don’t require waiting on a vendor to pull reports. Practices locked into multi-tenant SaaS with limited export options will be chasing compliance while their vendors catch up.

The Bottom Line

A PMS migration is not an IT project. It’s a security event with a business continuity dimension, a compliance dimension, and a data ownership dimension. Treating it as anything less is how practices end up with incomplete records, shadow data, unrevoked credentials, and vendors they can’t leave.

The checklist above won’t cover every situation - your practice’s specific configuration, vendor relationships, and infrastructure will introduce factors unique to you. But it covers the things that go wrong most often, and it gives you the questions to ask the people handling your data.

If you’re planning a PMS switch - or you’re not sure how your current setup would hold up to this kind of scrutiny - Solas AI offers a free PMS security assessment. I’ll look at your current data environment, your vendor agreements, your backup situation, and your integration dependencies. You’ll leave with a clear picture of where the risks are and what to do about them.

No sales deck. Just specifics.

Book your free assessment at solasai.net.

Sources:

David Moline is a CISSP and CISM with a background in cybersecurity and AI systems. He built and secured infrastructure for the Department of Defense before founding Solas AI, which builds practice automation for dental offices, HVAC companies, and other service businesses. His work focuses on automation that’s practical, measurable, and built to handle the security requirements that healthcare practices actually face.