Dental Software Migration: A Billing Readiness Guide

A dental software migration moves records from one practice management system to another. Billing readiness means the office can explain the balances it starts with, continue unfinished insurance work, and record new activity without losing or duplicating transactions. Those checks belong in the launch plan alongside scheduling and clinical record review.

This guide focuses on the transition between systems for U.S. dental practices. It provides an operational checklist, not instructions for running a conversion utility. Ask your software vendors to confirm the actual conversion scope and supported workflows. The suggested checkpoints are planning examples, not universal vendor requirements.

Existing daily billing procedures still apply after the move. The additional task is to establish which system owns each record, what changed during conversion, and how the office will prove that unfinished work survived the handoff.

Request a written conversion scope before choosing the final transfer date. For each record type, ask whether the destination receives usable detail, a summary balance, reference-only history, or no data. A patient name appearing in the new system does not prove that the patient's claim history or payment allocation transferred with it.

Open Dental's Use Converted Database guidance notes that transferred data depends on the previous software. Its Outstanding Claims guidance also warns that most final conversions do not transfer outstanding claims. These vendor-specific examples show why practices must confirm scope rather than assume every open item will arrive ready to work. Both references are linked in Research Sources.

Assign responsibility for information that remains outside the destination. The vendor explains conversion limitations, while the office decides how staff will retrieve historical evidence and continue excluded work. Record these decisions before approving the conversion.

Agree on an ownership model with the vendor. One approach transfers outstanding balances into the new system for ongoing collection. Another leaves older accounts in the legacy system while the new system handles activity after a defined cutoff. A split approach needs clear rules for accounts with activity in both systems.

Write down which system owns old claims, payments against those claims, patient credits, and new treatment. Identify which system generates statements for each balance. Sending statements from both systems without an account-level rule can produce two requests for the same amount or omit part of the balance.

Avoid maintaining two independently editable copies of the same receivable. If a supported workflow requires a reference entry in the other system, document its purpose and how reports exclude double counting. The manager should approve the model, and the billing team should demonstrate it using sample accounts.

Save source reports at the agreed cutoff with their names, filters, date and time, locations, and inclusion rules. Retain an account-level balance report as well as totals. A grand total is useful for comparison, but it cannot identify which account changed when a difference appears.

Include credits and separately reported payment-plan balances in the review. Confirm report definitions with both vendors so the comparison measures the same population. Do not add a payment-plan report to an account report unless those balances are excluded from the first report.

Open Dental's Post-Data Conversion Setup Checklist illustrates this issue: its balance comparison includes negative balances and may require a separate payment-plan report. It also notes that aging buckets and individual family-member balances can differ after conversion. Use the destination vendor's instructions for your actual reports, then investigate differences at the appropriate account level.

Ask for a test conversion and review a varied set of accounts. Include an uncomplicated account, an insurance balance, a patient credit, a partially paid claim, a family with several members, and a payment arrangement if the office uses them. For multiple locations, include records from each location and provider mapping.

Trace each sample from source to destination. Compare ownership, amounts, dates, transaction meaning, and access to supporting history. If a payment appears as a general credit instead of an allocation to a procedure, ask how staff should handle the next transaction before accepting the result.

Separate expected conversion behavior from defects. An explained display difference can be acceptable when the underlying balance and workflow remain correct. A missing credit, inaccessible claim reference, or payment assigned to the wrong account needs resolution. Log each exception with evidence, an owner, and a retest result.

Keep the test environment isolated from live claim transmission, statement delivery, and payment collection. Confirm the safe testing method with the vendor before exercising any workflow that could contact a payer or patient.

Suppose a fictional practice's source reports contain $84,000 in debit balances and $6,000 in credits. The net account balance is $78,000. The converted reports also show $78,000, so the headline total appears correct.

A closer review finds $82,000 in debits and $4,000 in credits. The net is still $78,000, but $2,000 of debit balances and $2,000 of credits are missing from the compared population. Report filters or conversion issues could explain the discrepancy; the matching net alone cannot establish accuracy.

Compare debit totals, credit totals, account counts, and account-level differences separately. Investigate whether an excluded account group, a mapping problem, or missing records caused the difference. Do not enter a balancing adjustment simply to make a summary report agree.

After resolving the cause, rerun the same comparison and retain the evidence. Any required adjustment should follow the practice's approval process and identify the affected account and reason. These figures are illustrative, not performance benchmarks.

Create a transition register for claims sent before the cutoff that remain unresolved. Link the legacy claim reference, destination account reference, latest known status, remaining work, and responsible staff member. Use approved internal identifiers rather than copying unnecessary patient details into a separate spreadsheet.

Distinguish reconstructing a claim record from transmitting a new claim. A destination system may require a record so staff can apply a later payment, but that does not mean the payer needs another submission. Follow the vendor's supported conversion workflow and verify transmission status before sending old work again.

For each item, decide where a later remittance will be posted and where follow-up notes belong. Preserve access to original submission evidence and correspondence. The related timely filing and documentation guides explain those routine workflows; the transition register ensures they remain reachable across the change.

Define when routine entry stops in the source system and begins in the destination. Ask the vendor whether activity after the final export can transfer through a supported update. If it cannot, use a controlled exception log and an approved re-entry procedure so the gap has a visible owner.

For each transaction during that window, record its source reference, actual event date, amount when relevant, destination, and completion status. Before re-entering anything, check whether it is already included in the final data. Otherwise, a payment recorded near the cutoff can be copied twice.

Name the person who decides whether the practice proceeds with launch or returns to its agreed contingency workflow. The vendor should explain how restoration would work and how activity created after launch would be preserved. A backup alone does not resolve newer transactions existing only in the destination.

List the connections the billing team uses: claim transmission, remittance delivery, payer portals, payment processing, and statements. Confirm which are ready in the new system and which remain active in the old environment. A completed database conversion does not establish the status of separate connections.

Assign one posting destination for each incoming payment stream, including payments for older treatment. Search the transaction reference before importing or entering a payment. Check that automation left in the legacy system will not also process the same activity.

Review the first statement batch before release. Confirm that opening balances, credits, and recent payments appear as expected and that the same balance is not selected for delivery elsewhere. Start with a manageable reviewed batch so errors can be corrected before reaching a larger group of patients.

Use this checklist as a sign-off record with evidence links. Mark an item ready only when the assigned reviewer can demonstrate the result. For unresolved issues, explicitly decide whether they block launch or can be handled through a documented temporary process.

During the first working week, review new transactions and migration exceptions daily. Look for unassigned payments, duplicates, missing history, failed transmissions, and statements that do not reflect approved balances. Compare reports using consistent definitions and keep old-account collections distinguishable from newly created activity.

Track unresolved migration issues, their age, affected accounts, and owners. Resolve causes instead of repeatedly correcting symptoms. If several accounts share a mapping defect, ask the vendor to assess the full affected population before treating it as an isolated entry error.

Close the transition when balance differences are explained, outstanding work has an active home, and staff can retrieve required history. Confirm the practice's record-access and retention requirements before ending any legacy arrangement. Keep the sign-off package so later balance questions can be traced to conversion decisions.