Switching to Oralstack

Choose how your clinic starts.

Oralstack is designed to run as the clinic's primary system. Standalone rollout is currently guided: we confirm native capability, clinic setup, record ownership, and any data move before a pilot begins. Plato is optional—not a prerequisite.

Choose a starting path →Book a clinic walkthrough

Rollout: Guided pilot
Standalone use: Clinic setup required
Plato: Optional connection

Four starting paths

Start with the clinic you have—not a generic migration promise.

Start fresh

Set up a new clinic in Oralstack.

Configure the clinic, providers, chairs, working hours, payment modes, staff access, and the first patient workflow without depending on another PMS.

Confirm clinic identity, patient numbering, roles, and operating hours.
Validate the first appointment, patient record, clinical note, and checkout path.
Train the front desk and clinical team against the configured clinic—not a generic sandbox.

Plan a new-clinic setup →

Move from paper

Review what should become a digital record.

Start with paper or spreadsheets. We inspect the source, agree the supported scope, test a sample, and document what remains in the clinic archive.

Inventory patient, appointment, clinical, billing, document, and audit sources.
Map supported fields and exceptions before a full import is considered.
Keep validation, rollback, archive, and offboarding decisions visible in the rollout plan.

Assess paper and spreadsheets →

Move from another system

Map the supported records before cutover.

Review the existing practice system, the exports it can produce, and the records staff need on day one before a migration scope is agreed.

Inspect representative exports before promising a migration timeline.
Test field mapping, exceptions, totals, attachments, and staff validation.
Define source retention, rollback, and the record that becomes authoritative after cutover.

Assess the current system →

Keep a connection

Use Oralstack with Plato where that fits.

A clinic can keep Plato authoritative for connected records while Oralstack runs the clinic workflow around it. Connector readiness and every supported write path are reviewed before rollout.

Confirm the clinic connector, available records, provider setup, and permissions.
Separate native Oralstack records from Plato-backed reads and reviewed changes.
Treat an unavailable connector or local fallback as visible—not as a completed writeback.

Review the Plato connection →

Before cutover

Prove the clinic path before naming a go-live date.

Native product code can exist before a capability is enabled for a clinic. The rollout plan records what is available, what needs setup, and what remains a controlled pilot.

Patient identity: Who creates the patient number, how duplicates are handled, and which record is authoritative after rollout.
Schedule and clinic setup: Providers, locations, chairs, hours, appointment states, and the exact booking and rescheduling path.
Clinical and billing scope: What the team records in Oralstack, how checkout is reviewed, and which payer, claim, payment, or refund actions stay external.
Continuity and exit: Backups, recovery expectations, supported exports, retained source records, offboarding, and the rollback decision.

Guided rollout

Map the first clinic workflow with Oralstack.

Tell us how the clinic works today, which records need to move, and which dental job should run first. We'll separate native setup, migration work, optional connections, and anything outside the current scope.

Plan the clinic rollout →