CRM migration
Field-level mapping, validation, and rollback between Agillic and Microsoft Dynamics 365 Sales . We move data and schema; workflows are rebuilt natively in Microsoft Dynamics 365 Sales .
Agillic
Source
Microsoft Dynamics 365 Sales
Destination
Compatibility
6 of 10
objects map 1:1 between Agillic and Microsoft Dynamics 365 Sales .
Complexity
BStandard
Timeline
2-4 weeks
Overview
Moving from Agillic to Microsoft Microsoft Dynamics 365 Sales is a structural migration from a marketing-centric custom data model into a structured sales CRM built on Dataverse. Agillic's primary entity is the Recipient — an arbitrary-schema person record with any client-defined custom fields — while Microsoft Dynamics 365 Sales separates prospects into Leads and qualified buyers into Contacts attached to Accounts, with a full Opportunity pipeline. We enumerate every active recipient property during discovery (no fixed field list exists in Agillic), design the destination Contact, Account, and custom entity schema, and import records in dependency order. Activity history (sends, opens, clicks, SMS, events) migrates to Dynamics 365 Task and Event records, but only if Flow Execution ID was explicitly enabled under Settings > System Settings > Export > Activity Exports before export. Agillic Flows, audience segments to Google and Meta, templates, and content blocks are not migratable as code; we deliver a written inventory of these for the customer to rebuild in Power Automate or Microsoft Dynamics 365 Sales .
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Source platform
Agillic platform overview
Scorecard, SWOT, gotchas, and pricing for Agillic.
Destination platform
Microsoft Dynamics 365 Sales platform overview
Scorecard, SWOT, gotchas, and pricing for Microsoft Dynamics 365 Sales .
Data migration guide
The complete Microsoft Dynamics 365 Sales migration guide
Data model, import mechanisms, field mapping strategy, pitfalls, and cutover — by the engineers running it.
Destination checklist
Microsoft Dynamics 365 Sales migration checklist
Pre- and post-cutover tasks for moving onto Microsoft Dynamics 365 Sales .
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Agillic object lands in Microsoft Dynamics 365 Sales , including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Agillic
Recipient
Microsoft Dynamics 365 Sales
Lead or Contact (split required)
1:manyAgillic Recipients with a subscriber or prospect lifecycle stage map to Microsoft Dynamics 365 Lead. Recipients with a confirmed buyer, customer, or evangelist lifecycle stage map to Dynamics 365 Contact tied to an Account. We compute the split at migration time using the customer's recipient property values, and preserve the original Agillic lifecycle stage in a custom field agillic_lifecycle_stage__c on both Lead and Contact for audit and reporting continuity.
Agillic
Company (Agillic)
Microsoft Dynamics 365 Sales
Account
1:1Agillic Company records — whether stored as a dedicated entity or embedded in Recipient fields — map to Microsoft Dynamics 365 Account. The Company name becomes Account.Name, city and country map to BillingCity and BillingCountry, and postal code maps to BillingPostalCode. Account is created before any Contact import so that the CustomerId lookup relationship is satisfied at the moment of Contact insert.
Agillic
Recipients Export (bulk snapshot)
Microsoft Dynamics 365 Sales
Lead / Contact (bulk import)
1:1Agillic's Recipients Export feature generates a structured file of all recipient records and their current field values. We use this as a baseline for full-contact migrations, then reconcile against API data for any fields not included in the export format. The export file feeds directly into the Dynamics 365 Data Management framework or Dataverse bulk import.
Agillic
Activity Log (sends, opens, clicks, SMS, events)
Microsoft Dynamics 365 Sales
Task and Event
1:1Every Agillic send, open, click, bounce, SMS delivery, and event trigger stored as an Activity record maps to a Dynamics 365 Task (for email, SMS, and task-type activities) or Event (for meeting and event-type activities). The Agillic activity type, timestamp, recipient ID, and channel are preserved as Task fields, and the WhatId or RegardingObjectId points to the migrated Contact or Lead.
Agillic
Activity Export (bundled file export)
Microsoft Dynamics 365 Sales
Task / Event (bulk import)
1:1Agillic's Activity Export bundles all events for a given date range across channels into a structured file. We schedule exports spanning the customer's entire history, parse the file into Task and Event rows, and bulk-import via the Dataverse bulk import API. If Flow Execution ID was enabled, we preserve it in a custom field agillic_flow_execution_id__c on the Activity record for journey reconstruction.
Agillic
Flow Execution ID
Microsoft Dynamics 365 Sales
agillic_flow_execution_id__c (custom field)
lossyThe Flow Execution ID uniquely identifies each Agillic campaign trigger instance and is appended to Activity Exports only when explicitly enabled under Settings > System Settings > Export > Activity Exports. We store this ID in a custom field on Task and Event in Dynamics 365 so that activity records can be matched back to specific Agillic campaign runs. If this setting was off during the export period, the Flow Execution ID data is permanently absent and cannot be reconstructed.
Agillic
Global Data Table
Microsoft Dynamics 365 Sales
Custom Entity (Dataverse)
1:1Agillic Global Data Tables are custom relational data structures referenced within Flows. We export table schemas and all row data, then create equivalent custom entities in Dataverse with the same column structure and data types. Lookup relationships between tables become Dataverse lookup fields on the custom entity. The customer rebuilds any data table query logic as Dataverse views or Power Apps canvas components post-migration.
Agillic
Reusable Content Block
Microsoft Dynamics 365 Sales
Web Resource or Template (Dataverse)
lossyAgillic Content Blocks are modular HTML or text fragments used across templates. We export block content and metadata as Web Resources in Dataverse. Recombination in Dynamics 365 email templates or Power Automate approval notifications requires content refactoring. HTML blocks migrate as text strings; the customer's marketing or admin team rebuilds the visual placement in Dynamics 365 email templates.
Agillic
Template
Microsoft Dynamics 365 Sales
Dynamics 365 Email Template or Power Automate
lossyAgillic Templates define layout and dynamic content fields for email, SMS, print, and push channels. We export template content and field mappings as reference documents. HTML-based templates require conversion to the destination system's template format. Dynamics 365 email templates are rebuilt as Email Template records; SMS templates migrate as Power Automate approval message definitions or custom entities.
Agillic
Owner
Microsoft Dynamics 365 Sales
User
1:1Agillic Owner records map to Microsoft Dynamics 365 User by email address. We resolve each Owner referenced on a Recipient, Activity, or Global Data Table record and match to the destination User. Owners without a matching User go to a reconciliation queue for the customer's admin to provision before record import resumes.
| Agillic | Microsoft Dynamics 365 Sales | Compatibility | |
|---|---|---|---|
| Recipient | Lead or Contact (split required)1:many | Fully supported | |
| Company (Agillic) | Account1:1 | Fully supported | |
| Recipients Export (bulk snapshot) | Lead / Contact (bulk import)1:1 | Fully supported | |
| Activity Log (sends, opens, clicks, SMS, events) | Task and Event1:1 | Fully supported | |
| Activity Export (bundled file export) | Task / Event (bulk import)1:1 | Fully supported | |
| Flow Execution ID | agillic_flow_execution_id__c (custom field)lossy | Fully supported | |
| Global Data Table | Custom Entity (Dataverse)1:1 | Fully supported | |
| Reusable Content Block | Web Resource or Template (Dataverse)lossy | Fully supported | |
| Template | Dynamics 365 Email Template or Power Automatelossy | Fully supported | |
| Owner | User1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Agillic gotchas
Undocumented API rate limits complicate bulk migration planning
Fully custom schema requires mandatory field enumeration during discovery
Flows are not exportable as portable workflow definitions
Activity Export requires explicit Flow Execution ID enablement
Microsoft Dynamics 365 Sales gotchas
Professional tier 15-table custom table limit blocks migrations
October 2024 pricing increase applies at renewal for all customers
Custom fields must be created in the UI before API writes
Power Platform request limits apply to bulk migrations
Activity records orphaned to inactive owners fail silently
Pair-specific challenges
Migration approach
Discovery and schema enumeration
We audit the Agillic instance for all active recipient properties via the Recipient API and a Recipients Export, capturing every custom field defined on the Recipient entity. We document Global Data Table schemas, Activity Export format settings, and Flow names. We review the Dynamics 365 destination org (or provision a Sandbox if none exists) and enumerate which standard and custom entities are available. The discovery output is a written migration scope document including the complete recipient field inventory, the recommended Dynamics 365 field type for each custom property, and the Agillic Flow inventory requiring rebuild.
Destination schema design
We design the Dynamics 365 destination schema in a Sandbox environment. This includes creating custom fields on Contact and Lead for every Agillic recipient property, creating custom entities in Dataverse for each Global Data Table, defining option sets for picklist-type properties, and creating lookup relationships between custom entities. We configure Lead and Contact field mappings for the recipient split. The schema is validated in Sandbox before production deployment.
Data extraction with rate limit handling
We extract Recipients via the Agillic REST API with exponential backoff and daily request tracking. For volumes exceeding API quotas, we switch to the WebDAV/SFTP Recipients Export as the primary ingestion path. Activity history is extracted via the Activity Export file in scheduled date-range bundles. We confirm that Flow Execution ID inclusion is enabled before extracting Activity data. All source data is staged in a secure migration workspace with a manifest of record counts per object.
Sandbox migration and reconciliation
We run a full migration into a Dynamics 365 Sandbox using production-like data volumes. The customer's team reconciles record counts (Leads in, Contacts in, Accounts in, Activities in), spot-checks 25-50 random records against the Agillic source, and validates that custom field values are correctly populated in Dynamics 365. The Agillic Flow inventory document is reviewed against the Dynamics 365 schema to confirm every required field is present. Schema corrections happen in Sandbox before production migration begins.
Owner reconciliation and User provisioning
We extract every distinct Agillic Owner referenced on Recipient, Activity, and Global Data Table records and match by email against the Dynamics 365 destination org's User table. Owners without a matching User go to a reconciliation queue. The customer's Dynamics 365 admin provisions any missing Users. Migration cannot proceed past this step because OwnerId references are required on most standard entities in Dynamics 365.
Production migration in dependency order
We run production migration in record-dependency order: Accounts (from Agillic Companies), Contacts and Leads (with the Recipients split applied and AccountId resolved for Contacts), custom entities for Global Data Tables (with parent-record lookups resolved), then Activity history via the Dataverse bulk import API. Each phase emits a row-count reconciliation report before the next phase begins. We freeze Agillic writes during cutover and run a final delta migration of any records modified during the migration window.
Cutover, validation, and Flow rebuild handoff
We enable Microsoft Dynamics 365 Sales as the system of record and deliver the Agillic Flow inventory document to the customer's admin team. The document lists each Flow with its name, trigger event, conditions, and actions, with a recommended Dynamics 365 Workflow or Power Automate equivalent. We support a one-week hypercare window for reconciliation issues. Workflow rebuild in Power Automate or Dynamics 365 native workflows is outside migration scope and is either handled by the customer's admin team or as a separate engagement.
Platform deep dives
Agillic
Source
Strengths
Weaknesses
Microsoft Dynamics 365 Sales
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. All 8 core objects map 1:1 between Agillic and Microsoft Dynamics 365 Sales .
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Agillic and Microsoft Dynamics 365 Sales .
Object compatibility
All 8 core objects map 1:1 between Agillic and Microsoft Dynamics 365 Sales .
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
Agillic: Not publicly documented — limited per production instance per day.
Data volume sensitivity
Agillic doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Agillic to Microsoft Dynamics 365 Sales migration scoping. Not seeing yours? Book a call.
Walk through your Agillic to Microsoft Dynamics 365 Sales migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Agillic
Other ways to arrive at Microsoft Dynamics 365 Sales
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.