An Open Dental server migration moves the database and the image folder from an old machine to a new one, then reinstalls the program's services and repoints every workstation. The vendor publishes the steps and marks them for advanced IT users. For a Seattle practice, ClearMax technicians do this on site, with the old server held in reserve.
Last updated: November 2026
Which migration is this?
The word gets used for three different jobs, and searches for it mix them up. This page covers the first.
- Same program, new server. The hardware is replaced, and nothing changes for staff except the speed.
- Same program, moved to hosting. The vendor says practices can switch from its cloud to a local server or the other way. That choice is on the server vs cloud page.
- A different program altogether. A software conversion is a data project with the software vendor, and a different scope.
What gets checked weeks before the move?
The vendor lists required steps before beginning, and they decide whether the evening goes smoothly.
The database version
The same MariaDB or MySQL version has to be on the new server as on the old one. Installs after July 14, 2021 normally use MariaDB; older ones use MySQL. The vendor's trial installer offers MariaDB 10.5 and 10.11. A MySQL 5.6 system takes an extra step, installing 5.5 first and upgrading.
The storage engine
Some steps differ under InnoDB. The program's Diagnostics window shows the StorageEngine in its details. It takes a minute to read, and it changes what gets copied.
HL7
Practices using HL7 are told to contact the vendor's support to schedule the migration, so that date goes in the plan first.
What else the old server is doing
This is the check the vendor's page leaves to the practice. Old servers collect jobs: a scanner destination, a shared folder for the lab, an imaging program's database, a scheduled backup nobody remembers. Each one needs a new home or a decision to retire it. List the ones you know of with the project details, because a forgotten job is exactly what stops working on the morning after. If more work is needed, it is brought to the practice's attention and the bid is updated.
What about the records that must stay reachable?
Washington's dental rule, WAC 246-817-310, says a licensed dentist shall keep readily accessible patient records for at least six years from the date of the last treatment. That shapes two decisions. Old charts and images come across in full; a migration is not the moment to trim history to save drive space. And a retired machine in a closet does not meet "readily accessible", so the old server cannot be the plan for reaching older records. Anything stored outside the program, such as an old imaging archive, is listed and moved too, or the dentist decides in writing what happens to it.
How does the night of the move run?
Everything below follows the vendor's sequence; the running order is written for a practice that opens the next morning.
- Back up first. The image folder, the database and the my.ini file. For InnoDB, the entire data folder.
- Close the old server. Stop and disable the database, Open Dental Service, eConnector and API Service, so no workstation can keep using it. Rename its image folder, which stops the sharing, and disable port 3306 in its firewall.
- Prepare the new one. Run the trial installer as administrator and tick only the database server, the grant tables, my.ini and OpenDentImages. The program and the database are left unticked, because those come from the old server.
- Bring the data in. Stop the database service, put the copy into the data folder, usually c:\mysql\data, place the my.ini file, and start the service again.
- Share and merge the images. Share the new image folder with full access, then copy the old one into the same directory. Work can continue while that copy runs. A warning about more than three duplicate files means cancel and check the folder.
- Install the program from setup.exe inside the image folder, as administrator, and enter the new server name.
- Correct the settings. Check Data Paths, set the Update Server to the new name in Preferences, and open port 3306 on the new machine.
- Reinstall the services. The Open Dental Service, the eConnector and, where third-party integrations use it, the API Service.
The eConnector has conditions of its own. The vendor says it goes on one machine only, typically the server, and that machine must stay on and awake. It should also be set as the Update Server, and it is not compatible with Linux or Mac. Sleep settings on the new server get checked before anyone goes home.
What has to happen at each desk?
Each workstation runs the program as administrator and enters the new server name in Choose Database. If a computer opens charts but not images, look at the stored credentials for the new share, which the vendor says are usually saved the first time the computer opens the folder. A technician goes desk by desk with a checklist so that no computer is found pointing at the old name a week later:
- open a chart and today's schedule;
- open an older image and a recent one;
- take a test capture where a sensor is attached;
- print to the printers that desk uses;
- confirm reminders and online forms are moving, once the eConnector is up.
What does the morning after look like?
The first full day is when the leftovers appear, so someone stays reachable through it. The image merge may still be finishing on a large practice, which is why the old server is not touched yet. A first backup runs from the new server that night and is restored to another computer as proof. The vendor's own advice is to test backups by restoring them, and its Backup Tool should run from the server that hosts the database. The handover document then records the server name, the database version and storage engine, the services installed, where the backups go and when they were last proven.
What happens to the old machine afterwards?
It stays powered off and intact for a few weeks, in case something turns up missing. Then its drives are wiped or destroyed, because of what is on them. RCW 19.255.005 counts a name combined with someone's medical history, condition, diagnosis or treatment as personal information, so every drive that ever held charts is a covered item, including the old backup disks in the drawer.
Encryption matters most during that waiting period, with one catch. RCW 19.255.010 still requires disclosure of secured information when the encryption key or other means of deciphering it was acquired by an unauthorized person. A recovery key taped to the server, or saved in a text file on it, gives that protection away. The key goes somewhere else, and the record says where.
The clock is why the list matters. RCW 19.255.010 requires notice to affected consumers no more than thirty calendar days after a breach is discovered, and notice to the attorney general when more than five hundred Washington residents must be told. RCW 19.255.030 deems a covered entity under federal health privacy law compliant for protected health information if it complied with section 13402 of the federal HITECH Act, and ties its attorney general notice to that act's timing. A dental practice is normally that kind of covered entity, so its counsel should confirm which clock applies. A practice that knows exactly which drives existed, what was on them and when each was destroyed can answer a hard question quickly. One that has to reconstruct all that spends part of the practice's deadline on the search.
How long does it take, and when?
The database itself moves quickly on most systems. The image folder sets the pace, and years of radiographs take a while. That is why the old folder's size is one of the details asked for before the quote, and why most moves are booked for an evening or a weekend with a clear day of slack behind them. The office closes as normal, and it should open as normal.
Is the server moving because the practice is?
Then the two plans become one. The server moves as part of the new office setup, while cabling, cameras and door hardware are done by your licensed local contractor. If the replacement has not been chosen yet, the hardware requirements page comes first.
Practices planning a move also ask
Can the vendor do the migration?
The vendor publishes the steps and tells practices to contact its support when they need help or hit errors. HL7 practices schedule the move with its support. The hardware and the desks stay on the practice's side.
What if something fails halfway?
The old server still holds a complete copy. Reversing the old-server steps brings it back, which is why it stays untouched until the new one is proven.