Migrate from ForceManager CRM to Twenty CRM

ForceManager Company records map directly to Twenty Organization. The standard fields (name, type, rating, address, responsible person) map to their Twenty equivalents without transformation. Custom z_-prefixed fields are stripped of the prefix and recreated as native custom fields on Organization. The company identifier is used as the dedupe key during import. Organizations are created before any Person import so that the ownership lookup is satisfied at the moment of Person insert.

ForceManager Contact records map to Twenty Person. The standard fields (name, email, phone, job title, address) map directly. Contact-to-Company association is resolved by matching the ForceManager company_id to the migrated Organization record via the foreign key established in the Organizations phase. Owner assignments are resolved by email lookup against the migrated user list. All z_ prefixed extra fields are recreated as native custom properties on Person with human-readable labels.

ForceManager Opportunity records map to Twenty Opportunity. The deal name, value, stage, responsible user, and expected close date migrate directly. ForceManager's pipeline assignment maps to a Twenty pipeline and stage set that we configure before migration. Closed-won and closed-lost reasons from ForceManager custom fields become native text fields on Opportunity in Twenty. If the customer uses ForceManager products or line items on Opportunities, we map these to Twenty's product line items if the feature is enabled, or to a custom multi-select field if not.

ForceManager Activities (calls, emails, meetings) map to Twenty's unified Timeline entries as Event records with the type field set to Call, Email, or Meeting. The activity body, date, duration, and linked Contact/Company are preserved as the event body, date, duration, and Person/Organization link respectively. Events are inserted after Person and Organization records so that the foreign key references resolve at migration time. GPS coordinates from field visit activities are stored as a text field since Twenty does not have native GPS anchoring.

ForceManager Tasks map to Twenty Event records with the type set to Task. Status (open/closed), due date, priority, and assignee are preserved. Note that Twenty's activity model does not distinguish a completed Task from a regular Event in the way ForceManager does; closed tasks are represented as completed Events rather than a separate status. We set the completedAt timestamp on the migrated Event record to preserve the completion date from the source task.

ForceManager Calendar Events (separate from Activities) map to Twenty Event records with type set to CalendarEvent. The event name, start and end time, location, and attendee list migrate directly. Attendees are resolved by email against the migrated Person records and linked as participants. If ForceManager event attendees include external contacts without migrated Person records, they are stored as a text array in a custom attendees_raw field for manual resolution post-migration.

ForceManager Sales Order and Sales Order Line entities represent a transactional layer that does not have a direct native equivalent in Twenty's core data model. Order header data (order number, date, total value, status) is mapped to custom fields on the related Opportunity. Order line items are mapped to Opportunity custom fields (product name, quantity, unit price) or stored as a structured Note attached to the Opportunity if the customer prefers to preserve the full line-item structure without modifying the Opportunity schema.

File attachments associated with Companies, Contacts, and Opportunities are not exposed via ForceManager's public REST API. We flag all attachment dependencies during scoping and advise the customer to export these manually from the ForceManager web interface before the migration window. Without this step, attachment references will not transfer. We cannot automate attachment extraction through the API and cannot guarantee completeness without customer-provided files. A post-migration attachment re-upload process is documented as part of the handoff.

ForceManager User records are extracted via the /users endpoint and mapped to Twenty Person records with an owner role flag. Owner assignments on Companies, Contacts, and Opportunities are resolved by matching the ForceManager owner_id to the migrated user by email. Users without a matching Twenty account are placed in a reconciliation queue for the customer's admin to provision before record import resumes. Inactive ForceManager users are migrated as inactive Twenty Person records to preserve historical assignment data.

Every custom field in ForceManager carries a z_ prefix in the API payload (e.g., z_internal_currency, z_text_special). Field type and display label are not embedded in the payload and must be retrieved from ForceManager's Fields menu or schema documentation during scoping. We parse the z_ prefix during extraction, strip it, and recreate the field as a native custom field in Twenty with the original human-readable label. Field type mapping is preserved (text to text, number to number, date to date, picklist to select). This translation step is applied across all objects with z_-prefixed fields before any record import begins.