Migrate from DGL Practice Manager to Microsoft Dynamics 365 Sales

Engage DGL and extract the data export

FlitStack AI begins by contacting DGL Practice Manager's support team to initiate the data export under the customer's contract terms. We identify all data subsets needed — patient records, insurer records, appointments, invoices, clinical notes, and documents — and agree on an export format (CSV, SQL backup, or DGL's native export tool). We disclose the DGL extraction fee at this stage and include it in the project budget. If DGL's export tool produces inconsistent field names or missing data, we log a remediation task before proceeding to mapping.

Design the Dynamics 365 schema and create custom columns

Before data moves, the Dynamics 365 admin (or FlitStack AI's implementation team) creates all required custom columns in Dataverse: Referral_Source__c, InsurancePolicyNumber__c, GPName__c, ClinicalFlag__c, ShortfallAmount__c, Original_Create_Date__c, Source_System_ID__c, and EDI_Submission__c table columns. We deliver a schema setup checklist based on the DGL custom field inventory. If the practice needs appointment scheduling preserved, we recommend deploying the Bookings app (part of Field Service or Universal Resource Scheduling) and create the custom appointment table in Dataverse as a staging layer.

Resolve consultants and staff users by email against Azure AD

DGL users (consultants, medical secretaries, practice managers) are matched to Dynamics 365 System Users by email address. Unmatched users are flagged in a pre-flight report — FlitStack AI generates a CSV of unmatched users with the DGL role and name so the practice administrator can invite them to the Dynamics 365 tenant or assign their records to a fallback owner. No patient or invoice record lands in Dynamics 365 without a resolved OwnerId. This step is critical for audit compliance in medical records contexts.

Migrate Accounts and Contacts before invoices and appointments

Dynamics 365 requires AccountId on Contact records and Contact lookups on Opportunity records. We sequence the migration to respect foreign-key dependencies: Insurers → Accounts first (AccountId required for Contact), then Patients → Contacts, then Invoices → Opportunities, then Appointments → Tasks. Documents are uploaded last and linked via SharePointDocumentLocation RegardingObjectId to the target Contact. This sequencing prevents orphan records and the 'parent record does not exist' errors that occur when dependent records are loaded out of order.

Run sample migration with field-level diff before full commit

A representative sample (typically 200–500 records spanning patients, insurers, invoices, and appointments) migrates to a Dynamics 365 sandbox environment first. FlitStack AI generates a field-level diff comparing source values against destination values for every mapped column — particularly the custom fields (Referral_Source__c, InsurancePolicyNumber__c, ShortfallAmount__c) and date fields (Original_Create_Date__c, appointment dates). The diff is reviewed with the practice administrator before the full migration run commits. This is where EDI shortfall logic and appointment status mapping are validated.

Cut over with delta-pickup window and rollback readiness

The full migration runs against the Dynamics 365 production environment. A delta-pickup window of 24–48 hours captures any DGL records created or modified during the cutover period. FlitStack AI generates an audit log of every record created, updated, and skipped during migration. If reconciliation fails — a mismatch in invoice amounts, a missing insurer account, or a patient record that failed to link — a one-click rollback reverts all Dynamics 365 changes to the pre-migration state. After rollback confirmation, the customer can remediate and re-run. Post-migration, FlitStack AI hands over a Power Automate rebuild guide for EDI submission workflows and appointment reminder sequences.