Migrate from YetiForce CRM to Twenty CRM

YetiForce Organization records map directly to Twenty's Company object. Company is the first object loaded in every migration because Contacts, Potentials, and custom object records reference it via lookup. The organization domain name from YetiForce becomes the Company website field, and industry/type picklists from YetiForce map to the corresponding Twenty select options. We preserve assigned owner as a user lookup resolved by email match.

YetiForce Contact records map to Twenty's People object. We map the full name split into firstName/lastName fields, email to email, phone to phoneNumber, and postal address fields to the Twenty address compound field. The Contact's linked Organization resolves to a Company record already imported, satisfying the WorkInformation and companyMember relations. Any YetiForce custom fields on Contact are created as custom fields on the People object before the import phase begins.

YetiForce Leads map to Twenty People records with a personType field set to Person to indicate they are prospect records pending qualification. We preserve Lead_Source and Lead_Status as custom select fields on the People object. Unlike Salesforce's Lead-to-Contact convert flow, Twenty does not have a separate Lead object — Leads and Contacts both live in the People object. We do not split into separate objects; the customer reconverts prospect records to customer-type People records manually after migration if needed.

YetiForce Potentials map to Twenty's Opportunity object. We map the Potential name to opportunityTitle, amount to amount, closeDate to closeDate, and probability to probability. The related Organization reference resolves to the imported Company. Stage names from YetiForce's pipeline map to Twenty Opportunity stage values via a configuration table that we build during scoping. The assigned user maps via email match to a Twenty user record.

YetiForce's deal pipelines and stage values map to Twenty's Opportunity pipeline and stage configuration. Each YetiForce pipeline becomes a distinct set of stage options in Twenty's Opportunity settings. Probability percentages from YetiForce migrate to Twenty's stage-level probability values. We configure this in Twenty's Settings before any Opportunity records are imported.

YetiForce Projects have no native Twenty equivalent — Twenty does not include a built-in Project or Project Task module. We create a Project custom object in Twenty via Settings > Data Model before migration, with custom fields for project name, status (select), start date, end date, and assigned owner (user lookup). Project Tasks link to this custom object via a parent lookup relationship. The customer defines the status picklist options during scoping to match their existing YetiForce stage values.

YetiForce Project Tasks map to a second custom object linked to the Project custom object via a parent lookup. We create custom fields for subject, status, priority (select), assigned user (lookup), start date, and due date. Parent record resolution is required — we build a temporary ID mapping table during the Project import phase and apply it to Task records during the Task import phase. Tasks import after Projects in the migration sequence.

YetiForce Tickets require a custom object in Twenty since no native ticket or helpdesk module exists. We create a Ticket custom object with custom fields for title, status (select), priority (select), category (select), related Contact (People lookup), and related Organization (Company lookup). Status and priority picklist options are defined during scoping against the customer's existing YetiForce ticket status values. We handle the Contact and Organization references by resolving them against already-imported People and Company records.

YetiForce Products map directly to Twenty's standard Product object. We map product name, unit price, description, and stock quantity. The vendor reference from YetiForce resolves to an imported Vendor record by matching on vendor company name. If the customer does not migrate Vendors as a separate object, we map the vendor reference to a text field on Product and the customer reconciles manually.

YetiForce Services share the same data shape as Products and migrate to Twenty's Product object or a separate custom object depending on the customer's reporting needs. We map service name, price per unit, and description. The customer decides during scoping whether to keep Services alongside Products in the same object or create a distinct custom object for clearer reporting separation.

YetiForce Vendors map to Twenty Company records or a custom Vendor object depending on whether the customer wants to distinguish vendor companies from customer companies in reporting. We map vendor name, website, address, and assigned owner. If the customer chooses the Company route, we add a custom select field (companyType) set to Vendor on migrated records to enable filtering.

YetiForce Users map to Twenty User records by email address match. We extract every distinct user referenced as an owner on Organizations, Contacts, Potentials, Projects, and Tickets, then match by email against the Twenty workspace User list. Any YetiForce user without a matching Twenty user is placed in a reconciliation queue for the customer's admin to provision before record import continues. Inactive YetiForce users map to inactive Twenty users to preserve historical assignment.