Quoted 6 Months and $80K.
Done in 6 Weeks for $22K.
A 4-location Florida DSO needed to move off aging on-prem Dentrix servers to Dentrix Ascend. Their previous MSP said it would take half a year. Here is how it actually went.
Anonymization notice: This case study is anonymized and represents a composite of real migration engagements. Specific details — including the group name, exact Florida market, staff count, and cost figures — have been changed to protect client confidentiality. The technical sequence and outcomes reflect real projects.
Four Locations. One Problem.
The DSO operated four locations across two Florida metro areas, with 18 operatories total and a centralized billing team that worked remotely. Each location ran its own on-premises Dentrix server — four separate databases, four separate hardware maintenance schedules, and four sets of IT risk. The servers were between 4 and 7 years old.
The DSO's managing partner had reached a breaking point: patient data lived in four siloed databases, which made consolidated reporting nearly impossible. Referring back to patient history across locations required staff to make phone calls between offices. The remote billing team was connecting via VPN tunnels that routinely dropped during peak hours. One location had lost a server to hardware failure 14 months earlier and had been running on a borrowed workstation acting as a server since.
The appeal of Dentrix Ascend was straightforward: a single cloud-hosted patient record accessible from all locations, no more server hardware, and a centralized view for the billing team. The DSO's existing IT provider — a generalist MSP that had been managing their network infrastructure — quoted the migration at $80,000 and six months. The timeline alone was the problem. Six months of running parallel systems, staff retraining, and risk exposure was not acceptable.
The DSO's office manager found Siotek through a dental study club referral. We did a scoping call the same week.
Assess, Test, Roll, Optimize.
Phase 1: Assessment (Weeks 1–2)
Before writing a single line of migration documentation, we audited all four locations. That meant cataloging every workstation, understanding which imaging systems were in use at each location (two locations had Schick CDR sensors, one had a CBCT unit, one had Dexis), confirming Dentrix Ascend compatibility with each imaging integration, assessing internet bandwidth at each location, and documenting every third-party integration the practice used — ERA, clearinghouse, patient communication software, digital forms.
This phase also turned up two surprises. One location's CBCT software had a known compatibility issue with Dentrix Ascend's current release — it required a specific bridge configuration and a firmware update to the CBCT unit that could only be scheduled during a non-patient day. We built that into the timeline. One location had no fiber service available and was running on a cable connection that would be marginal for cloud-hosted software. We coordinated a bandwidth upgrade through the building's ISP before the cutover — a lead time issue that the 2-week assessment period absorbed cleanly.
Phase 2: Test Migration — One Location (Week 3)
We selected the smallest location — a 3-operatory satellite office — as the test site. A test migration does two things: it validates the data conversion before you commit, and it gives at least one staff member a real Dentrix Ascend experience before the rest of the group goes live.
Henry Schein's Dentrix Ascend migration process handles the actual data conversion, but the surrounding configuration is on the implementation partner. We stood up the Ascend environment, ran the test conversion over a weekend, and brought that location live on a Tuesday morning after a Monday afternoon staff walkthrough. The first week of live operation ran alongside the old server in read-only mode so the team could reference historical data during the learning curve. No issues required rollback. We declared the test phase successful at day seven.
Phase 3: Rolling Production Cutover (Weeks 4–6)
One location per week, Friday-to-Monday cutover windows. Each location ran the same playbook: Friday afternoon staff walkthrough, weekend data migration and environment configuration, Monday morning go-live with a Siotek engineer available by phone and remote desktop for the full first day. Imaging integrations were validated on Monday morning before the first patient.
The CBCT location required the scheduled firmware update and was moved to the last week to allow the maximum lead time for the equipment service appointment. That appointment happened the Thursday before cutover weekend, which gave us a buffer day to confirm the bridge was operating correctly before the Monday go-live.
Across all four cutovers, no location required more than 20 minutes of Siotek phone support on their go-live Monday morning. Total staff downtime across all four transitions: zero clinical hours.
Phase 4: Post-Migration Optimization (Week 7)
Once all four locations were live, we spent a week on the things that only become apparent after you are running in production: report templates the billing team needed rebuilt in Ascend's report builder, a scheduling template adjustment at one location, and cleanup of duplicate patient records that the data conversion had flagged for manual review. We also decommissioned all four physical servers and removed the VPN tunnel infrastructure the billing team had previously depended on.
Week by Week
| Week | Activity | Status |
|---|---|---|
| Weeks 1–2 | Infrastructure audit, imaging compatibility check, ISP upgrade coordination, migration plan sign-off | Assessment complete |
| Week 3 | Test migration — Location 1 (3 operatories, no CBCT). Staff walkthrough, go-live, 7-day parallel read-only period. | Live, no issues |
| Week 4 | Production cutover — Location 2 (5 operatories). ISP bandwidth upgrade confirmed pre-cutover. | Live, no issues |
| Week 5 | Production cutover — Location 3 (5 operatories, Dexis integration). | Live, no issues |
| Week 6 | Production cutover — Location 4 (5 operatories, CBCT). Firmware update Thursday. Go-live Monday. | Live, no issues |
| Week 7 | Report rebuilds, scheduling template tuning, duplicate patient cleanup, server decommission, VPN teardown. | Project closed |
What Changed
Beyond the cost and timeline improvements, the DSO gained something harder to quantify: the centralized patient record they had originally wanted. The billing team no longer works over VPN tunnels. The managing partner can run consolidated production and collections reports across all four locations from a single Ascend dashboard. Patients who visit multiple locations no longer require staff to call between offices to pull prior records.
The location that had been running on a borrowed workstation-as-server for 14 months had its hardware decommissioned on the week 6 weekend. That was, by the managing partner's assessment, "the best day of the whole project."
What a Generic MSP Misses
The six-month timeline from the previous provider was not dishonesty — it was a genuine reflection of the learning curve for a team that had never done a Dentrix-to-Ascend migration before. A generalist MSP approaching this project for the first time would need time to understand the Henry Schein migration process, discover the imaging compatibility matrix through trial and error, figure out which third-party integrations need reconfiguration, and determine what "done" looks like from a clinical workflow perspective.
We have done this before. We know which imaging systems require bridge reconfiguration. We know where the common data conversion issues show up and how to address them before they become Monday morning problems. We know which ERA and clearinghouse connections break during the cutover and how to restore them in under an hour. That accumulated experience is why the project took 6 weeks instead of 6 months — and why the quote was $22K instead of $80K.
The savings were not from working cheaper. They were from working without the exploratory overhead that a first-time migration always incurs.