The Dental PMS Migration Cutover Plan: Friday Night to Monday Morning

It is Wednesday. The conversion is booked for Friday at close, the new software is installed on a test workstation, and somebody on the team has asked the question you have been avoiding: if the x-rays do not open on Monday, what do we do?

You are ready for Monday when four things are written down and signed: a rehearsal (test conversion) that your own staff verified, a list of what will not convert and who will re-enter it, pass/fail smoke tests for the database, images, sensors, CBCT, workstations and permissions, and a rollback trigger with a deadline and one named person who decides. If any of the four is missing, you are hoping, not ready.

This page is the cutover and go-live part of a migration. If you are still choosing software or budgeting the project, start with our guide to dental software migration cost and timeline, and use the full dental software migration checklist for the months before cutover. What follows picks up roughly two weeks out and ends when the office has run normally for two weeks on the new system. It is organised in four parts: before migration, the rehearsal, the cutover weekend, and reopening.

The Friday-to-Monday Go-Live Runbook

A safe weekend cutover freezes the old system at an announced time, captures a final protected recovery point, lets the software vendor convert while IT rebuilds the environment, tests the highest-risk workflows on Sunday, makes a written go/no-go call before a rollback deadline, and opens Monday with named people on hand for the first hours.

The runbook below is the skeleton. Each block has an exit test: you do not start the next block until the current one has passed, or until the decision owner has accepted the risk in writing.

A common question is whether this all fits in one weekend. The final conversion often does. The preparation does not, which is why the first two blocks start a fortnight earlier.

Part 1 · Before migration

Two weeks before cutover: lock the command plan

Two weeks before cutover, stop discovering and start confirming. Every owner, date, vendor contact, test and rollback step should be written down by now. If a critical vendor cannot confirm that someone will be available during your window, move the date; a cutover with a missing vendor is a gamble on the weekend going perfectly.

By the final two weeks, the project should no longer be discovering architecture. Confirm owners, dates, contact methods, backup and rollback, vendor availability, test scripts and the impact on the patient schedule. Open Dental, for example, recommends "scheduling one to two weeks in advance of your desired conversion date", so if your vendor has not yet confirmed the final conversion slot, that is the first call to make.

Critical System Requirements for T-14 Days

The change freeze deserves its own line. A conversion is already the biggest change the office will make this year. Swapping phones, installing a new reminder service or replacing operatory computers in the same fortnight turns every Monday problem into a guessing game about which change caused it. Hold them until the new system has run cleanly for two weeks.

What will not convert, and what do you do about it?

Some data does not convert, and the vendors say so in writing. Open Dental's final conversion page states plainly: "Some data will be lost after a conversion." The fix is a table made before Friday: each item that will not move, how the office will rebuild or re-enter it, who does it and by when.

The details depend on the source and target system, so ask your vendor for its conversion document for your exact software. As one example, Open Dental's published conversion documents for Eaglesoft and Dentrix list items such as these:

Two habits make this table work. First, run the old system's accounts receivable report (including credit balances) and outstanding insurance claims report at the freeze, as Open Dental's final conversion page instructs, so you have totals to tie out on Sunday. Second, keep the old system available read-only for historical lookups; Open Dental's own instruction is "Do not enter new data in your old software; only use it for historical records."

Dr. Kenneth L. Hale, describing his own practice's conversion in Dentaltown Magazine (July 2019), put the cost of skipping this work bluntly: "Billing was interrupted for months, the hygiene recare system was exploded, patients were lost, and patient accounting became confusing." Most of that list maps to rows in the table above.

What Does Complete Dental IT Support Include?

A migration touches every area of practice IT, not just the database. Workstations, servers or cloud access, the network, the PMS itself, imaging devices, security settings, backups and access controls all change or need re-testing during cutover. A gap in any one of them shows up on Monday as a closed operatory.

The cards below map each area to what the cutover weekend actually changes and the test that proves it. Use them to check that someone owns every area before Thursday.

If you want to see how these areas fit into ongoing support outside a migration, our guide to what dental IT services include covers them in full.

Thursday: confirm readiness and stop change

Thursday is for verification, not experimentation. Confirm the target environment, credentials, licences, vendor access, the contact sheet and a current baseline backup. Freeze the project scope. Any "while we are here" change that is not required for the migration waits until after go-live.

Avoid unrelated updates or network changes that day; each one adds a suspect if something fails on Monday.

New "while we are here" changes belong after go-live unless they are required for the migration.

Part 2 · The rehearsal

How do you rehearse a dental software conversion?

Rehearse with a test conversion: the vendor converts a copy of your current data, and your own staff check it against the old system using the vendor's checklist. Time the extract and conversion, record every difference found, and repeat until the output is right. The final conversion follows the same path, so the rehearsal predicts the weekend.

Vendors put the verification on the practice. Open Dental's test conversion page says "Your office will thoroughly verify the test conversion data, using the Pre-Data Conversion Checklist as a guide," and that "This cycle will continue until you are satisfied with the output." It also warns that "The final conversion will be nearly identical to the test conversion, so make certain you are happy with the test." Its final conversion page repeats the point: "Each practice is responsible for checking the test conversion data."

That changes who should do the checking. An IT provider can prove the database opens and the bridges launch. Only the people who use the system every day can tell whether a family's balance, a hygiene recall or a treatment plan looks the way it should.

The rehearsal record

Fill this in during the test conversion. It becomes section A of the go/no-go packet.

Rehearse the weekend, not just the data

A test conversion checks the data. It does not check the people. Walk the cutover timeline as a tabletop exercise: the office manager, the IT contact and the vendor contact talk through Friday to Monday hour by hour, asking "what if this step fails?" at each one. NIST's contingency planning guide (SP 800-34 Rev. 1) separates tabletop exercises, which are discussion-based, from functional exercises, which run real steps on real systems; a dental cutover benefits from both. The tabletop finds gaps in the plan. The test conversion and a dry run of the smoke tests find gaps in the systems.

If the rehearsal shows the conversion takes most of Saturday, or that historical images will not arrive until days later, you have learned it on a Tuesday instead of a Sunday night. Adjust the schedule, warn the clinical team, or move the date.

Part 3 · The cutover weekend

Friday: freeze data and capture the last authoritative source state

At the announced freeze time, stop normal data entry in the old system, follow the downtime process, run the final reports, take the final protected recovery point and record exactly what business time it represents. From that moment, every manual patient or payment change is written down until the new system is authoritative.

What a "protected recovery point" means for common systems

The final backup must contain both the database and the images, because a rollback that restores one without the other does not work. Software vendors publish where these live. For Open Dental, the manual names the database folder (\\SERVER\mysql\data\) and the images folder (\\SERVER\OpenDentImages\, A to Z) and recommends testing backups "by restoring them to a workstation not connected to the office network". For Dentrix, Henry Schein One's migration tool guide asks for "a complete and verified data backup" before server changes and describes copying "the entire Common folder, including all subfolders and files."

The Dentrix guide also contains the sentence every rollback plan should quote: "Restoring from a backup will erase any data entered after the last export." That is why the freeze matters. Anything entered after the freeze is either in the new system or on the paper log, and a rollback means re-entering it in the old one.

Our backup checklist for dental software migrations covers the backup side in more detail, including why a database export is not the same as a backup.

Friday night / Saturday: perform conversion and technical reconnection

Friday night and Saturday are two parallel jobs. The PMS vendor converts the data and handles product-specific setup. Your IT provider rebuilds the environment: server or cloud access, workstations, network, accounts, backups, imaging bridges and integrations. Both jobs write into one shared issue log so nothing is fixed twice or missed.

The PMS vendor should run product-specific conversion and application tasks. IT should execute the environment work. Track issues in one command log with a time, a description, an owner and a status for each line.

Cutover workstreams and owners

One coordinator instead of a phone tree

The friction on cutover weekends usually comes from the handoffs between vendors. PMS and imaging companies support their own products, so when a bridge fails, each vendor can reasonably say the fault sits on the other side, or in the network.

Agree in writing before Friday who that coordinator is and what they are responsible for. If your IT agreement does not say whether vendor coordination during a conversion is included, ask, and get the answer in the project plan.

The responsibility table

Fill in names, not company titles, in your own copy. A table full of company names is how everyone ends up assuming someone else had it.

How do you smoke-test sensors, pano and CBCT after a conversion?

Test each imaging device on the workstation where it is actually used, not just in the viewer. For every intraoral sensor, pano and CBCT unit, open a test record from the new PMS, launch imaging through the bridge, capture an image, and confirm it files to the correct chart and opens again from a second workstation.

Opening an old x-ray proves that the viewer can read the archive. It does not prove that a sensor plugged into operatory three will capture into the right chart on Monday at 8:00. Those are different tests, and Monday needs both.

Device smoke-test sheet (one row per device)

Five checks deserve attention:

1. 1. Patient match. For the patients you spot-checked in the rehearsal, open their images from the new PMS. The image must belong to the same patient. If your imaging is DEXIS, ask the conversion team whether a patient ID renumbering is required; Open Dental's Dexis page says its "Conversions Department can determine if a Dexis patient ID renumbering will be required".
2. 1. Capture station, not viewer. CBCT and pano capture usually run on a dedicated workstation with their own software and storage. Test capture there.
3. 1. Historical images. Confirm whether they arrive with the data or after a separate image conversion. Open Dental notes that historical scans are not visible "until after the image conversion is fully complete." Tell the clinical team in advance.
4. 1. New-image location. Check that new captures are saved to the storage location that is backed up.
5. 1. Every room. Sensors fail one operatory at a time. A test in operatory one says nothing about operatory four.

Common systems in this test include DEXIS, Carestream, Vatech, Planmeca Romexis and Dolphin Imaging, bridged into Dentrix, Eaglesoft, Open Dental or Archy. When a device passes on Sunday and fails on Monday, our guide to dental imaging integration troubleshooting walks through how to find the broken link.

Sunday: validate real practice workflows

Sunday's tests should be run by the people who do the work: the front desk, an assistant or hygienist and the billing lead. Each one follows a short script on representative patients and records pass or fail. An administrator clicking through dashboards proves the software installed; staff running their own day proves the office can open.

Choose the representative patients before Sunday, and give each tester a printed script with a pass/fail column.

A sample non-patient workflow

Run one complete visit end to end on a test record that is clearly not a real patient (for example, "TEST, Cutover"). Create the record, add insurance, book an appointment, check in, open imaging through the bridge and capture one image, chart a procedure, write a note, create a treatment plan, post a charge and a payment, generate a claim (use the clearinghouse test mode if it offers one), print a walkout statement, then check out. Finally, inactivate or archive the test record as your software allows. If one person can carry a test record through the whole day without help, Monday is much less likely to surprise you.

The go/no-go packet

The go/no-go packet is the signed record that the practice is ready to reopen on the new system. It lists every check, its pass standard, the evidence and the person who ran it, then names who decides, the rollback deadline, what triggers a rollback and who carries it out. Print it, fill it in on Sunday, and keep it.

Nothing in the packet is new work. It collects the rehearsal record, the smoke tests and the Sunday scripts into one place so the decision is made on evidence at a known time rather than by exhaustion late on Sunday night.

Decision: GO / NO-GO · Time: ______ · Signed: ______ (decision owner) · Witnessed: ______

A packet with an empty owner column is a warning in itself. If nobody will sign for a row, nobody has checked it.

The Rollback Threshold Assessment

Roll back when a critical workflow, data set or integration cannot be made reliable before the rollback deadline you set in advance. The triggers, the deadline and the person who decides must be written down before Friday. On Sunday night the decision should be a reading of the packet, not a debate.

Before you write the trigger list, settle four questions

1. 1. Who decides? One person, usually the practice owner, with advice from the office manager, IT and the vendors. Advisers do not hold a veto.
2. 1. By when? A clock time on Sunday that leaves enough time to restore the old environment and reopen on it Monday. Your IT provider should tell you, from the rehearsal, how long that restore takes.
3. 1. Back to what? The old system restored from Friday's recovery point. Remember that a restore erases anything entered after that point; the paper log covers the gap.
4. 1. What about a hosted system? If you are moving into or out of a cloud PMS, ask the vendor in writing how a rollback works, whether you can export again, and how long the old system stays available. Do not assume you can go back if the contract does not say so.

There is also a middle option: go live with a known, contained problem and a workaround, such as one sensor that will be replaced Tuesday. The decision owner can accept that in writing. What should not happen is a quiet go-live with an unknown problem.

Part 4 · Reopening

Monday morning: how do you reopen after a PMS conversion?

Open early with support on site or on the line, one person collecting every issue, and a lighter first schedule if you can. Start with the patients you tested, watch the first check-ins and the first image captures, fix problems in order of how many chairs they stop, and review the issue list at lunch and at close.

• • Arrive early. Staff log in and open their usual screens before the first patient. Problems found at 7:15 are cheaper than problems found at 8:05.
• • One issue log. Everyone reports to the same person, who records it, triages it and passes it to the right vendor.
• • Triage by impact. An operatory that cannot capture images comes before a report that looks odd.
• • Floor support. A trainer or experienced user on the floor for day one and day two. Open Dental asks practices to schedule a Post Conversion Setup with an Open Dental trainer; other vendors offer go-live training in their own way, so ask what yours provides.
• • Paper ready. Keep Friday's printed schedule and downtime forms in reach until the end of the day.
• • Lunch and close reviews. Fifteen minutes: what broke, what is fixed, what is open, who owns it.

Monday hypercare roster

What happens in the first two weeks after go-live?

The first two weeks are stabilisation. Tie out balances daily, finish re-entering unconverted claims and treatment plans, close training gaps, keep the old system read-only for lookups and keep the change freeze. At the end of week two, review the issue log and set a date to retire the old system safely.

Expect some friction. A new system changes muscle memory, and some of the first weeks' problems will be training rather than technology. Write each one down anyway; the pattern tells you where to retrain.

When it is time to retire the old server or cancel the old subscription, do it as its own small project. Our guide to the Dentrix server migration checklist covers server moves, and the dental backup and disaster recovery checklist helps you set the ongoing backup routine for the new system.

Dental IT Support vs General IT Support

Any capable IT provider can move a database and install software. A conversion weekend also needs someone who knows how dental imaging bridges, sensors and capture workstations connect to the PMS, and who has dealt with the PMS and imaging vendors before. Ask any provider, dental or general, to show that experience on your systems.

The practical test is simple: ask the provider to describe, step by step, how they would test a DEXIS or Carestream bridge after a conversion to your new PMS, and what they would do if images filed to the wrong patient. A specific answer is worth more than a label. Our comparison of dental IT support and general IT support goes through the differences in detail.

• Read more:The complete guide to dental IT support

What to ask your IT provider before cutover weekend

Ask these before you sign off the plan, and write the answers into the packet.

1. 1. Who is our coordinator for the weekend, and how do we reach them Friday night, Saturday, Sunday and Monday morning?
2. 1. Is coordination with the PMS and imaging vendors during the conversion part of our agreement, or a separate project? What does it cost?
3. 1. When did you last restore our backup, and how long would it take to restore the old system if we roll back Sunday night?
4. 1. Will the final recovery point include both the database and every image folder? Where will it be stored?
5. 1. Which workstations will you test, and will you test every operatory or a sample?
6. 1. How will you test each sensor, the pano and the CBCT capture workstation?
7. 1. Do our imaging patient IDs need to be renumbered after the conversion, and who will check?
8. 1. Will historical images arrive with the data or after a separate image conversion? When?
9. 1. When will the new database and image folders be added to the backup, and when will you prove a restore?
10. 1. How will user accounts and permissions be set up, and when will old accounts be disabled?
11. 1. What time is the rollback deadline, who decides, and who carries out the rollback?
12. 1. Who will be available on Monday morning, from what time, and how do staff report problems?
13. 1. What changes are you holding until after go-live, and when will you reschedule them?
14. 1. When and how will the old server be retired, and what happens to the data on it?

If your provider supports your platform already, it will have a page describing that work. Legend's pages cover Open Dental IT support, Dentrix IT support, Eaglesoft IT support, Archy IT support and DEXIS imaging IT support.

What Does Dental IT Support Cost in 2026?

Ongoing dental IT support and a one-off migration project are usually priced separately, so ask for both in writing. Legend's published price is: Starting at $360 per month. Hardware procurement, major cabling projects and software licensing are quoted separately. Ask any provider how conversion-weekend work is billed.

For Legend, the published figures are:

The migration project itself, and what the PMS quote usually leaves out, is covered in our guide to dental software migration cost and timeline. For a line-by-line way to compare ongoing support quotes, see what dental IT support costs and why quotes differ.

Who wrote this and what Legend does

This guide comes from Legend Networking's dental IT team. Ian Lynch has 22 years in dental IT and oversees the NOC, onsite dispatch and client technology roadmaps. Legend has served over 3,500 practices since 2004, is rated 4.8 from 173 Google reviews, and works with in-house engineers; no outsourced first-level triage. Legend supports the IT environment around Dentrix, Eaglesoft, Open Dental and Archy, and around DEXIS, Vatech, Carestream, Planmeca/Romexis and Dolphin Imaging. The helpdesk is staffed 24/7 at 1-800-794-1588, with 24/7 monitoring, and onsite dispatch is by appointment across served dental markets.

Related guides

• • Dental software migration cost and timeline: the budget and phases around the cutover.
• • The full dental software migration checklist: the months of preparation before this page begins.
• • What to back up before a dental software migration: recovery points for the database, images and documents.
• • Dentrix server migration checklist: moving servers without breaking DEXIS, workstations or backups.
• • Dental imaging integration troubleshooting: when the sensor stops talking to the chart.