Migrate from Access CRM to Twenty CRM

Access CRM Contacts map directly to Twenty CRM People. Name, email, phone, address, and owner assignment migrate as standard fields. We resolve the Access CRM owner reference by email against Twenty CRM workspace Members and create placeholder Person records for any owner without a matching Twenty user.

Access CRM Company records map to Twenty CRM Company. The organisation-level data (name, domain, industry, employee count, address) migrates directly. Parent-child hierarchy in Access CRM migrates as a flat organisation tree in Twenty, and we flag any circular references during the scoping audit so they do not cause import loops.

Access CRM Opportunities carry Worst/Likely/Best monetary values and stage-based probability logic. These map to Twenty CRM Opportunities, but the three-value probability model has no native equivalent in Twenty. We preserve Worst/Likely/Best as custom Opportunity fields and set the primary Opportunity amount to the Likely value unless the customer specifies otherwise during scoping.

Access CRM Kanban pipelines with tenant-defined stage names require explicit mapping to Twenty CRM pipeline configuration. We capture every distinct stage name during scoping, produce a stage-mapping matrix, and configure the Twenty pipeline stages before any records are imported. Stages with no mapping direction default to an Archive pipeline unless the customer explicitly directs otherwise.

Access CRM Cases (problem-tracking with open-through-resolution lifecycle) do not have a native equivalent in Twenty CRM. We create a Case custom object in Twenty during schema setup, define custom fields for status, priority, owner, and description, and map the Access CRM case lifecycle to the custom object's status field. If the customer also uses Twenty's task and note objects for tracking, Cases can alternatively be modelled as Opportunities with a specific record type.

Access CRM Activities associated with Contacts and Opportunities migrate as Task records or Note records in Twenty CRM. Call disposition and duration migrate to custom Task fields. Meeting start and end times, location, and attendees map to the corresponding Task fields. The original timestamp is preserved on the ActivityDate field so the timeline ordering is intact in Twenty.

Access CRM tenant-specific custom fields are extracted via the admin knowledge base and cross-referenced against the full field manifest. Each custom field is pre-created in Twenty CRM Settings → Data Model with the appropriate type (text, number, date, select, multi-select, relation) before any records are imported. Fields that reference Access-specific picklist values are normalised to text or select fields in Twenty as appropriate.

Access CRM web-enquiry forms feed leads into Opportunities or raw lead records. Form field structures are configurable per tenant. We treat each form as a custom object set or as additional custom fields on the People object depending on the form's complexity, and map the enquiry source and field data accordingly. The customer chooses the modelling approach during scoping.

Access CRM User records (name, email, role) are migratable. We map the Access CRM owner/User assignment on each Contact, Company, Opportunity, and Activity to the corresponding workspace Member in Twenty by email match. Users without a matching Twenty workspace Member are held in a reconciliation queue for the customer's admin to provision before the record import phase begins.

Access CRM knowledge-base articles and customer self-service portal content have no standard counterpart in Twenty CRM. We export KB content as a structured HTML or JSON package and deliver it alongside the CRM record migration so the customer can re-import to their chosen knowledge-base platform (Twenty does not include a native KB module). We do not map KB articles to any Twenty CRM object.

Access CRM records may carry references to workers, clients, or care episodes in Access Pay & Bill, Access Elite, or Servelec. These cross-module IDs cannot be imported into Twenty CRM. We flag every external Access module reference during the scoping audit, preserve the original module and ID in a custom text field on the affected record, and either create a stub record or strip the reference depending on the customer's preference documented during scoping.