Migrate your Kinabase data

Collections are Kinabase's top-level object containers — equivalent to entity types. Every Collection has its own schema of Fields. We export each Collection as a separate CSV file or API call and replicate it as a distinct object type in the destination CRM.

Records are the individual rows within a Collection. We map each Record to the corresponding destination object and preserve all field values, handling nulls, empty strings, and multi-select dropdowns according to the destination's field type constraints.

Fields are the typed columns within a Collection — text, number, date, dropdown, computed, and linked collection fields. Custom fields are fully supported but require field-level mapping since Kinabase field names and types may not map 1:1 to the destination CRM's property schema.

Linked collection fields create cross-collection references — a 'Client' field in a 'Projects' collection points to a record in the 'Clients' collection. We preserve these as foreign-key relationships, either as lookup fields or denormalised IDs depending on destination support.

Computed Fields derive their value from a formula or expression. These cannot be stored as formulas in most destination CRMs, so we evaluate them at migration time and store the resulting value as a static field. The formula itself is lost unless the destination supports computed properties.

Activities track work history on a record — emails, calls, meetings. We map these to the destination CRM's activity or engagement object, preserving timestamps, owners, and content where the schema allows.

Tasks are standalone work items that can be associated with records. We map Tasks to the destination's task or to-do object, preserving assignees, due dates, status, and linked record associations.

Documents attached to records are exported by reference URL or filename. We handle document migration by mapping file associations; actual file content transfer depends on whether the destination supports file attachments on the target object.

Workflows define stage progression, trigger-based automations, and approval gates. We capture workflow definitions and stage maps as structured data, but automated actions (triggers, notifications) cannot be replicated in systems with different automation engines.

Stages represent pipeline statuses within a Collection — Draft, Approved, In Progress, and so on. We preserve stage values as a categorical field on the target record, but the visual progress indicators and stage-requirement logic are Kinabase-native and do not transfer.

Views and Filters are saved query definitions scoped to a Collection. These are user-interface constructs and do not represent actual data. We do not migrate views; we export the underlying records that the views would surface.

Integrations such as Microsoft 365 (Outlook, SharePoint, Entra ID SSO) are connection-level configurations. These cannot be migrated to a different platform. We do not replicate integration setup; the destination will require fresh OAuth or credentials configuration.