Migrate from Anthill CRM to Twenty CRM

Anthill Enquiries are the primary intake object and represent deals at various stages of the workflow stream. Each Enquiry maps to a Twenty Opportunity. We extract the current workflow stream state and map it to a Twenty Opportunity.stage value using a document we generate during scoping that maps each Anthill workflow state to its equivalent Twenty stage. The Enquiry's name becomes Opportunity.name, and we resolve the linked Customer to a Twenty Person and Company at migration time.

Anthill Customer records hold both contact and company data in a flat schema. We split these into Twenty's separate Company (the organisation) and Person (the individual) objects. The customer's business name and address fields map to Company; the contact's name, email, and phone map to Person. We preserve the original Anthill Customer ID in a custom field on both records for reconciliation and audit purposes.

Anthill Activities tied to Enquiries and Customers represent touchpoints across the customer journey. We map activity type (call, email, meeting, task) to the equivalent Twenty object: calls become Tasks with the call subtype, meetings become Events, and standalone tasks become Tasks. Activity timestamps and content are preserved. Anthill does not expose a bulk activity-history endpoint, so we paginate through the API and cross-validate against any CSV export available for the object.

Anthill Workflows define the customer interaction process and allocate actions to teams. Because workflows are configuration-heavy and contain Anthill-specific state triggers and team assignments, we do not migrate them as executable objects. Instead we extract the stage definitions from every active workflow and generate a workflow-to-pipeline mapping document. This document maps each Anthill workflow state name to a Twenty Opportunity stage value with a description of the transition logic, which the customer uses to configure their pipeline in Twenty after migration.

Anthill represents deal progression through workflow stream states rather than column-based pipeline stages. We extract every distinct state name from the active workflow definitions, normalise them into a clean stage sequence, and map them to Twenty Opportunity stage values. The customer defines the stage names and probability percentages in Twenty during setup, informed by our mapping document. Closed-won and closed-lost states from Anthill become the terminal stages in Twenty's pipeline.

Anthill supports custom fields per object but does not publish a field reference catalogue. We pull the actual field inventory by introspecting the API responses during discovery, noting picklist values, data types, and object associations. Each discovered custom property is mapped to a Twenty custom field. Picklist values are cross-referenced against any matching Twenty field options. Fields with no destination match are flagged for the customer to decide whether to carry them forward as free-text fields or archive them.

Anthill dashboards are stored as internal configuration files in the platform's visualisation engine and are not exposed via SOAP or JSON API. We cannot export them automatically. We perform a dashboard audit during discovery: we document each live dashboard's layout, metric definitions, filter set, data source objects, and refresh behaviour from the running system. The customer receives a written specification for each dashboard to rebuild in Twenty using the query builder. Dashboard rebuild is a manual step performed by the customer post-migration and is outside the data-migration scope.

Anthill Automations trigger personalised notifications and email or SMS sequences based on workflow state transitions. Because automations are workflow-scoped and reference Anthill-specific contact property names, they cannot migrate as executable logic. We extract every active automation and document its trigger conditions, actions, and target audience. The customer receives an automation inventory with a description of each rule's purpose, which their Twenty admin uses to configure equivalent Workflow actions in Twenty post-migration.

Anthill Users are organised by team (Sales, Admin, Support) with ownership assigned to records. We map Users and their team associations to Twenty Users. Anthill does not expose a dedicated user-list endpoint, so we derive the user list from the owner fields on Enquiry, Customer, and Activity records. We match by email address. Any Anthill User without a corresponding Twenty User goes to a reconciliation queue for the customer's admin to provision before record import continues.

Anthill allocates workflow actions to Sales, Admin, and Support teams. These team assignments define which team members can act on a record at each workflow state. We extract the team structure from the workflow definitions and map it to Twenty's workspace and role model. The customer defines Twenty User Roles and workspace permissions during their Twenty setup, informed by our team-assignment mapping document. This is a configuration step rather than a data migration step.

Each Anthill Enquiry is created through a workflow stream and carries the workflow identifier and current stream position. We preserve this context by storing the Anthill workflow name and stream state as custom fields on the migrated Twenty Opportunity. This allows the customer to audit the original workflow lineage and reconstruct team accountability in Twenty if needed.