Migrate from Unim to Twenty CRM

Unim Contact records map to Twenty People. The Unim Contact model carries standard fields (name, email, phone, address) plus a variable set of custom fields discovered at schema-introspection time. We inspect the Contact ModelID and enumerate every active custom field before defining the import map. Email is used as the dedupe key. Standard Unim Contact fields map directly to their Twenty People equivalents; custom fields are created in Twenty Settings → Data Model before import begins.

Unim Company records map to Twenty Company. The same schema-discovery pattern applies: we enumerate the Company model's ModelID, active custom fields, and datatypes before writing migration code. Domain-based dedupe is applied. Company is loaded before People so that the Twenty People record can reference the parent Company via the workspaceId or linked Company record at import time.

Unim Activity records—calls, emails, meetings, notes—carry timestamps, owner references, and optionally linked custom fields. We map call activities to Twenty Task with a task-type annotation, meeting activities to Task with date/time and location preserved, and note activities to Note records linked to the parent People or Company. Activity-to-contact linkage is preserved by setting the target People ID at migration time. Owner references require email-based resolution against the Twenty workspace members.

Unim custom fields have a Name, ModelID, DataType, and Nullable flag. DataTypes are resolved via the valuelists endpoint. We query this endpoint to enumerate every active custom field on each entity, map the datatype to the closest Twenty field type (text, number, date, select, multi-select, checkbox, URL, currency), and pre-create the field in Twenty Settings → Data Model before any records are imported. This is the highest-risk step for data loss if skipped.

Bespoke entity types beyond the standard Contacts/Companies/Activities triad are defined at the Unim application level. We discover these via schema introspection, enumerate their field sets and datatypes, and create equivalent custom objects in Twenty's workspace. Custom object-to-standard object lookup relationships (e.g., a bespoke Project entity linked to People) are resolved at migration time using the parent-record ID pattern. Each custom object migration runs after its parent standard object has been imported.

Unim Owner IDs assigned on records are scoped to that specific deployment and cannot be used as-is in Twenty. We map source owner IDs to Twenty workspace members using email as the join key. Twenty requires that all referenced members exist in the workspace before import; we validate member presence and flag any owner without a matching workspace member for the customer's admin to provision before record import resumes.

Attachments in Unim are served via the Files dimension, not inline with the record. Each attachment requires a separate API call to fetch the binary blob. For large migrations, we paginate file extraction and apply retry logic on 429 responses. Files are re-associated with the target People or Company record in Twenty using Twenty's file attachment API, with original filenames and MIME types preserved.

Tag associations in Unim are stored as separate linked records or as array fields depending on the specific deployment. We preserve tag-to-record linkages as a join table and either map to a Twenty multi-select custom field or attach as a Note on the target record, depending on tag cardinality. The customer chooses the strategy during scoping.

Business-logic workflows built within Unim's application builder are tightly coupled to that specific application's custom object model and cannot be meaningfully exported or re-imported into Twenty. We export a written inventory of every active Unim workflow with its trigger, conditions, actions, and a recommended Twenty workflow equivalent, so the customer's admin can rebuild them post-migration.

Webhook configurations are environment-level settings tied to Unim's internal routing and event model. They do not translate across to Twenty's webhook or integration system. We document active webhooks for the customer's awareness and recommend rebuilding them using Twenty's API or a middleware platform (n8n, Zapier) post-migration.