Migrate from Quanum Practice Management to Microsoft Dynamics 365 Sales

Quanum PM export format requires pre-processing before Dataverse ingestion

Quanum PM delivers data as a Microsoft Access database (.mdb/.accdb) or flat CSV exports — not a structured API. The Access format requires an intermediate step: FlitStack parses the .mdb schema to identify table relationships (Patient, Insurance, Provider, Appointment, Encounter), resolves foreign keys, and outputs normalized CSV files that match Dataverse column types before Bulk API ingestion. Practices that used custom fields in Quanum PM may have additional columns in the Access tables that require schema discovery before mapping begins. This pre-processing step adds 1–3 days to the project timeline compared to standard CRM-to-CRM migrations that use API exports directly.

Provider-to-owner resolution creates orphaned records if email match fails

Dynamics 365 Sales requires a valid OwnerId (SystemUser reference) on every Contact and Event. Quanum PM provider records store provider names as free text with no mandatory email field — a known limitation of the platform. FlitStack resolves providers by matching the email extracted from the provider record (if present) or by matching the provider name to the FullName of an existing Dynamics 365 SystemUser. When no match is found, the Contact or Event is flagged and assigned to a designated fallback owner before migration — but this means the audit trail of which provider handled the patient or appointment is not preserved automatically. Your admin must review unmatched provider assignments and either invite the provider as a Dynamics 365 user or manually reassign records after migration.

Dynamics 365 Sales Professional caps custom tables at 15, forcing Enterprise licensing for complex billing

The billing claim data from Quanum PM — claim number, billed amount, paid amount, claim status, payer, submission date — has no native Dynamics 365 Sales equivalent. FlitStack creates a custom Claim__c Dataverse table to preserve this financial history. However, Dynamics 365 Sales Professional licensing limits custom tables to 15 total. Practices with more than 15 custom fields across multiple entities (insurance fields, alert fields, encounter fields, referral fields) can exceed this cap. Exceeding the cap requires an upgrade to Sales Enterprise or Sales Premium licensing, which adds per-user-per-month cost. FlitStack audits your Quanum PM custom field count and flags this licensing constraint before the migration plan is finalized.

Encounter notes containing PHI require Dataverse field-level security configuration

Quanum PM encounter records often contain clinical notes, diagnosis codes (ICD-10), and procedure codes (CPT) that constitute protected health information (PHI) under HIPAA. These notes migrate as Annotation NoteText fields attached to Contact records in Dynamics 365 Sales. Dynamics 365 supports field-level security through Field Security Profiles — but this is not enabled by default. FlitStack configures Field Security Profiles on sensitive custom fields (Diagnosis_Code__c, Procedure_Code__c, Insurance_Carrier__c, Member_ID__c) so that only roles with a business need (front-desk supervisors, billing staff) can read those fields. This is a post-migration configuration step that must be completed before the system goes live to maintain HIPAA compliance posture.

Duplicate patient records collapse during migration — Quanum PM did not enforce uniqueness

Quanum PM historically allowed duplicate patient records without a merge or deduplication mechanism at the platform level. When FlitStack ingests patient records into Dynamics 365 Sales Contact, contacts with identical first name, last name, date of birth, and address are flagged as potential duplicates before the full run. Your team decides the merge strategy — primary record retention with attachments from duplicates, or manual review. Dynamics 365 Sales duplicate rules can be activated post-migration to prevent new duplicates going forward, but existing duplicates must be resolved during the migration window. This is a data-quality step that cannot be fully automated when the duplicates have conflicting values in overlapping fields.