Migrate from Kinabase to Microsoft Dynamics 365 Sales

Kinabase Collections are the top-level entity containers and map to one of three Dynamics 365 targets depending on the Collection's semantic role: Organizations, Companies, or Clients map to Account; People, Contacts, or Individuals map to Contact; anything that represents a project, case, subscription, or custom concept with no standard Dynamics 365 equivalent maps to a custom entity. We pre-create the destination schema during scoping, deploy to a Sandbox for validation, and confirm the Collection-to-Object mapping with the customer's admin before export begins. Collections with fewer than ten records that act as reference data (dropdown sources, category lists) may be delivered as picklist values instead of separate records.

Individual Records map to the Dynamics 365 record type determined by their parent Collection's mapping. We preserve all typed field values including nulls and empty strings, applying type coercion where Kinabase field types differ from Dynamics 365 field types (e.g., Kinabase multi-select dropdowns map to Dynamics 365 multi-select picklist or to a text field with delimited values). Records are imported in dependency order: Account records first, then Contact records with resolved AccountId lookups, then custom entity records with their own lookup chains.

Kinabase Fields with standard types (text, number, date, email, phone, URL) map to equivalent Dynamics 365 field types. Email fields map to email type; phone fields map to telephone type. We preserve the field label as the Dynamics 365 display name and use a sanitized version of the Kinabase field name as the API name. Required-field enforcement in Dynamics 365 requires the corresponding Kinabase field to have been required in the Collection; we flag any mismatch during the pre-migration audit.

Kinabase dropdown Fields map to Dynamics 365 picklist fields, with the dropdown options becoming picklist values. We create the picklist values in the destination during schema deployment, preserving the display label and optionally the sort order. Multi-select dropdowns in Kinabase map to multi-select picklist in Dynamics 365. If the target Dynamics 365 edition does not support multi-select picklist (which is available from Microsoft Dynamics 365 Sales Professional onward), we fall back to a text field with comma-delimited values.

A Linked Collection field (e.g., a 'Client' field in a 'Projects' Collection pointing to a 'Clients' Collection record) maps to a Dynamics 365 Lookup field on the target entity, pointing to the resolved Account, Contact, or custom entity record. We export linked records in dependency order so that the parent record exists before the child record is loaded. For Linked Collection fields pointing to Collections that map to custom entities, we verify the custom entity has been provisioned before loading begins. If the destination org does not support the lookup relationship type, we fall back to storing the source Kinabase record ID as a text External ID field.

Kinabase Computed Fields evaluate a formula at read time; the formula itself is not persistent data. We evaluate each computed expression at migration time using the values present in the source record and write the resulting value as a static field in Dynamics 365. The formula definition is not transferred because Dynamics 365 does not support importing formula definitions from external systems. We flag all computed fields during the pre-migration audit and document the formula logic in the field mapping deliverable so the customer's admin can recreate it as a Dynamics 365 calculated field or Power Automate flow if needed.

Kinabase Collections with Stage progression (Draft, In Progress, Approved, Closed) map to a Dynamics 365 Opportunity's stage field if the Collection represents a sales pipeline, or to a custom status field on the target entity otherwise. We extract the distinct stage values, create corresponding stage entries in the Microsoft Dynamics 365 Sales Process, and preserve the probability percentage if present in Kinabase. Stage progression rules and automation triggers in Kinabase do not migrate.

Kinabase activity records linked to a Collection record map to Dynamics 365 activity entities: email activities map to EmailMessage with the email body and recipients; call records map to Task with TaskSubtype=Call; meeting records map to Appointment with start and end times; standalone task records map to Task with Status, Priority, and ActivityDate preserved. We resolve the Kinabase activity's linked record to the migrated Dynamics 365 record via the Kinabase record ID retained in an external ID field, then set the Regarding (object) lookup on the activity to the migrated record.