Migrate from OPEX 365 CRM to Twenty CRM

OPEX 365 CRM Contact records map to Twenty Person objects. We map fullname, emailaddress1, telephone1, address fields, and lifecycle-related properties to their Twenty equivalents. Owner assignment resolves by email match against Twenty workspace members. If the customer's OPEX 365 CRM uses custom contact properties (e.g., custom fields from Dataverse), we create matching custom fields in Twenty's Data Model before import using the Metadata API. The Person.recordId is stored for use as a lookup target by activity and opportunity records.

OPEX 365 CRM Account records map to Twenty Company objects. We map name, website, industry, numberofemployees, annualrevenue, address fields, and custom account properties. Account is created before any Person import so that the Person.companyId lookup is satisfied at the moment of Person insert. The company record is also the dedupe key for parent-child hierarchy preservation.

OPEX 365 CRM Opportunity records map to Twenty Opportunity objects. Pipeline stage labels and deal amount migrate directly. We preserve estimatedclosedate, closeprobability (computed from stage mapping), and opportunity type. The opportunity.personId and opportunity.companyId lookups resolve to the migrated Person and Company records respectively. Stage names are stored as-is; the customer's admin recreates pipeline stages in Twenty after migration.

OPEX 365 CRM Lead records that are unqualified prospects (not yet converted to Contact) map to Twenty Person records. Leads that have already converted in OPEX 365 CRM are handled as their target object type (Contact or Account). Where the customer uses Leads as a separate queue, we flag the unconverted Lead count during scoping and either migrate them as Person records with a lead_source property or recommend recreating them as a custom Pipeline view. The choice is made during scoping based on the customer's process.

OPEX 365 CRM Cases (incident entity) have no direct standard equivalent in Twenty CRM. We map the incident to a custom object (e.g., SupportCase) created via Twenty's Metadata API before migration, with fields for case number, status, priority, subject, originating contact, and account. If Twenty's standard Comments model on Person or Company is sufficient for the customer's support workflow, we migrate Cases as Comments linked to the corresponding Person or Company record instead.

OPEX 365 CRM Activities (activitypointer records) map to Twenty Task objects. The polymorphic activityparty references are resolved to the target Person or Company ID during transformation. We preserve activity type (email, call, task, meeting), timestamp, subject, description, duration (for calls), and outcome. TaskAssignee resolves to the migrated Owner/User. Activity records with no resolvable target party are flagged for manual assignment review post-migration.

OPEX 365 CRM Notes stored as annotation entities with base64-encoded file content require separate extraction using the Dataverse RetrieveContent discharge API. We extract binary attachment bodies to staging blob storage, then remap them as file references on Twenty Task records of note type. The note body text migrates as the Task description, and any file attachments are uploaded to Twenty's attachment storage and linked to the parent record (Person, Company, or Opportunity). This is a distinct extraction step from the standard record migration.

OPEX 365 CRM Product records with pricing linked via productpricelevel entities map to a custom Product object in Twenty created via the Metadata API. Product name, SKU, and pricing tier information migrate with pricing stored as custom fields. Bundle structures are noted as a separate reassembly task for the customer's admin post-migration since Twenty's standard Opportunity model does not include line-item bundles.

OPEX 365 CRM User records map to Twenty workspace members by email address match. Owner assignments on Contact, Account, Opportunity, and Activity records resolve to the corresponding Twenty user. Any OPEX 365 CRM owner with no matching email in the Twenty workspace goes to a reconciliation queue; the customer provisions the missing user before record import resumes. Inactive OPEX 365 CRM users can be migrated as inactive Twenty members or archived with their record assignments reassigned.

OPEX 365 CRM custom entities discovered via the Dataverse EntityDefinitions endpoint map to Twenty custom objects created via the Metadata API. We enumerate all custom entity schemas during pre-migration discovery, generate matching field definitions with type conversion (Dataverse OptionSet becomes Twenty select, Dataverse Lookup becomes Twenty relation, etc.), then import the data. Lookup relationships between custom entities and standard entities (Contact, Account) are preserved by resolving the parent record ID before the child record inserts.

OPEX 365 CRM pipeline and stage metadata does not migrate automatically and is not transferred as code. We document the source pipeline structure (pipeline names, stage labels, stage order, stage probabilities) in a written configuration guide. The customer's admin recreates these in Twenty's pipeline settings after migration. Closed-won and closed-lost stage mappings are preserved in the documentation for accurate reporting continuity.