Migrate from Cliniko to Microsoft Dynamics 365 Sales

Cliniko appointment types have no native Dynamics 365 equivalent — appointment semantics require a custom Dataverse table

Cliniko appointment types carry billable flags, default durations, and category labels (telehealth, initial consult, procedure) that define the semantics of each booking. Dynamics 365 Sales has no native appointment-type entity — the built-in Task and Phone Call activity types have no equivalent concept. FlitStack creates an AppointmentType__c custom Dataverse table with Name, DefaultDurationMinutes, IsBillable, and ClinikoID__c fields. Each migrated Task then carries a lookup to AppointmentType__c so reporting by appointment category works in Dynamics 365 without relying on string-matching in the Task Subject. This requires a pre-migration schema setup step in the target Dynamics environment before data loading begins.

Practitioners without Dynamics 365 user licenses cannot own records — email-match orphaning must be resolved before migration

Dynamics 365 requires a licensed SystemUser to own a record. Cliniko practitioners may include administrative staff or referring clinicians who do not hold (and should not be billed for) a Dynamics 365 Sales license. FlitStack resolves each Cliniko practitioner by email against existing SystemUser records: matched practitioners become record Owners directly; unmatched practitioners are migrated to a custom Practitioner__c table linked to a Contact record that stores their profile. Unresolved practitioners (no email in either Cliniko or Dynamics) are flagged in a pre-migration audit report so the admin can either invite them to Dynamics 365 or assign a fallback owner before the migration run commits.

Cliniko invoice payment status requires explicit value-by-value mapping to a custom Opportunity field

Cliniko invoice statuses (Paid, Due, Overdue, Partially Paid, Cancelled, Refunded) are arbitrary strings defined at the account level. Dynamics 365 Opportunity Stage is a sales-pipeline stage pick-list not semantically equivalent to billing status. FlitStack creates a custom PaymentStatus__c picklist on the Opportunity record and builds a value-mapping table for each Cliniko status string found in the data. If a Cliniko practice has added custom status values outside the standard set, those appear in the pre-migration audit and must be mapped individually before the migration run. This prevents silent data loss where Cliniko's payment state maps to a blank or default Dynamics field value.

Patient file attachments require SharePoint re-upload — Cliniko's file storage is not directly portable

Cliniko stores file attachments (signed forms, imaging references, intake documents) in its own cloud storage with per-attachment URLs. Dynamics 365 Sales does not host files natively — it relies on SharePoint Online document libraries connected via the native SharePoint integration. FlitStack downloads each attachment from Cliniko's storage during the export phase, then re-uploads to a SharePoint PatientFiles library organized by Contact record GUID. A custom Attachment_URL__c field on the Contact records the Cliniko source URL for traceability during the cutover window. File size limits from Cliniko's export apply; attachments exceeding 50 MB are flagged in the audit report for manual handling.

Multi-location Cliniko setups require location-scoped user resolution to avoid practitioner-to-owner assignment collisions

Cliniko supports multiple locations with practitioners who may work across locations. Dynamics 365 user records are tenant-global — a practitioner with one email address exists as a single SystemUser regardless of location. When the same practitioner appears in Cliniko appointments at multiple locations, FlitStack resolves their email to one SystemUser and maps all appointment Tasks to that owner. The Cliniko location ID is preserved in a custom Location__c field on the Task so location-based reporting can filter within Dynamics 365 without requiring separate user accounts per location. Practices that need strict per-location data isolation in Dynamics 365 must configure access teams or security roles pre-migration.