Migrate from Essential MD Software Suite to Microsoft Dynamics 365 Sales

Dataverse API rate limits require staged extraction from Essential MD

Dynamics 365 Dataverse Web API enforces concurrent request limits (4 per user for standard environments, up to 100 for high-load environments) and daily request quotas that scale with your licensing tier. If your Essential MD instance holds a large patient base with thousands of encounters and attachments, a naive bulk upsert will hit 429 Too Many Requests errors mid-migration. We handle this by staging Essential MD extracts in batches, throttling Dataverse API writes, and resuming from the last successful record — but the Essential MD export side also needs to be polled carefully to avoid overwhelming a small-footprint healthcare SaaS API that may not handle high-concurrency extraction well. Map your expected record volume to the right Dataverse API tier before migration day.

Diagnosis codes require a Dataverse custom table with N:1 relationship to Contact

Essential MD stores ICD codes as fields on the patient record. Dynamics 365 Sales has no native diagnosis code table — the out-of-box schema cannot store ICD-10 or CPT codes on a Contact record without creating a custom entity. This means your admin must create a Diagnosis_Code__c custom table in the Dataverse solution before data lands, with a lookup relationship to Contact and fields for code, description, diagnosis date, and provider. We deliver the custom-table definition as part of the migration plan, but the creation itself requires Dataverse schema access. If this step is skipped, diagnosis data cannot land in Dynamics 365 without overwriting a native field.

Essential MD workflows do not migrate — Power Automate rebuild required

Every automation rule, multi-step approval chain, and conditional trigger in Essential MD is specific to Essential MD's workflow engine and cannot be translated to Dynamics 365 or Power Automate through any automated path. Your team will need to export the workflow definitions from Essential MD and rebuild them as Power Automate flows or Dynamics 365 cloud flows. We provide an export of your Essential MD workflow definitions as JSON, with a before/after logic summary your admin or a Power Automate consultant can use as a rebuild reference. This is a manual step that adds 2–6 weeks to your overall project timeline depending on workflow complexity.

Insurance carrier mapping risks N:1 duplication in Dynamics 365 if not handled carefully

Essential MD's insurance carrier list is a flat table — each carrier appears once. In Dynamics 365, an insurance carrier can be modeled as an Account, but if two Essential MD patients share the same carrier and both are migrated simultaneously without de-duplication, you risk creating duplicate Account records for the same carrier. We apply a carrier-name de-duplication pass before migration: carriers are upserted by name to a dedicated carrier Account, and patient-specific insurance details (member ID, group number) are stored as custom fields on the Contact. If your Essential MD instance has carrier name variants (e.g., 'Aetna' vs 'Aetna Inc.'), those variants will collapse into one Account and your admin should confirm the canonical name.

Scheduling slot data has no native Dynamics 365 equivalent

Essential MD appointment slot durations, room assignments, and booking rules are first-class data in the source system. Dynamics 365 Sales has no native scheduling slot concept — appointments are modeled as Tasks or Events with a start and end time, but slot duration, room, and booking status are not native fields. We migrate appointment data to Task records and surface slot duration and room as custom fields on the Task. If your practice relies on slot-level data for reporting or resource utilization, those custom fields must be created in Dataverse before migration and the reporting views updated accordingly.