Dentrix 2026 Upgrade Checklist for Dental Practices

No. Dentrix used G-series names through G7.9, then changed its version naming to a year-and-release format. Dentrix Magazine explained that the release following G7.9 was Dentrix 22.5 and that subsequent feature releases would continue using the year plus release number.

That distinction matters because searches for a “G8 migration” may lead practices to outdated assumptions, unofficial articles, or requirements for the wrong build. Open Office Manager, select Help, and review About Dentrix to record the complete installed version before planning any upgrade.

Obtain the exact target version and current requirements from Dentrix or your authorized support channel. The target may differ based on entitlement, staged rollout, hosted environment, server project, or vendor recommendation. Your project plan should use the actual version, not a marketing shorthand.

Document the server name, operating system, hardware, storage, Dentrix version, database location, Common folder, database passphrase, workstation count, Windows versions, user roles, printers, scanners, signature devices, imaging systems, bridges, claims services, e-prescribing, patient communications, payments, and remote-access tools.

Identify every vendor that may need to participate. Dentrix support may handle application-specific installation and database tasks, while your IT provider manages Windows, server hardware, networking, security, backups, permissions, and workstation readiness. Imaging and integration vendors may need to validate bridges or reinstall components.

Record current problems before the change. Slow workstations, database errors, failed backups, missing space, broken integrations, unsupported Windows versions, or intermittent network issues should not be hidden inside the upgrade. Decide which conditions must be corrected first and which will be tested after the new version is stable.

Compare every server and workstation against the latest Dentrix system requirements for the target release. Review supported Windows editions, processors, memory, storage, display requirements, network components, prerequisites, and any restrictions for domain controllers, virtual machines, remote sessions, or imaging integrations.

Install outstanding Windows updates in a controlled maintenance window before the Dentrix project, as the official Installation and Migration Tool prerequisites require. Restart systems, confirm update completion, and resolve driver or hardware failures rather than stacking several uncertain changes into the migration window.

Check free storage and health on the server and workstations. Database migration, backups, temporary installation files, Windows servicing, logs, and rollback copies need space. Review storage performance and hardware age; an application upgrade cannot compensate for failing drives, insufficient memory, overheating, or an undersized server.

Create a current Dentrix database export and protect the complete Common folder, including required subfolders and files. Dentrix documentation explains that database activity pauses during export and that the Common folder contains the components needed for restoration. Coordinate timing so the backup product copies a completed export rather than an inconsistent live state.

Protect related systems separately. Imaging databases and files, scanned documents outside Dentrix, file shares, configuration, templates, and third-party applications may not be included in the Dentrix database backup. Build a recovery inventory that identifies each source and owner.

Verify—not assume—the backup. Confirm job completion, file access, timestamps, off-site or protected retention, available credentials, and a recent restore test. Document the recovery point and rollback process. A project should not begin when the only recovery plan is to call several vendors and hope their portals contain enough data.

Dentrix’s current Installation and Migration Tool can support server migration, restoration from backup, server or workstation reinstallation, new installation, and redirecting workstations to another server. The official prerequisite list includes Dentrix 17.9.26.0 or newer, current system requirements, a protected backup, outstanding Windows updates, and the database passphrase.

If the office uses a third-party firewall, Dentrix lists UDP 9000 and TCP 9001 and 9002 for the tool. Do not open ports broadly without understanding the required source, destination, scope, and duration. Coordinate firewall changes with the IT provider and remove temporary rules that are no longer needed.

Both servers must be available on the same network for the documented server-to-server migration workflow. The guide notes that migration time depends on data volume and gives a typical two-to-three-hour estimate for many practices, including Document Center files. Treat that as vendor guidance, not a guaranteed maintenance window; add time for preparation and testing.

Build an integration matrix with vendor, version, workstation or server location, connection method, support contact, license information, and test steps. Include imaging bridges, sensors, scanners, e-prescribing, claims, eligibility, payments, patient communications, forms, reporting, accounting exports, and any custom utilities.

Ask vendors to confirm compatibility with the exact target Dentrix and Windows versions. An integration may require an updated bridge, service, driver, certificate, browser component, or workstation reinstall. Schedule vendor participation before the cutover rather than opening urgent tickets after the office discovers a missing workflow.

Use a representative non-production or test patient where permitted. Verify launch behavior, patient matching, image acquisition and retrieval, document filing, printing, scanning, claims, payments, and communication jobs. Record expected results so testing does not become a quick visual check.

Choose a window that protects the next clinical day. Avoid starting during lunch, immediately before a full schedule, just before a holiday, or when key vendors are unavailable. Allow time for final backup, installation, workstation updates, integration repair, user validation, rollback, and unexpected hardware or Windows issues.

Communicate the freeze point. Staff should know when to stop entering data, close Dentrix, complete outstanding transactions, and avoid reconnecting until released. During server migration, prevent workstations from writing to the old environment after the authoritative database moves.

Assign decision authority. One person should approve start, rollback, and production release based on agreed criteria. Keep Dentrix, IT, imaging, and integration contacts available, along with account numbers, support entitlements, credentials, and escalation paths.

Confirm the server service, database version, workstations, user authentication, permissions, Appointment Book, Ledger, clinical chart, treatment plans, insurance, claims, reports, documents, printers, scanners, signature devices, and application performance. Check several operatories and front-desk stations rather than testing only the server.

Validate every integration in the matrix. Open representative patients, acquire and retrieve images, launch connected applications, send a test workflow where appropriate, and check background services. Review Windows Event Viewer, application logs, endpoint alerts, firewall logs, and vendor errors for problems that may not be visible to users.

Run and verify the first post-upgrade backup. Confirm the database export schedule, backup paths, permissions, retention, and monitoring still work. Update documentation with the new version, server details, workstation status, changed ports, vendor notes, and known issues.

Common mistakes include using outdated requirements, skipping Windows updates, treating a successful backup job as a tested restore, forgetting the database passphrase, underestimating Document Center volume, ignoring imaging and bridges, and scheduling too little downtime.

Practices also create risk by changing the server, Windows version, Dentrix version, network, security software, imaging environment, and remote-access method at once without staged testing. Some projects require several coordinated changes, but each dependency should be understood and a rollback boundary defined.

Another mistake is releasing the system after one login succeeds. Production readiness means representative users can complete critical workflows and the practice can back up the new state. Keep the next day’s schedule lighter when feasible and arrange elevated support during the first operating hours.

Before: exact current and target versions, current system requirements, supported Windows, healthy hardware, storage capacity, completed updates, database passphrase, verified backups, integration matrix, vendor confirmations, downtime notice, and rollback criteria.

During: final data freeze, current export, protected backup, controlled installation or migration, workstation updates, documented firewall changes, integration configuration, issue log, and a clear authoritative server and database.

After: workflow validation, imaging and vendor tests, permissions review, performance checks, first successful backup, monitoring review, documentation update, staff communication, and scheduled follow-up. Keep the project open until the practice completes a stable clinical cycle.