Migrate from Act-On to Microsoft Dynamics 365 Sales

Discovery and data audit

We audit the source Act-On environment across Contacts (volume and properties), Companies, Lists (count and type: static vs dynamic), Programs (count and estimated step complexity), Custom Data schemas, engagement score coverage, and Activity history volume by type. We confirm the exact product name and API credentials during discovery to avoid the ACT! vs Act-On confusion. The discovery output is a written migration scope specifying record counts, field mapping, custom entity requirements, and a recommendation on whether the destination Microsoft Dynamics 365 Sales org is provisioned in Production or Sandbox for the initial migration run.

Dataverse schema pre-creation

We create the destination schema in Microsoft Dynamics 365 Sales before any data export begins. This includes any Custom Data entities mapped from Act-On Custom Data schemas, custom fields on Contact and Account to hold Act-On-specific properties (act_lifecycle_stage__c, act_engagement_score__c, act_original_source__c, act_tags__c), a custom entity act_form_submission__c for web form data, and a custom entity act_activity_log__c for behavioural event history. Each custom field's Dataverse data type is matched to the Act-On source type. The schema is deployed into a Sandbox org first for validation if the customer requests a parallel test run.

Data profiling and deduplication

We run a data quality assessment on the exported Act-On data before import. Duplicate contacts (same email address) are flagged for the customer's review; we apply a dedupe rule (typically retaining the most recently updated record) and log the merged record IDs for audit. Incomplete records (missing required fields like lastname or email) are quarantined and reported to the customer for remediation before import. Lists are profiled to determine the tag-value distribution and whether dynamic Lists can be approximated with Power Automate flows or require manual rebuild in Dynamics Customer Insights.

Sandbox or parallel test migration

For migrations exceeding 10,000 Contacts or involving custom entities, we run a parallel test migration into a Microsoft Dynamics 365 Sales Sandbox environment. The customer's RevOps or sales operations lead spot-checks 20-30 migrated records against the Act-On source for field accuracy, verifies the Account-Contact parent relationship resolution, confirms List membership tagging, and reviews the activity log for completeness. Any mapping corrections are documented and applied before the production migration begins. This step is optional for smaller migrations and can be replaced with a representative sample review in the production org.

Production migration in dependency order

We run production migration in dependency order: Accounts (from Act-On Companies) first, then Contacts with AccountId Lookup resolved at insert time, then Activity history (Email activities and act_activity_log__c records chunked by month to manage API volume), then Custom Data entities with their inter-entity Lookup relationships resolved, then Form submission records. Each phase emits a row-count reconciliation report. Any quarantined records (duplicates, missing required fields) are resolved in coordination with the customer before the next phase begins.

Cutover, delta migration, and Program documentation handoff

We freeze writes to the Act-On environment during cutover, run a final delta migration of any records modified during the migration window, then mark the Microsoft Dynamics 365 Sales org as the system of record. We deliver the written Program map documenting each Act-On Program's sequence steps, triggers, and conditions for the customer's admin to rebuild in Microsoft Dynamics 365 Sales Playbooks or Power Automate. We support a five-business-day hypercare window for reconciliation issues. We do not configure Microsoft 365 integration, rebuild Automations, or provide Dynamics 365 admin training as part of the migration scope; these are separate engagements.