Migrate from MOGO to Microsoft Dynamics 365 Sales

Every MOGO patient becomes a Dynamics 365 Contact. The patient's first name maps to FirstName, last name to LastName, date of birth to BirthDate, and email to Email. The practice's clinic name populates the AccountId lookup so the Contact is associated with the correct Account (clinic) in Dynamics 365.

MOGO stores one address per patient. The address line, city, state or province, and ZIP or postal code map to Dynamics 365 Contact address fields (street, city, statecode, postalcode). Country is populated from MOGO country data or defaults to the clinic's country setting.

MOGO primary phone numbers map to Contact.Phone. Mobile or cell phone numbers map to Contact.MobilePhone. If MOGO stores a separate emergency contact phone number, it is preserved in a custom Emergency_Contact_Phone__c text field on the Contact record. Practices that record multiple contact numbers for a single patient — such as a home phone, work phone, and emergency line — can retain all values in dedicated custom fields to ensure no patient communication detail is lost during the migration to Dynamics 365.

MOGO insurance carrier name, plan name, group number, subscriber ID, and effective dates have no native Dynamics 365 equivalent. These become custom fields on Contact: Insurance_Carrier__c, Insurance_Plan__c, Insurance_Group_Number__c, Insurance_Subscriber_ID__c, and Insurance_Effective_Date__c. We preserve the full insurance record as a field set on the Contact rather than a separate entity.

MOGO appointments track dentist, date, time, operatory, type, and status — concepts not native to Dynamics 365 Sales. We map appointments to a custom MOGO_Appointment__c table linked to the Contact via a lookup. The appointment date becomes Appointment_Date__c, dentist name becomes Provider__c (resolved to Dynamics OwnerId by email), and type becomes Procedure_Type__c pick-list. A Junction record connects each appointment to the patient's Contact.

MOGO treatment plans list procedure codes, tooth numbers, surfaces, fees, and clinical notes per visit. Dynamics 365 Sales has no native treatment-plan entity. We create a custom Treatment_Plan__c table in Dataverse with fields for procedure code, tooth number, surface, fee, date, provider, and status. Each treatment plan links to the Contact and optionally to an Opportunity representing the case value.

MOGO supports multi-location practices. Each clinic location becomes a Dynamics 365 Account with the clinic name as Account.Name, the clinic address as Account.Address fields, and the clinic phone as Account.Telephone. Multiple providers can be associated with one Account via Contact records, each with the AccountId lookup set to the clinic.

MOGO providers (dentists, hygienists, office managers) do not exist as standalone objects in Dynamics 365. Provider records are resolved to existing Dynamics 365 users by email match. Unmatched providers are flagged as Contacts with a custom Provider__c flag set to true and a Provider_Role__c pick-list value, so the admin can invite them as users post-migration.

MOGO clinical notes per patient visit are preserved in a custom Clinical_Notes__c field on the Contact record, capped at 32,000 characters. For practices with high note volume, notes are linked as an Attachment record on the Contact using Dynamics 365 Notes with a file upload rather than a text field.

MOGO recall intervals track when a patient is next due for hygiene or checkup appointments. Dynamics 365 Sales has no native recall concept. We create a custom Recall__c table with fields for Recall_Type__c (hygiene, perio, recall), Recall_Due_Date__c, and Recall_Status__c. Each recall record links to the Contact and can trigger a Power Automate flow to create an Opportunity or Task when the due date arrives.

MOGO generates invoices for procedures. In Dynamics 365 Sales, the financial value of a case maps to the Opportunity Amount field. Invoice number, billing date, and payment status become custom fields on the Opportunity (Invoice_Number__c, Billing_Date__c, Payment_Status__c). Full accounts-receivable data lives in an ERP and is not part of the CRM migration scope.

MOGO Enterprise allows practices to add custom fields for specialty tracking, referral sources, or clinical flags. Each custom MOGO field maps to a corresponding custom field in Dataverse on the appropriate table (Contact, Account, or custom entity). FlitStack AI creates the target fields before migration and applies the correct data type (text, number, pick-list, date, or checkbox).