Migrate from Mothernode to Twenty CRM

Mothernode Customer records map to Twenty CRM Company. The customer_id from the GET /customers response becomes the Company identifier. Customer name maps to the Company display name, and the associated address, phone, and domain fields map to Twenty's Company fields. We resolve the Company insert order so that any subsequent Contact or Opportunity import can satisfy the Company lookup at the moment of record creation. Mothernode Enterprise customers with Project Folder or Job Center associations have these flagged for manual export because the API availability is not confirmed in the public documentation.

Mothernode Contact records map to Twenty CRM Person. We use email as the primary dedupe key during import and cross-reference the associated customer_id to link the Person to the pre-inserted Company via the Company link field in Twenty's Person schema. Contact first name, last name, phone, email, title, and address fields map directly. Custom fields detected in the API response payload during the extraction phase migrate to Twenty custom fields that we pre-create via the /metadata API before the Person import begins.

Mothernode's FAQ confirms that Leads and Opportunities are distinct objects with different meanings in the sales workflow. Both are returned from the shared GET /leads-and-opportunities endpoint with a record type indicator in the response payload. We separate Leads from Opportunities at extraction time using this indicator. Leads with early-stage semantics (sourced, uncontacted) map to Twenty Person records with a Lead opportunity status. We preserve the original Mothernode record type in a custom field on the Person for audit. Customers who have repurposed these fields non-standardly require a pre-import validation call to confirm the mapping table before data moves.

Mothernode Opportunities share the same API endpoint as Leads and are separated using the record type indicator. We map Opportunity fields directly to Twenty CRM Opportunity: name, amount, close date, stage, owner assignment, and associated Contact and Customer references. The Customer reference resolves to the Twenty Company record via the lookup relationship established during the Company import phase. Pipeline stage names and values from Mothernode's configuration migrate to Twenty's Opportunity pipeline stage configuration, which we set up via Twenty's pipeline settings before Opportunity records are inserted.

Mothernode Notes accessible via the Notes/Events API endpoint migrate to Twenty CRM Comments. We extract note body content, associated entity IDs (Contact or Opportunity), created timestamp, and author attribution. Comments in Twenty are linked to the target record (Person or Opportunity) via the Twenty ActivityComment schema. We set the ActivityDate to the original Mothernode timestamp to preserve chronological ordering in the activity timeline.

Mothernode Events share the Notes/Events API endpoint with Notes. We extract event type, start and end datetime, duration, location, and the associated Contact or Opportunity link. Calendar-bound events migrate to Twenty CRM Activity records with start datetime, end datetime, and the linked Person or Opportunity preserved. The event type indicator maps to an Activity type field in Twenty.

Mothernode Invoices migrate to a Twenty CRM custom object named Invoice that we pre-create via the /metadata API before import. The custom object includes fields for invoice number, issue date, due date, line items, total amount, status, and the associated Customer reference (resolved to the Twenty Company record). Invoice line items migrate as child records under the Invoice custom object. We flag any billing configurations that are Mothernode-specific (progress invoicing, which is Enterprise-only in Mothernode) as requiring admin review post-migration.

Owner references on Mothernode Contact, Opportunity, and Event records (owner_id in the API payload) map to Twenty CRM WorkspaceMember records. The Mothernode API does not expose a dedicated Users endpoint, so we extract distinct owner_id values from the records themselves and resolve them by email match against the Twenty workspace members table. Any owner without a matching WorkspaceMember goes to a reconciliation queue for the customer's admin to provision before record import resumes. The migration cannot proceed past Opportunity and Contact imports without resolved OwnerId references.

Custom fields on Mothernode Contacts, Customers, Leads, and Opportunities are not explicitly documented in the API reference. We probe the API response schema during extraction to identify any non-standard fields beyond the documented field set. Each custom field discovered is pre-created in Twenty CRM via the /metadata API with a matching field type (text, number, date, picklist, checkbox, or currency). Custom field values migrate as part of the parent object import. Customer input is required during scoping to confirm which custom fields carry business-critical data and which can be dropped.

Opportunity records in Mothernode carry a pipeline stage value that governs the sales workflow state. The stage names and count are customer-specific and vary by Mothernode configuration. We extract all stage values from the source data, map them to Twenty's pipeline stage configuration, and pre-create the pipeline with the same stage sequence before any Opportunity records are written. Stage order and probability percentages migrate where they exist in the source data. Customers with non-standard stage repurposing require a pre-import review call to confirm the stage mapping table.

Project Folders are gated behind Mothernode Enterprise and their API availability is not confirmed in the public API documentation. We attempt to probe these endpoints during the extraction phase. If the API returns 403 or 404, we flag Project Folders as requiring a manual UI export and do not include them in the automated migration scope. Customers with heavy reliance on Project Folders should schedule a parallel manual export step and plan to recreate the structure in Twenty CRM or a separate project management tool.

Job Center Modules handle real-time job tracking for manufacturing or service operations and are an Enterprise-tier feature. The public API reference does not cover these objects. We flag Job records as requiring a manual export and do not attempt automated migration. If the customer uses Twenty CRM's self-hosted deployment and has custom object requirements for job tracking, we recommend creating a Jobs custom object via Twenty's /metadata API post-migration and populating it from the manual export.