Oralstack

Reference · Migration & operations

Plato → cloud PMS migration runbook

Last reviewed 27 Apr 2026·13 min read·Free reference

Pre-migration audit, data export specifics, cleaning, cutover-week day-by-day, staff retraining, post-cutover review. The runbook for clinics moving off Plato to a cloud dental PMS.

Migrating off Plato is one of the higher-stakes operational moves a Singapore dental clinic makes. The clinic runs on it every day; downtime translates directly to lost revenue and unhappy patients. Done well, a Plato → cloud migration is invisible to patients. Done badly, it introduces weeks of catch-up data entry and at least one incident that lives in clinic folklore.

This runbook describes the full migration motion: what to audit before you start, how to export Plato data without losing fidelity, how to clean it, how to run cutover week, and how to operate in the first month after.

Section 1 — Pre-migration audit (week -8 to -4)

Inventory everything

  • Plato version + last patch date. Different versions export differently; some export options only exist on recent patches.
  • Data volumes. Patient count, total appointments to date, treatment-history record count, financial record count, attached files (radiographs, photos, intake PDFs).
  • Custom fields. List every custom field added to Plato over time. These often hold critical clinical info (allergy notes, recall preferences, billing notes) and are the most commonly lost in migration.
  • Integrations. What else talks to Plato? Imaging desktop apps, accounting export, recall SMS service, insurance portals. Each is a migration sub-project.
  • Active users. Roles: receptionist, dentist, clinical assistant, owner, accountant. Usage patterns differ; retraining differs.

Decide on data scope

Not all data needs to migrate live. Pragmatic split:

  • Live in cloud (must migrate cleanly): active patients, appointments next 90 days, current recall queue, last-12-month treatment history, last-12-month financial ledger, allergy / consent / clinical flags, current insurance info.
  • Read-only archive (historical, accessible but not edited):older treatment history, older financial records, archived patients (no visit in 5+ years), historical radiographs.

Reducing scope reduces risk. A migration that tries to perfectly port 15 years of data is a migration that takes 6 months and breaks more than it preserves.

Communicate

  • Inform clinical team — what they need to know, when training happens, what the cutover week looks like.
  • Inform patients with appointments in the cutover window — they may need to confirm details a second time.
  • Inform external partners — accountants, insurers, lab — that your billing system is changing on date X.

Section 2 — Export from Plato (week -4 to -2)

Standard exports

Plato exports vary by edition. Generally available:

  • Patient list (CSV)
  • Appointment history (CSV)
  • Treatment history (CSV)
  • Financial transactions (CSV)
  • Recall list (CSV)
  • Custom field values (sometimes only in proprietary format — request DB-level dump)

Gotchas

  • Timezone handling.Plato stores some timestamps in local time, others in UTC, depending on field and version. Migration scripts that don't handle this shift appointments by 8 hours after import. Test with known appointments.
  • NRIC formatting. Hyphens, spaces, leading zeros — Plato allows multiple formats. Normalise to a canonical format on import.
  • Patient duplicates. Same patient registered twice (different name spellings, different IDs). Detect via NRIC, mobile, DOB matching.
  • Treatment-history orphans. Treatment records referencing deleted patient IDs. Decide: migrate as orphan (with note), drop, or attempt patient match.
  • Financial reconciliation.Total of exported transactions should match Plato's month-end financial summary for at least the last 12 months. Discrepancies surface missed transactions.
  • Attached files. Plato stores radiographs and PDFs in a server-side folder structure. Export the folder alongside the database export, or many files will be referenced but missing post-migration.

Section 3 — Data cleaning (week -3 to -1)

  • Patient deduplication. Run automated dedup on NRIC + mobile + DOB. Manually review possible matches flagged with name similarity but different identifiers. Conservative merge — if uncertain, leave as separate.
  • Recall queue cleanup.Patients with recall due dates >2 years past — review whether to keep in active recall or archive. Most have moved on.
  • Provider mapping.Plato provider codes vs new system's provider IDs. Map every provider explicitly.
  • Procedure code mapping.Plato may use clinic- custom codes. Map each to the new system's code (or to MOH-standard codes if you're standardising).
  • Custom fields → new fields.Decide each custom field's destination. Some go to dedicated fields, some to free-text notes. Document the mapping.
  • Allergy and clinical-flag normalisation.These are critical. If Plato has them in free-text and the new system has structured allergy fields, map carefully — manual review for any patient with non-empty allergy text.

Section 4 — Cutover week, day by day

Friday before cutover (day -2)

  • Final import of cleaned data into the new system.
  • Smoke test: pick 20 random patients, verify their record is correct end-to-end (history, recall, financial, attached files).
  • Inform clinical team of the cutover plan — chair-by-chair familiarisation tomorrow.

Saturday before cutover (day -1)

  • Half-day clinic familiarisation. Each staff member walks their common workflows in the new system on the imported real data.
  • Front desk: pull tomorrow's schedule, look up 5 patients, register a fake new patient.
  • Clinical: open today's charted patients, attempt a chart entry, attempt a radiograph capture.
  • Owner: verify financial dashboard reads sensible numbers.
  • Document any issues found — these must be resolved before Monday morning.

Cutover Monday (day 0)

  • Monday is intentionally light-scheduled — no new patient appointments, only repeat patients with familiar staff.
  • Plato runs in read-only mode in the background as a fallback / reference.
  • Two staff at the front desk all day, one supporting the other on new-system motions.
  • End of day: 30-minute review with all staff — what worked, what felt slow, what broke.

Cutover Tuesday–Friday (days 1–4)

  • Normal scheduling resumes.
  • Daily 15-minute end-of-day reviews to catch issues early.
  • On-call dental migration support (your vendor or migration partner) available all week.
  • Any data discrepancies surfaced — log, triage, fix in the new system OR re-import from Plato source if structural.

Section 5 — Staff retraining by role

Front desk

  • Booking: new vs returning. Scheduling drag-to-reschedule. Recall pull workflow.
  • Discharge billing: insurance vs patient portion split, payment terminal integration, recall set before patient leaves.
  • WhatsApp / SMS recall outreach.

Clinical (dentist + assistant)

  • Chart navigation: open patient, last visit, treatment plan.
  • Tooth-led charting (vs Plato's form-led).
  • Radiograph capture from the chair.
  • Case-note entry that writes back to billing.

Owner / practice manager

  • Daily / weekly / monthly dashboards.
  • Audit log queries — for accountant or compliance.
  • User management: adding / removing staff, role changes.
  • Backup verification: how to confirm backups are running.

Section 6 — First month after cutover

Week 1

  • Daily standups; surface and resolve issues fast.
  • Plato remains read-only. Cross-reference for any patient where something feels off.
  • Staff feedback loop: what feels slower than Plato, what feels faster, what's confusing.

Week 2–3

  • End daily standups; switch to twice-weekly review.
  • Address top staff friction items — usually muscle-memory differences from Plato that need either retraining or new-system configuration tweaks.
  • Monitor the financial dashboard against Plato's last-month data — totals should be in the same ballpark.

Week 4

  • End-of-month financial reconciliation in the new system. Compare to your accountant's expectations.
  • Plato decommission decision: shut down the read-only fallback (most clinics keep it 6–12 months for archive query, then archive the database to cold storage).
  • Migration retrospective: what would you do differently next time? Document for any other location migration.

Section 7 — Rollback contingency

At what point would you roll back to Plato? Define this explicitly before cutover.

  • Hard fail (rollback within 24h):data corruption, system unavailable for a clinic-day, financial ledger off by >5%.
  • Soft fail (review at end of week 1):significant staff productivity loss, >3 patient-facing incidents in week 1, data scope gap discovered.
  • Acceptable friction (continue): slower for staff (expected for first 2–3 weeks), occasional UI confusion, edge-case data quirks.

Pre-cutover checklist

  • Pre-migration audit complete (week -8 to -4)
  • Plato data exported with all relevant tables (week -4)
  • Data cleaned, deduped, mapped (week -3 to -1)
  • Final import tested in new system (Friday day -2)
  • Staff Saturday familiarisation done (day -1)
  • Plato switched to read-only fallback (day -1)
  • External partners notified (week -1)

Cutover-day checklist

  • Light schedule (no new patients on Monday)
  • Two front desk staff all day
  • Migration partner on standby
  • Plato accessible read-only as cross-reference
  • End-of-day team review and issue log

Post-cutover checklist (week 1)

  • Daily standups
  • Patient-facing incident log (target: 0)
  • Staff feedback log → translated into actions
  • Financial sanity check (daily totals make sense)
  • Decision on rollback by Friday — go or no-go for permanence

For the cloud-side of this migration — the destination PMS that accepts Plato exports cleanly, handles the 8-hour timezone gotcha correctly, mirrors Plato's booking form for staff muscle memory, and keeps the financial ledger structurally sane — Oralstack is built around exactly this transition. Read more at our Plato migration article or request a migration assessment at /contact.

Try Oralstack

Want this in your clinic, not just on paper?

Oralstack's migration & operations module is built around the motions in this reference. A 30-minute demo walks the relevant team through it on a sample dataset that mirrors a Singapore clinic.

Book a demo →