Migrate from Encharge to Microsoft Dynamics 365 Sales

Encharge People records split into Dynamics 365 Leads (for people with early lifecycle stages like subscriber or lead) and Contacts attached to Accounts (for people with qualified stages like customer or evangelist). The split rule is derived from Encharge's lifecyclestage and lifecycleboughth_stage properties during scoping. We preserve the original Encharge lifecycle stage value in a custom field on both Lead and Contact for audit. Primary email address becomes the dedupe key for all inserts.

Encharge Accounts map directly to Dynamics 365 Accounts. The domain field from Encharge maps to Account Website. Account is created before any Person-to-Contact import so that the AccountId lookup is satisfied at Contact insert time. Custom company fields from Encharge become custom Account fields in Dynamics 365.

Encharge Tags are flat string labels applied to People. We export the full tag set and assess cardinality during scoping. If a Contact has fewer than 15 distinct tags, we map to a Dynamics 365 Multi-Select Picklist on Contact. If cardinality is higher or if tags represent categorical data rather than label sets, we create a custom text field and store tags as comma-separated values. Tag history per contact is preserved as a text log in a secondary field.

If Encharge is configured with Deals as a Custom Object, we map them to Microsoft Dynamics 365 Sales Opportunity. The deal name maps to Opportunity Name, amount maps to Amount, close date maps to CloseDate, and stage maps to StageName via a pre-configured Sales Process. We configure the Opportunity Record Type and Sales Process in Dynamics 365 before migration so that stage values are valid at insert time.

Encharge Custom Objects (Orders, Invoices, Subscriptions, or any customer-defined entity) migrate to Dataverse custom tables in Dynamics 365. We pre-create the destination schema during the scoping phase, including all custom columns, data types (string, integer, decimal, date, lookup), and any lookup relationships to Account, Contact, or Opportunity. The schema must be deployed to the Dynamics 365 environment before data load begins.

Encharge Activities (email opens, page views, custom events, webinar attendance) do not map directly to any standard Dynamics 365 object because Microsoft Dynamics 365 Sales tracks CRM engagements (calls, meetings, emails, tasks) rather than behavioral marketing events. We map Activities to a combination of Task records (for event-type tracking) and custom fields on the Contact or Account record. The customer decides during scoping whether to load full activity history as Task records or to summarize high-level counts as custom number fields for reporting.

Encharge Email Templates stored as HTML export as files and are attached to a Note record in Dynamics 365 tied to the relevant Account or Contact. The templates are not functional in Dynamics 365's native email template system (which requires Dynamics-specific merge syntax), but the HTML content is preserved for the customer's marketing team to re-author in Dynamics 365 or a separate email marketing tool.

Encharge Form field definitions export as a list of field names and types. We map these to new custom fields on the Dynamics 365 Contact or Lead form. Form submission endpoints, webhook URLs, and embed codes do not migrate and must be replaced with Dynamics 365 native form endpoints (Power Apps portals, Dynamics 365 marketing forms, or Web-to-Lead) post-migration.

Encharge Owner assignments on People, Accounts, Deals, and Activities map by email address to Dynamics 365 User records. We build a reconciliation report listing every Encharge owner that has no matching Dynamics 365 User; the customer's admin provisions any missing Users before production migration resumes. Inactive Encharge owners map to a system fallback user rather than nulling the OwnerId.