What Should Be Backed Up Before a Dental Software Migration? PMS Data, Images, Documents and Recovery Testing
Most dental practices do not start looking for IT support when everything is working. They start looking after the third morning an operatory computer freezes. Or when a sensor suddenly stops acquiring images and the imaging company says it is the network. Or when the network company says it is the software.
In dentistry, technology is not a corporate back-office function. It is a live component of the clinical day. If a workstation in operatory four cannot pull up Dentrix or display a CBCT scan, that room is functionally closed. Production halts, staff sit idle, and patients leave frustrated.
This guide breaks down exactly what reliable dental software migration and backup checklists look like in 2026—explaining how to coordinate multiple software platforms, imaging bridges, and strict security compliance without constant operational friction.
In this guide
- Separate “Data Being Converted” from “Data Needed to Recover”
- Protect the PMS Database Using Current Vendor Guidance
- Treat Dental Imaging as a Separate Protected Data Set
- Protect Documents, Attachments and Workflow Assets
- Create Two Recovery Points: Planning Snapshot & Final Cutover Copy
- Test Recovery Before the Practice Needs It
- Define Rollback Before the Migration Begins
- Keep Source-System Access Until Conversion is Validated
- For DSOs: Protect Every Location & Standardize Evidence
- Your Practice Needs Clear Technology Ownership
- Frequently asked questions
Separate “Data Being Converted” from “Data Needed to Recover”
The conversion vendor may need only a database export. A rollback may require more: application data, images, configuration, shared documents, server state, credentials and vendor access. Protect for recovery, not only conversion.
“An export file proves you can attempt a conversion. A recovery plan proves you can return to production if the attempt fails.”
- 1PMS DB
- 2Images
- 3Documents
- 4Config
- 5Credentials
- 6System State
- 7Recovery GateVerified
Migration and rollback data sets
| Data Set | Conversion Target? | Rollback Critical? |
|---|---|---|
| PMS database | Yes | Yes |
| Imaging repository/index | Depends | Yes if imaging affected |
| Documents/attachments | Depends | Yes if workflow requires |
| Application configuration | Often not exported | Often yes |
| Shared folders/templates | Not always | Often yes |
| Server/system configuration | No | Potentially |
| Credentials/vendor details | No | Yes for recovery/coordination |
Protect the PMS Database Using Current Vendor Guidance
Follow the current vendor’s supported backup/export procedure for the exact version. Do not assume a file-copy or snapshot is application-consistent unless the vendor documents it.
Record the source system/version, export/backup method, timestamp, database size, storage location and the person/vendor who verified it. If the PMS vendor supplies an export, retain the original protected copy in addition to any transformed conversion files.
PMS Backup Evidence Card
PMS backup evidence
| Version | Dentrix G7.8 Build 1024 |
|---|---|
| Time | Friday, 8:00 PM EST (Pre-Migration) |
| Location | Vault Recovery Partition E:// + Cloud |
| Method | Vendor-supported DB Export Util |
| Size | 148.4 GB (Clean verification) |
| Verified By | Ian Lynch (Lead Systems Engineer) |
Treat Dental Imaging as a Separate Protected Data Set
Images frequently live outside the PMS database. Identify the imaging application, database/index, underlying image files and storage location before migration day.
- DEXIS or other imaging database/index files
- 2D image repositories (raw x-rays, intraoral photos)
- CBCT / 3D high-density study storage
- Acquisition workstation local data/cache directories
- Specific imaging bridge configuration variables mapping patients to images
Protect Documents, Attachments and Workflow Assets
Clinical and business workflows may rely on files that are not inside the core PMS database: scanned documents, claims attachments, forms, templates, exports and shared folders. Inventory what staff would miss on Monday.
- Scanned documentsAre they stored inside PMS, document manager or a shared folder?
- Claim attachmentsWhere are the original images and active linkage records?
- Templates/formsAre custom consents database content or local files?
- Reports/exportsAre historical financial reports archived for business continuity?
- Shared foldersDo third-party integrations depend on specific local directory paths?
Create Two Recovery Points: Planning Snapshot & Final Cutover Copy
A pre-project snapshot protects against preparation mistakes; the final cutover backup represents the last authoritative state before data entry freezes. Label them clearly so nobody restores the wrong point.
Migration Chronology Checkpoints
- 1Baseline Snapshot01 · Phase 1 - PlanningBefore preparatory database changes are made
- 2Data Freeze Lock02 · Phase 2 - PreparationCut off practice entries to prevent desync
- 3Final Cutover Copy03 · Phase 3 - MigrationLast authoritative backup representing complete history
Test Recovery Before the Practice Needs It
A backup success notification is not proof that the practice can recover. At minimum, validate that the protected data is readable and the recovery method is documented; for critical systems, perform restore testing according to the practice's recovery plan.
Backup completeness logs verified
Job completes clean with zero soft-errors.
Secure isolated vault partitioning
Recovery copy is air-gapped from production domains.
Database credentials validation
Admins hold original root database keys.
Chronological restoration drills
Test DB successfully mounts to prove recovery speed.
Define Rollback Before the Migration Begins
Rollback needs a decision owner, deadline and sequence. “We will decide if something goes wrong” is not a plan when multiple vendors are working at midnight. Use a rollback clock, not an open-ended promise.
11:59 PM Sunday
Rollback Execution Plan
Trigger Workflows: Imaging bridges fail or database locks prevent Monday schedule mounting.
Decision Owner: Lead Practice Doctor + Authorized Legend Network Engineer.
Safe Deadline Window: No later than Sunday at 11:59 PM to allow full rollback procedures.
Keep Source-System Access Until Conversion is Validated
Do not decommission the old PMS or imaging environment because the new login works. Validate records, historical images, documents, reporting and retention needs; keep read-only access if contracts and policy allow.
- Ensure representative patient charts match historical expectations.
- Verify old x-rays and CBCT studies remain diagnostic and accessible.
- Confirm required scanned documents have carried over cleanly.
- Validate past financial balances before closing old accounts.
For DSOs: Protect Every Location & Standardize Evidence
A multi-location conversion needs a consistent backup/restore evidence packet per location or database. One successful pilot does not prove every acquired environment is recoverable.
DSO Compliance Checklist
- Location-specific database credentials isolated from production
- Individual PMS and imaging version mappings recorded
- Standardized, validated daily backup restore logs signed by lead engineers
- Rollback escalation protocol agreed by regional managers
Your Practice Needs Clear Technology Ownership
Technology is an investment that should secure your patient schedule, not disrupt it. Without clear, professional ownership of your clinical technology dependencies, your team remains exposed to constant operational friction and compliance risk.
By establishing structured, proactive safeguards and validating restore metrics prior to cutover, your practice can run reliably under any operational pressure.
Frequently asked questions
Quick, direct answers surrounding clinical dental software migrations, rollback windows, and secure data storage strategies.
Is a database export the same as a backup?
No. An export may be sufficient for conversion but may not contain every asset required to restore the old production environment.
Does a Dentrix backup include DEXIS images?
Do not assume it does. Identify where the imaging database/index and image files live and follow the current vendor backup guidance for each system.
Should we test the backup before migration?
Yes. Verify the recovery path before making destructive changes. The appropriate depth of restore testing depends on the system and recovery plan.
How long should we keep the old system?
Keep access until conversion scope, data, images and retention needs are validated and contractual/licensing arrangements are clear. Many practices benefit from a defined read-only period.
Who owns the backup during migration?
The IT partner should own the infrastructure/recovery plan; software vendors should provide product-specific backup/export requirements. Assign ownership explicitly.