Migrate from Twenty CRM to Microsoft Dynamics 365 Sales

Twenty Companies map directly to Dynamics 365 Account. The domain field in Twenty becomes the Account Website field and is used as a deduplication key during import. Account is imported first in the migration sequence because both People (via companyId) and Opportunities reference it. We pre-create the destination Account schema including industry, size, and location fields before any dependent imports begin.

Twenty People map to Dynamics 365 Contact. Email is the unique reference key used for deduplication matching. We resolve the companyId foreign key against imported Account records to populate the Contact's parentcustomerid_account AccountId lookup at migration time. Job title, phone, and name fields map directly to typed Contact fields. Any People record referencing a companyId that fails resolution is held in a reconciliation queue.

Twenty Opportunities map to Dynamics 365 Opportunity. We map stage name values explicitly to Microsoft Dynamics 365 Sales Process stage values to avoid silent mismatches. Amount and close date transfer directly. We resolve the companyId to AccountId and personId (if populated) to ContactId before insert. Closed-Won and Closed-Lost reason fields migrate from Twenty custom fields if they exist.

Twenty Tasks map to Dynamics 365 Task. We preserve the record-to-task relation by resolving the target record's ID in Dynamics 365 and setting the WhatId (related to) or WhoId (related contacts) reference accordingly. Title, due date, completion status, and assignee migrate with status mapped to Dynamics 365 Task Statecode and Priority.

Twenty Notes map to Dynamics 365 Annotation (the Dataverse entity backing the Notes wall on Account, Contact, and Opportunity forms). We map the relational target to the corresponding record ID in Dynamics 365 and migrate note body content as the Annotation's notetext field. Note attachments migrate as Dynamics 365's documentattachment entity linked to the Annotation.

Twenty Custom Objects migrate to Dataverse custom entities. We pre-create the destination schema including all custom fields, lookup relationships to standard entities (Account, Contact, Opportunity), and picklist option sets before any data import. Customer must hold a Dynamics 365 Enterprise license or a Dataverse database license to host custom entities. Self-hosted Twenty deployments may have Custom Objects that have no direct Dynamics 365 equivalent; we document these as custom entity requirements during scoping.

Twenty stores call, email, and meeting history as engagement records linked to People and Companies. We map call engagements to Dynamics 365 Task with TaskSubtype=Call, email to EmailMessage records linked to ActivityPointer, and meetings to Event records. Activity timestamps are preserved by setting ActivityDate to the original Twenty timestamp. Engagement records with no matching Contact or Account in Dynamics 365 are held in a reconciliation queue.

Twenty Owner references on People, Companies, Opportunities, and Tasks map to Dynamics 365 User by email match. We extract all distinct ownerId values from the Twenty export and resolve against the destination org's User table. Any owner without a matching Dynamics 365 User goes to a reconciliation queue for the customer's admin to provision before record import resumes.