Migrate from Origo BPO to Twenty CRM

Origo BPO contact records (name, email, phone, job title, company association) map directly to Twenty CRM's People object. The primary company link becomes the People.companyId relation. Origo BPO does not split contacts into Lead vs Contact objects — all records land in Twenty's unified People object. Secondary company associations are preserved as custom fields for reference.

Origo BPO company records map to Twenty CRM Companies object — company name, domain/website, industry, employee count, and annual revenue all have direct equivalents in Twenty's standard Company fields. Parent-child company hierarchies in Origo BPO map to the Companies.parentId relation. Industry pick-list values may need standardization if Origo BPO uses free-text industry entries.

Origo BPO deal records — deal name, amount, stage, close date, owner — map to Twenty CRM Opportunities. Stage values from Origo BPO are mapped to Twenty stage pick-list values created in Settings → Data Model before migration. Probability percentages and forecast category metadata from Origo BPO migrate as custom fields since Twenty does not have a native probability field on Opportunities.

Origo BPO task records (subject, due date, assignee, completion status) map to Twenty CRM Tasks. The relation to People, Companies, or Opportunities is preserved via the task's linkedId and linkedIdModule fields. Origo BPO SLA-driven task flags migrate as a custom text or select field on the Twenty task record.

Origo BPO free-text notes attached to contacts or companies map to Twenty CRM Notes. The note body migrates as the note content field. Notes linked to specific People or Companies records carry the same relation in Twenty — the note's linkedId and linkedIdModule fields connect to the correct record. Creation timestamps and author information are preserved as custom fields if needed.

Origo BPO records often carry custom fields unique to the BPO engagement (client SLA tier, service-level category, back-office team assignee). These do not have Twenty native equivalents and must be created in Twenty's Settings → Data Model before import. We create the field with the appropriate type (text, number, select, date, relation) and then populate it during the migration run.

Origo BPO user records (owner IDs, assignee IDs, team member names) must exist as Twenty Workspace Members before the migration can resolve owner links. We invite all Origo BPO team members to the Twenty workspace during setup. Owner resolution then matches by email — any Origo BPO owner without a corresponding Twenty user is flagged and assigned to a fallback workspace member.

If an Origo BPO contact record is associated with more than one company, Twenty's People object links to one primary company via companyId. Additional company associations are surfaced as a custom multi-select or relation table (PeopleAdditionalCompanies__c) after migration. The mapping plan flags which company should be primary — typically the most recently modified or the highest-revenue account.

Origo BPO engagement records (call logs, email threads, meeting notes) are extracted as activity records and loaded into Twenty as Tasks with the appropriate type ('Call', 'Email') or as Events for calendar-bound meetings. Original timestamps, subject lines, and assignee information are preserved. The activity's linkedId connects it to the relevant People or Company record in Twenty.

If Origo BPO stores domain-specific records beyond contacts, companies, deals, tasks, and notes — for example, project records, service tickets, or SLA logs — these map 1:1 to Twenty custom objects. The custom object name and all its custom fields are created in Twenty's Data Model first. Relation fields between custom objects and standard objects (People, Companies, Opportunities) are resolved during migration using Twenty's relation field type.