Migrate your Dentrix data

Patient demographics, contact information, medical alerts, and insurance records are stored in structured .dat tables. We extract all active and historical patient records and map them to the destination schema field-by-field. Archived or inactive patients require a separate export flag.

Charting data including tooth conditions, procedure history (CDT codes), and periodontal records are stored per-visit. We preserve the full treatment history per patient but note that charting format varies significantly between practices due to custom template usage.

Appointment records including provider, date/time, chair assignment, and procedure codes are extractable from the appointment ledger. We reconstruct the appointment book including provider schedules and appointment types.

Claims history, claim status, payer information, and EOB records are stored in the ledger. We preserve submitted claim data but note that in-flight (unprocessed) claims must be submitted before migration cutover to avoid silent loss.

Open and historical ledger entries, including adjustments, payments, and write-offs, are stored in the ledger .dat file. Balance-forward accounts require special handling to avoid inflating charges on the destination system.

Proposed and accepted treatment plans are attached to patient charts. We extract treatment plan records and preserve the planned vs. completed status flag, which is critical for case acceptance tracking.

Uploaded documents (forms, consent documents, referral letters) are stored in a file archive on the Dentrix server. We map file references to their physical location on disk. Direct file migration requires access to the file store path.

Imaging files (intraoral X-rays, extraoral photos, panoramic images) are stored separately from the database and linked by file path. We preserve path references so the new system can point to the same archive. Imaging file binary migration requires separate transfer.

Provider records including doctor names, NPI numbers, credentials, and schedule templates are stored in the system. We map provider IDs to ensure historical appointment records maintain the correct provider attribution.

Chair/operatory configurations and facility-level scheduling rules are hard-coded to the local server setup. These do not have a clean export path and must be manually reconstructed at the destination. We do not migrate this object.

Many practices add custom fields to patient or clinical records. Custom properties are stored in separate .dat tables. We inventory all custom fields during discovery and map them explicitly since there is no standard schema.

Insurance plan records including payer name, plan type, and fee schedules are stored in the payer table. We map active and historical insurance plans to the destination system. Deprecated or inactive payer records require archival handling.