CRM migration

Migrate from Agillic to Microsoft Dynamics 365 Sales

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 logo

Agillic

Source

Microsoft Dynamics 365 Sales

Destination

Microsoft Dynamics 365 Sales  logo

Compatibility

60%

6 of 10

objects map 1:1 between Agillic and Microsoft Dynamics 365 Sales .

Complexity

BStandard

Timeline

2-4 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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 .

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

Agillic logo

Agillic

What's pushing teams away

  • Rate limits and API quotas are not publicly documented, creating uncertainty for teams planning large-scale data migrations or integrations.
  • The platform's heavy reliance on developer configuration for data synchronisation, custom flow elements, and content templates means marketing teams without technical support encounter bottlenecks.
  • Complex workflow logic built by developers becomes difficult for non-technical marketers to modify independently, limiting operational agility.
  • Exporting Activity data requires external analysis tools; Agillic itself lacks built-in advanced analytics dashboards for post-campaign insight generation.

Choosing

Microsoft Dynamics 365 Sales  logo

Microsoft Dynamics 365 Sales

What's pulling them in

  • Deep Microsoft 365, Teams, and Outlook integration makes Microsoft Dynamics 365 Sales a natural fit for Microsoft-first organizations already invested in that ecosystem
  • Sales Enterprise and Premium tiers offer unlimited custom tables and advanced AI-driven forecasting and predictive analytics not available in lower tiers
  • Professional tier pricing at $65 per user per month offers a lower entry cost than Salesforce for SMB teams with straightforward CRM needs
  • Flexible customization options allow businesses to build bespoke apps, tailor forms and views, and integrate with other Dynamics 365 modules
  • Microsoft Copilot AI tools are embedded directly into the sales workflow on Enterprise and Premium, automating routine tasks and providing deal intelligence

Object mapping

How Agillic objects map to Microsoft Dynamics 365 Sales

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

maps to

Microsoft Dynamics 365 Sales

Lead or Contact (split required)

1:many
Fully supported

Agillic 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)

maps to

Microsoft Dynamics 365 Sales

Account

1:1
Fully supported

Agillic 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)

maps to

Microsoft Dynamics 365 Sales

Lead / Contact (bulk import)

1:1
Fully supported

Agillic'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)

maps to

Microsoft Dynamics 365 Sales

Task and Event

1:1
Fully supported

Every 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)

maps to

Microsoft Dynamics 365 Sales

Task / Event (bulk import)

1:1
Fully supported

Agillic'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

maps to

Microsoft Dynamics 365 Sales

agillic_flow_execution_id__c (custom field)

lossy
Fully supported

The 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

maps to

Microsoft Dynamics 365 Sales

Custom Entity (Dataverse)

1:1
Fully supported

Agillic 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

maps to

Microsoft Dynamics 365 Sales

Web Resource or Template (Dataverse)

lossy
Fully supported

Agillic 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

maps to

Microsoft Dynamics 365 Sales

Dynamics 365 Email Template or Power Automate

lossy
Fully supported

Agillic 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

maps to

Microsoft Dynamics 365 Sales

User

1:1
Fully supported

Agillic 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.

Gotchas + challenges

What specifically takes care here

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 logo

Agillic gotchas

High

Undocumented API rate limits complicate bulk migration planning

High

Fully custom schema requires mandatory field enumeration during discovery

Medium

Flows are not exportable as portable workflow definitions

Medium

Activity Export requires explicit Flow Execution ID enablement

Microsoft Dynamics 365 Sales  logo

Microsoft Dynamics 365 Sales gotchas

High

Professional tier 15-table custom table limit blocks migrations

High

October 2024 pricing increase applies at renewal for all customers

Medium

Custom fields must be created in the UI before API writes

Medium

Power Platform request limits apply to bulk migrations

Medium

Activity records orphaned to inactive owners fail silently

Pair-specific challenges

  • Custom schema requires mandatory field enumeration during discovery

    Agillic allows clients to define arbitrary custom properties on Recipients with no fixed data model. There is no single documented list of all possible fields — each client's schema is unique. We cannot begin field mapping until we have enumerated every active recipient property via the Recipient API or a Recipients Export. We run a full schema discovery pass before any other migration work. Missing fields during migration results in silent data loss for those attributes; they will not appear in Dynamics 365 and cannot be retrofitted from the source without a re-export. The customer must confirm the complete list of active fields from their Agillic instance before migration begins.

  • Flow Execution ID absent if not explicitly enabled before export

    The Flow Execution ID is not included in Agillic Activity Exports by default — it must be explicitly enabled under Settings > System Settings > Export > Activity Exports. If this setting was off during the customer's historical export period, we lose the ability to tie activity records to specific campaign runs in Dynamics 365. We check this setting on both staging and production during discovery and request the client enables it before exporting. If it was off historically, the Flow Execution ID data is permanently absent and we store a flag in the migration record noting this limitation.

  • Agillic Flows cannot migrate to Dynamics 365 Workflows

    Agillic Flows (campaign automation workflows) are stored as internal execution configurations and there is no documented export endpoint to retrieve flow logic as a portable file. We can export Flow names, associated trigger events, and Activity history tied to a Flow Execution ID, but the actual branching logic, conditions, and wait-step configurations must be manually recreated in Dynamics 365 via the native workflow designer or Power Automate. This is a re-implementation effort, not a data migration. We deliver a written Flow inventory with trigger and action documentation for the customer's admin to rebuild post-migration.

  • Agillic API rate limits are not publicly documented

    Agillic's REST API is rate limited per production instance per day, but specific thresholds are not publicly documented. During migration, if we exceed these limits the API returns 429 errors and stops accepting requests. We handle this by implementing exponential backoff and using WebDAV/SFTP Activity Export endpoints as a parallel ingestion path when API calls are throttled. We request Agillic support to confirm current rate limit values before scoping a large-volume migration. Without confirmed limits, we size batches conservatively which extends migration duration.

  • Dynamics 365 requires schema pre-configuration before data import

    Microsoft Microsoft Dynamics 365 Sales requires that custom entities, custom fields, option sets, and lookup relationships are created and published before any data import. Unlike some platforms that accept custom field creation during import, Dynamics 365 enforces a strict schema-first approach. We design and deploy the complete destination schema into a Sandbox org before production migration begins. Any schema changes after data import require a separate deployment and re-import of affected records. This adds a planning step not present in Agillic, which accepts arbitrary new fields at any time.

Migration approach

Six steps for a successful Agillic to Microsoft Dynamics 365 Sales data migration

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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

Context on both ends of the pair

Agillic logo

Agillic

Source

Strengths

  • Fully customisable recipient schema with no fixed field constraints.
  • Native omnichannel support: email, SMS, push, print, paid media, and point-of-sale.
  • GDPR compliance built-in with annual independent security audits.
  • Staging and production separation for safe campaign testing.
  • Real-time audience activation to Google and Meta.

Weaknesses

  • API rate limits are not publicly documented, complicating migration planning.
  • Heavy developer dependency for data sync, custom flows, and content templates.
  • No built-in advanced analytics — requires external BI tools for activity analysis.
  • Workflows (Flows) are tightly coupled to Agillic's execution engine, making cross-platform migration requires reimplementation.
Microsoft Dynamics 365 Sales  logo

Microsoft Dynamics 365 Sales

Destination

Strengths

  • Native integration with Microsoft 365, Teams, Outlook, and SharePoint for unified productivity workflow
  • Unlimited custom tables and complex workflows on Enterprise tier enable deep customization for complex sales processes
  • AI-driven predictive analytics and deal intelligence on Enterprise and Premium tiers help sales teams prioritize pipeline
  • Dataverse unified data layer provides a consistent API and data model across all Dynamics 365 and Power Platform apps
  • Strong security model with Field-Level Security and Record Ownership rules for governance-conscious enterprises

Weaknesses

  • Sales Professional tier caps custom tables at 15, creating a migration ceiling for highly customized SMB environments
  • October 2024 pricing increases of $15 per user across all tiers apply to existing customers upon renewal
  • Implementation typically requires costly certified partners, adding 30–50% to total project cost
  • Updates and platform releases can disrupt customizations and plugins, requiring regression testing after each wave
  • Non-Microsoft integrations require additional configuration or middleware, limiting flexibility for heterogeneous tech stacks

Complexity grading

How hard is this migration?

Standard CRM migration. All 8 core objects map 1:1 between Agillic and Microsoft Dynamics 365 Sales .

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across Agillic and Microsoft Dynamics 365 Sales .

  • Object compatibility

    A

    All 8 core objects map 1:1 between Agillic and Microsoft Dynamics 365 Sales .

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    Agillic: Not publicly documented — limited per production instance per day.

  • Data volume sensitivity

    B

    Agillic doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your Agillic to Microsoft Dynamics 365 Sales migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about Agillic to Microsoft Dynamics 365 Sales data migrations

Answers to the questions buyers ask most during Agillic to Microsoft Dynamics 365 Sales migration scoping. Not seeing yours? Book a call.

Can't find your answer?

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 consultation

Most migrations land between two and four weeks for accounts under 15,000 Recipients, a straightforward recipient schema, and no custom Global Data Tables. Migrations with large custom schemas (50+ recipient properties), multiple Global Data Tables, or high-volume Activity exports (over 200,000 event records) move to six to ten weeks because of field enumeration, Dataverse schema design, and bulk API batching time. The migration timeline also depends on Dynamics 365 Sandbox availability and admin responsiveness for User provisioning and schema sign-off.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Agillic.
Land in Microsoft Dynamics 365 Sales , intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day