Dentrix Server Migration Checklist: Beat the Windows Server 2016 End-of-Life (Jan 2027)

If your Dentrix server is running Windows Server 2016, it has an expiration date: January 12, 2027. That's the day Microsoft ends extended support for Server 2016. The server won't stop booting on January 13. What stops is the security patches, and that's where the trouble starts.

An unpatched server holding patient records is a problem your HIPAA risk analysis can't wave away. Cyber insurance applications ask about end-of-life operating systems by name. And Henry Schein One has moved on: current Dentrix releases are built and supported for newer Windows Server versions, and Windows 10 has dropped off the supported list for workstations, which means a server move now tends to drag a round of workstation upgrades along with it.

So if your practice is on Server 2016, a Dentrix server migration is already on your calendar whether you've scheduled it or not. The only real choice is whether it happens on a planned evening with a tested backup, or as an emergency when the old hardware finally quits on a Tuesday.

This is the checklist version of how the migration actually runs when it's done in the right order. Hand it to whoever is doing yours and make them walk you through every line. This checklist is the migration companion to our full Dentrix IT support guide, which covers performance problems, database errors, and day-to-day troubleshooting.

What the Deadline Actually Means for a Dental Practice

• No more security patches after January 12, 2027. Microsoft sells Extended Security Updates for Server 2016, but it's a short, per-core-priced bridge: schedule insurance, not a strategy. It does nothing for 9-year-old hardware.
• Your hardware is the real deadline. A server purchased for Server 2016 is typically 8–10 years old now. Disks, RAID batteries, and power supplies fail on their own schedule, and they don't check yours first.
• Dentrix support follows Microsoft's platforms. Running a current Dentrix version on an unsupported OS means that when something breaks, "your server OS is end-of-life" is where the support conversation starts and ends.
• Workstations are part of this project. If your operatories are still on Windows 10, budget for those upgrades in the same window. A new server with unsupported workstations is a half-finished migration.

Step 1: Inventory Everything Before You Touch Anything (2–3 Weeks Out)

Most migration problems are inventory problems discovered too late. Before anyone quotes you a cutover date, every one of these should be written down:

• Current server specs: OS build, CPU, RAM, storage used vs. free, RAID health. If the RAID has been quietly degraded for a year, you want to know now.
• Exact Dentrix version and build number. Screenshot it from the old server. The new server gets the same version first. Version upgrades are a separate step (more on that below).
• Every Dentrix data location: the database directory, the Document Center archive, letter and form templates. The database is the easy part. It's the folder somebody pointed to a custom path in 2019 that gets left behind.
• Imaging platform and image location: DEXIS, Apteryx, Carestream, Schick: which one, which version, what bridge type, and where the images physically live. Server? NAS? An operatory PC? It happens more often than you'd think, and nobody remembers until the images don't open.
• Sensors and acquisition devices: every intraoral sensor by operatory, intraoral cameras, and the panoramic/CBCT acquisition workstation.
• Peripherals: label printer, receipt printer, document scanner, signature pads, payment terminals.
• Third-party integrations: eClaims and your clearinghouse connection, Dentrix eServices, patient communication platform (reminders/recalls), online scheduling, payment processing.
• Network facts: server name, static IP, share names, mapped drive letters, printer shares.
• Licensing and access: Windows Server license and CALs, Dentrix licensing, imaging licenses (some are tied to hardware IDs), server admin credentials, Dentrix admin credentials, vendor support numbers.

If a line on this list comes back blank, that's the line that will bite you on the first morning after the migration. Fill it in now, while the old server is still running and you can go look.

Step 2: Prove the Backup Before Anything Moves

A backup job that reports "completed" proves a job ran. It does not prove your data opens.

Before a cutover date is even set:

• Take a full backup of everything on the inventory: database, image store, document archive, templates. A backup that captures the SQL database but skips the imaging folder is the most common incomplete backup we find, and imaging is usually the largest share of a practice's data.
• Restore it somewhere. Onto the new server or a test machine. Restore the whole thing, open Dentrix, open real charts, and open images from two or three years ago, not just last week. Archived images live in different folders and fail differently.
• Measure the image store. Imaging archives in the hundreds of gigabytes are normal. A copy or restore you mentally budgeted an hour for can run all night if nobody checked the size first.
• Keep a second copy off the server (external drive or cloud) before cutover starts. The old server is not its own backup.
• If the restore test fails, stop. Fix the backup first, then reschedule. Migrating on top of an unproven backup is how a planned server upgrade turns into a data-recovery job.

For what a complete dental backup has to capture, and how restore testing actually works, see our dental data backup and recovery guide.

Step 3: Stage the New Server While the Old One Still Runs

The cutover night should be a final sync, not a first attempt. Everything that can be built and tested ahead of time, is:

• Build the new server on Windows Server 2022, fully patched, with antivirus exclusions set for the Dentrix data and imaging directories. Real-time AV scanning of a live database is a performance problem at best.
• Install the same Dentrix version as the old server and restore the test copy from Step 2 onto it. Confirm Dentrix opens with your data before cutover is scheduled.
• Recreate shares with identical names and permissions. Every workstation, bridge, and integration that points at \\SERVER\DentrixData should find the same path on the new box.
• Pre-seed the big, static data. Copy the imaging archive and document folders across during the week. They barely change day to day, so on cutover night only the final delta has to move.
• Decide the naming question now. Either the new server takes the old server's name and IP address at cutover (workstations mostly never notice), or it gets a new name and every workstation gets remapped. Both work. Pick one, write it into the plan, and don't improvise it at 9 p.m.
• Check hardware-tied licenses. Some imaging and third-party licenses key off hardware IDs and need a transfer or re-activation on the new server. Find out during business hours, not during the cutover.

Step 4: Cutover Night, In Order

Schedule it after hours, most practices use a Friday evening so Saturday is a buffer if anything runs long. Agree on a go/no-go time before you start: if verification isn't clean by that hour, you roll back while rolling back is still easy (Step 7).

1. Last patient out. Everyone logs out of Dentrix, everywhere. That includes the doctor checking the schedule from home and the office manager's remote session. One open remote connection can hold the database open and stall the whole night.
2. Stop the Dentrix services on the old server so nothing else can write to it.
3. Run the final backup, then the final data sync: the database, plus any image and document changes since the pre-seed.
4. Sanity-check the new server before touching a workstation: open Dentrix, confirm tomorrow's schedule is there, open a handful of charts across different providers, check an account balance or two against the old server's numbers.
5. Make the swap: the name/IP change, or the start of workstation remapping, per the decision in Step 3.
6. Take the old server out of circulation. Dentrix services stay off. Leave a note on it, an actual note, taped to the monitor: "OLD SERVER: DO NOT USE." Monday-morning habits are strong, and you do not want anyone charting into the old box.

Step 5: Reconnect Imaging and Sensors

This is the step generic IT providers skip, and it's where dental migrations actually fail.

The classic morning-after scenario: patient records open fine, the schedule is fine, and every X-ray errors out, because the imaging bridge on each workstation still points at the old server's image path. Dentrix migrated. The images didn't.

• Update the imaging bridge/image path on every workstation, not just the one you tested at the front desk.
• Take a test image with every sensor in every operatory. Sensor drivers live on the workstations, so most survive a server swap untouched. The one that doesn't will otherwise introduce itself at 8:05 a.m. with a patient in the chair.
• Verify the panoramic/CBCT acquisition PC separately: take an image, confirm it saves to the new location, and confirm Dentrix pulls it up from the chart.
• Open archived images, not just recent ones. Archive volumes sometimes sit on a different path than current images, and a path fix that heals this month's X-rays can leave three years of history dark.

Step 6: Cut Over Workstations in This Order

Don't do them alphabetically or by whoever's standing closest. Order matters because each stage catches a different class of problem:

1. The server itself: Dentrix already verified there in Step 4; this is your reference point for "working."
2. One operatory workstation: the full test: staff login, open a chart, load images, fire the sensor.
3. Front desk: schedule, check-in view, printing, payment terminal. Front desk finds problems faster than anyone, and the morning runs through them.
4. Remaining operatories.
5. Doctor's office and back office machines: least time-critical if something needs a second look.

On every workstation, the test is the same: a staff member logs in with their own credentials (not the admin account, you need to know their permissions work), opens a real chart, opens images, prints one page to the correct printer, and checks the scanner and signature pad where fitted.

Step 7: Write the Rollback Plan Before You Need It

A rollback plan written at 7 a.m. under pressure is not a plan. Write it before cutover night, while everyone is calm:

• The old server stays intact. Nothing gets wiped, repurposed, or "cleaned up." The entire sequence above is designed so the old box remains a complete, working copy of the practice as of Friday's close.
• Rollback is a reconnection, not a restore. Point workstations back at the old server (or reverse the name/IP swap), staff work the day on the old system, and the migration gets rescheduled with a diagnosis instead of a deadline panic.
• Know the point of no return. Once patients are being charted on the new server, rolling back stops being simple: that new charting exists only on the new box and would have to be reconciled by hand. This is why verification happens the night before and again early the next morning, not at 8:15 with a full waiting room.
• Keep the old server standing by for 30 days after a successful cutover before decommissioning it. Storage is cheap; regret is expensive.

Step 8: Verify Everything the First Morning, and the First Night

Cutover night ends when these are checked, not when the data finishes copying:

Then do a one-week check-in. The complaints that surface in week one are usually one workstation with a stale path or a dying drive, not the server. Catch them while they're small.

How Long Does a Dentrix Server Migration Actually Take?

Honest answer: the data decides.

For a typical single-location practice with the staging and pre-seeding done ahead of time, the cutover itself is an evening's work, and the goal is zero patient hours lost: work happens after close, verification before open. What stretches the timeline is almost never Dentrix. It's volume: imaging archives in the hundreds of gigabytes don't move in an hour, which is exactly why they move the week before.

What turns an evening into a weekend:

• A multi-terabyte imaging archive nobody measured
• A Dentrix version upgrade attempted in the same night (see below)
• Workstations still on Windows 10 that turn out to need replacing mid-project
• A backup that fails its restore test the week before, which is the system working as intended, but it moves the date

And the part nobody budgets for: the risk window isn't the evening, it's the first two hours of the next morning. Whoever ran the migration should be covering that first morning (on-site or remote) when the first patients check in.

Should You Upgrade Your Dentrix Version During the Migration?

Almost never in the same night. Migrate version-for-version, let the practice run stable on the new server, then schedule the Dentrix upgrade as its own step. When two big changes land at once and something misbehaves Monday, you've doubled the list of suspects.

When a Practice Shouldn't DIY This

Plenty of office managers are technical, and plenty of general IT folks know Windows Server cold. Neither is the gap. The gap is knowing which of the moving parts is dental. Don't DIY if any of these are true:

• Your backups have never been test-restored. Then you don't have a backup: you have a hope and a green checkmark.
• Your Dentrix version is several releases behind. Big version jumps can require intermediate steps and vendor involvement mid-upgrade.
• Nobody can say exactly where the images live. See Step 1. This gets discovered eventually; the only question is when.
• The practice can't absorb a rough morning. If your schedule is wall-to-wall surgeries, your margin for improvisation is zero.
• The migration would be your IT person's first Dentrix migration. Windows skills transfer. Knowing that the backup job needs repointing, that the bridge paths live on each workstation, that one open remote session can freeze the night: that's Dentrix-specific, and it's learned by doing migrations, preferably someone else's first, not yours.

A failed DIY migration doesn't save the cost of hiring help. It converts a planned evening project into emergency recovery at emergency rates, with patients sitting in the middle of it.

How FlossByte Runs a Dentrix Server Migration

For Bay Area practices that would rather hand this off, this checklist is the process we work from:

• Assessment and inventory first. The Step 1 inventory, done with your team, before any date is proposed.
• Restore test before scheduling. Your backup gets restored and opened before a cutover date goes on the calendar, not the night of.
• Staged build and pre-seeding. The new server is built, loaded, and synced during the week so cutover night is a final delta, not a marathon.
• After-hours cutover with a written rollback plan. The work happens after close, so the practice loses zero patient hours: you close on the old server and open on the new one. The old server stays untouched and on standby for 30 days after the move.
• First-morning verification. Logins, imaging, claims, printing, and that night's backup job, checked with your team, not assumed. We cover that first morning on-site or remotely, with the person who ran the cutover.

For a typical single-location practice, the cutover itself runs about 3–5 hours on the night. The heavy lifting (staging, pre-seeding the imaging archive) happens during the week before, so the evening is a final sync and verification, not a marathon.

Frequently Asked Questions