juno.dental / migration

Your data, on Juno, in fourteen days.

Native connectors for Open Dental, Dentrix, SoftDent, Eaglesoft, and CareStack. Schema-mapped extraction, four-stage validation, lossless transfer. Free for design partners. This page covers the technical specifics.

Timeline 14 days standard · 7 days fast-track
Cost Free for design partners
Data fidelity 100% on canonical entities · field-level audit
Downtime 2-hour window · cutover after-hours
Architecture

Five sources. One canonical model. Zero loss.

Each source PMS gets a dedicated adapter that reads from its native datastore — direct ODBC for SQL Anywhere systems (Eaglesoft, SoftDent), MySQL replication for Open Dental, REST for CareStack, and JET/Access exports for Dentrix. All five normalize through Juno's canonical schema before landing in your tenant. Same internal model regardless of where you came from.

Source PMS
Open Dental
Dentrix
SoftDent
Eaglesoft
CareStack
Adapter layer
Schema reader
Field mapper
Validator (4 rules)
PHI redactor (logs)
Diff reporter
Juno canonical
Tenant juno. Postgres + RLS
HIPAA-ready · audit log
Live in 14 days · 100% fidelity
Adapter isolation
Each adapter runs in its own sandboxed worker. A failure in the Dentrix reader doesn't touch Eaglesoft data. We've moved 1.4M+ records through this pipeline in internal testing.
Four-layer validation
Every record passes type checks, referential integrity, business-rule sanity, and statistical anomaly detection before it lands in your tenant. Field-level diff report on every batch.
Reversible cutover
Day 14's cutover is a 2-hour window run after-hours. Read-only mirror keeps your old system intact for 90 days post-migration. Roll back at any point during that window if something feels wrong.
The 14-day plan

Four stages. One go-live.

Standard migration runs over 14 calendar days from kickoff to cutover. Fast-track in 7 days available for practices already running Postgres-friendly stacks (Open Dental and CareStack). Every stage has named deliverables and a sign-off gate before the next begins.

Day 1–3 · Discovery

Snapshot & map.

Read-only snapshot of your current PMS database. We profile entity counts, custom fields, and any non-standard schema modifications. You receive a field-level mapping report to review.

  • Read-only DB snapshot
  • Custom field inventory
  • Per-entity record counts
  • Mapping report sign-off
Day 4–7 · Dry run

Mirror to staging.

Full migration run into a staging tenant. You log in, validate sample patient charts, treatment histories, ledger balances. We run the diff report against your live system and surface any mismatches.

  • Full staging migration
  • Diff report (field-level)
  • Sample chart validation
  • Ledger balance reconciliation
Day 8–13 · Reconcile

Fix what's off.

Address custom-field nuances, edge cases your team flagged, and any payer-specific quirks. Second dry run validates the fixes. Final go-live readiness review with your team.

  • Edge case resolution
  • Custom field re-mapping
  • Second dry run
  • Go-live readiness review
Day 14 · Cutover

Go live.

2-hour cutover window, scheduled after-hours. Final delta sync from your live system, then DNS / login flip. Old PMS stays read-only for 90 days as a safety net.

  • 2-hour after-hours cutover
  • Final delta sync
  • 90-day read-only fallback
  • Day-1 white-glove support
Per-system specifics

How we move you off each one.

Every PMS has its own quirks — what gets read directly, what needs an export, what custom fields matter. Here's the technical reality for each.

open dental
Native connector

How it works

Direct MySQL read replica off your opendental database. We connect via SSH tunnel, snapshot, and stream changes during the dry-run window. Open Dental's open schema makes this the cleanest of the five — most of the work is just mapping their conventions to ours.

Special handling

We map their procedurelog, treatplan, and perio tables directly. Custom UserOd fields preserved verbatim. Multi-clinic configs auto-detect via preferences.PracticeIsMedicalOnly.

Read method MySQL replica
Typical timeline 7 days fast-track
Difficulty Low
DENTRIX
Native connector

How it works

Dentrix runs on JET/Access (legacy) or SQL Server (G7+). We support both. For G7+, we connect via the DXOne read API and Dentrix-Direct ODBC. Older versions: weekly export-and-ingest with a final cutover sync.

Special handling

Treatment area codes are translated to standard CDT before write. Dentrix's PatNote blob is parsed for clinical narrative recovery. Insurance plan IDs reconciled against your existing carrier list during dry run.

Read method DXOne API + ODBC
Typical timeline 14 days standard
Difficulty Medium
SoftDent
Native connector

How it works

SoftDent runs on SQL Anywhere. We use Carestream's documented ODBC layer + a local export agent that reads .dbs files directly when ODBC is restricted. The agent runs on your server, signs each batch, and posts to our ingestion endpoint.

Special handling

Patient images stay in place — we link by reference rather than copying terabytes of intraoral photos. Treatment plan versioning preserved. Recall scheduling rules migrated via translation table.

Read method SQL Anywhere ODBC
Typical timeline 14 days standard
Difficulty Medium
Eaglesoft
Native connector

How it works

Patterson's Eaglesoft also runs on SQL Anywhere. Same ODBC approach as SoftDent, with a separate adapter for their proprietary EAGLE.DB structure. Patterson Imaging refs migrate as pointers — we never duplicate radiograph blobs.

Special handling

Eaglesoft's chart shorthand parsed and normalized to canonical findings. Provider productivity reports backfilled from tHistory. Insurance fee schedules per-employer preserved in our payer-config layer.

Read method SQL Anywhere ODBC
Typical timeline 14 days standard
Difficulty Medium
CareStack
Native connector

How it works

CareStack is cloud-native, so we read via their REST API with paginated entity exports. OAuth-scoped read-only token. The entire migration runs without anyone touching a server in your office.

Special handling

Multi-location DSO configs auto-detected via OrganizationContext. Per-location fee schedules, provider rosters, and recall rules migrated as a single tree. Cross-location patient sharing settings preserved.

Read method REST API (OAuth)
Typical timeline 7 days fast-track
Difficulty Low
Data fidelity

Exactly what migrates — and what doesn't.

We're explicit about every data class. Where we don't have full fidelity (uncommon), we're transparent about it — no buried caveats. Anything marked "Manual" comes with a tracked task list and team support during the dry run.

Data class
Fidelity
Notes
Patient demographics
100% · Full
Name, address, phone, email, DOB, insurance — all preserved with original IDs as foreign keys.
Treatment history
100% · Full
Every CDT code, narrative, provider, and date. Source-system codes preserved alongside canonical mapping.
Ledger & payments
100% · Full
Per-patient balance reconciled to the cent. Adjustment history preserved. Aging buckets recomputed at cutover.
Schedule & appointments
100% · Full
All future and historical appointments, op assignments, provider routing, and recurrence rules.
Perio charts
100% · Full
All probing depths, BOP, mobility, recession, and CAL preserved with original exam dates.
Imaging
100% · Reference
Image references migrate; actual files stay in place. Imaging Bridge adapter (Dexis, Carestream, Sirona) handles serving.
Insurance & eligibility
100% · Full
Policy details, plan IDs, deductibles, maximums, fee schedules. Reverified through Stedi 270/271 on day 1.
Custom forms & templates
~95% · Partial
Standard forms migrate fully. Heavily-customized JET/Access forms may need rebuilding — flagged on day 4 dry run.
Macros & auto-text
Manual
Per-user macros are reviewed with you and recreated in Juno. Tracked as a reconcile-stage task.
Custom reports (legacy)
Manual
If you have custom Crystal/SSRS reports, we rebuild them as Juno dashboards. Most teams keep three or four; we replicate them all.
FAQ

The questions buyers actually ask.

Your old PMS stays running and read-only for 90 days post-cutover. If anything's wrong with how Juno represents your data, you have a working fallback. We've designed the cutover to be reversible up to and including the 2-hour go-live window — we can pull the plug and revert without your team noticing. We've never had to do this in internal testing, but the option is real, not theoretical.
Yes. There's no archive tier or "historical data" access fee. Every patient record from day-one of your Eaglesoft install transfers as a first-class record. You'll see the same chart history, the same notes, the same images — searchable, filterable, exactly as you'd expect.
No on both. The discovery and dry-run stages run in parallel with your normal operations — we read off a replica or snapshot, never your live database during business hours. The cutover itself is a 2-hour window after-hours, typically Friday or Saturday night. Monday morning your team logs into Juno instead of Eaglesoft and gets to work.
BAA signed before discovery starts. Data in transit uses TLS 1.3 with mutual auth. Adapter logs strip PHI before they hit our observability stack. The Juno tenant is encrypted at rest with row-level security — practice A's data is invisible to practice B by Postgres policy, not just by app code. SOC 2 Type II is on the roadmap; we're operating at SOC 2-equivalent controls today.
Probably yes — but the discovery stage exists exactly to find out. We profile your schema, including any custom UserDef fields and modified tables. The mapping report tells you which custom modifications migrate cleanly, which need a one-line translation rule, and which (rare) require a manual workaround. You sign off before we move to dry run.
Yes. The dry-run stage is essentially a 7+ day parallel run — your team can log into the staging Juno tenant alongside your live PMS, validate workflows, and surface anything that feels wrong. Some practices extend this to 14+ days before cutover. We don't charge for the extension.
For our first 10 design partners: the entire migration, including the dry run, reconcile stage, cutover, and 30 days of white-glove support after go-live, is included in the design partner program at no charge. The "catch" is that we ask for honest feedback — weekly 30-minute calls with the product team during the first 90 days. Pilot pricing on Juno itself is then locked for the life of your account.
Only 7 design partner spots remaining

Stop staying on Dentrix because leaving feels impossible.

Free migration. 14 days. Reversible cutover. Your old PMS stays read-only for 90 days. The friction of switching is now smaller than the cost of staying.

Apply to be a design partner Talk to migration team