Integrations & migration
Switch to MSKster without starting over
Technical pathways for CSV import, assisted migration, and staged go-live — honest about what your source system can export, and what we validate before cutover.
Which path is yours?
New to MSKster
Starting fresh
No system to migrate from. We configure your organization, disciplines, and templates, then onboard your team before the first booked consult.
- Guided setup call to configure your clinic
- Template selection per discipline
- Team invited and trained before go-live
Switching to MSKster
Bringing your data with you
Coming from another practice management system. We map exports, validate in staging, and coordinate a controlled go-live so nothing is lost mid-transition.
- Discovery call to scope your current system
- Test import you review before anything goes live
- A dedicated go-live window, not a surprise cutover
Technical import model
Entities we typically migrate
Exact columns vary by source system. This is the working model we use in discovery — not a guarantee that every vendor exports every field.
Patients
Required (or strongly preferred)
- external_id or chart_number
- full_name
- date_of_birth (if available)
Optional
- phone
- sex/gender
- address
- emergency_contact
- tags
Duplicates are flagged on name + DOB (+ phone when present). You decide merges.
Practitioners / staff
Required (or strongly preferred)
- external_id
- full_name
- role
Optional
- disciplines
- active_flag
- license_id
Mapped to MSKster roles (owner / admin / practitioner / front desk) during onboarding.
Appointments
Required (or strongly preferred)
- external_id
- patient_ref
- practitioner_ref
- start_at
- status
Optional
- location
- service_code
- duration_minutes
- notes_snippet
Timezone must be explicit. Cancelled vs completed statuses are normalized in mapping.
Notes / chart entries
Required (or strongly preferred)
- external_id
- patient_ref
- authored_at
- body_or_sections
Optional
- practitioner_ref
- episode_ref
- note_type
- signed_flag
We prefer structured sections (S/O/A/P) when the source has them; otherwise free text imports as a signed historical note.
Packages / memberships
Required (or strongly preferred)
- external_id
- patient_ref
- product_name
- remaining_units_or_status
Optional
- purchase_date
- expiry
- price_paid
Balances are validated in staging before go-live so front desk doesn’t inherit silent errors.
CSV conventions
How to prepare files
- UTF-8 CSV (or XLSX exported cleanly to CSV). One entity type per file.
- Header row required. Snake_case or clear human headers both work — we map either.
- Dates as ISO-8601 where possible (YYYY-MM-DD or full timestamp with offset).
- Stable external IDs from the source system — critical for re-imports and reconciliation.
- Do not paste PHI into email threads; share via the secure upload path we provide.
Staging validation
What “good” looks like before go-live
- Row counts match export totals you expect
- Orphan appointments/notes without patient refs are listed for decision
- Duplicate candidates queued for clinic review
- Package remaining units sample-checked against source
- Staff can open a sample of historical notes in staging
Go-live checklist
Cutover is a process, not a button
- 01Freeze window agreed (usually after last clinic day before cutover)
- 02Final delta export if needed (new appointments / notes since test import)
- 03Import into production org with verification checklist signed by clinic owner/admin
- 04DNS/app bookmark cutover + staff login verification
- 05Hypercare period: front desk + practitioner spot checks on day 1–3
Move to MSKster
Guided CSV import
For clinics that can export records. Available fields depend on the source system and data quality.
Assisted migration
Onboarding maps fields, validates a sample in staging, then coordinates a controlled go-live import.
API / custom migration
Where a source system provides suitable API access, we assess a secure assisted pathway — we don’t promise every vendor. See the developer overview for the intended MSKster API direction.
Building against MSKster later? Start with the developer overview.
Migration safety process
- 01Discovery — current software, export/API options, scope
- 02Mapping — fields, duplicates, incomplete records, decisions
- 03Test import — sample in secure staging for clinic validation
- 04Controlled migration — approved data in an agreed window
- 05Go-live & verification — counts, balances, access, workflows
Your clinic retains ownership of its data. Migration is planned, reviewed, and verified before go-live — subject to your customer agreement and architecture.
Connect your tools
We list categories honestly. No fake marketplace logos for tools we don’t support yet.
Migration questions
It depends on what your current system can export — most practice management tools support CSV or spreadsheet exports of patients, appointments, and notes. We review your specific system on a discovery call before committing to a migration plan.
We test your import against a sample of your real data in a secure staging environment before anything live moves, specifically so go-live day doesn't come with surprises.
Our onboarding team maps your fields, flags duplicates or incomplete records, and coordinates the go-live window with you — you're not exporting and re-uploading files on your own.
That's normal. Mapping and validation exist precisely to catch duplicates and gaps before go-live, and we'll flag anything that needs a decision from your team rather than guessing.
Yes — this follows the same discovery and staged-validation process as a migration from an external system, just between two MSKster organizations.