Migrate from Kinabase to Salesforce Sales Cloud

A Kinabase Collection that represents organisations, companies, or business entities maps to Salesforce Account. We use the Collection's primary name field as Account.Name, the address fields as BillingAddress, and any classification fields as Industry, Type, or custom __c fields. If the Collection stores individual people rather than organisations, it maps to Contact instead—determined during scoping by examining whether the name field is singular or plural and whether the Collection has company-related fields.

A Kinabase Collection that represents individual people maps to Salesforce Contact. The primary name field maps to Contact.FirstName and LastName (parsed from a full-name field), email maps to Email, phone maps to Phone, and any role or title fields map to Title. Contact requires an AccountId Lookup to associate the individual with an organisation; we resolve this from a linked-collection field pointing to the corresponding Accounts Collection during the load phase.

A Kinabase Collection tracking revenue-generating work maps to Salesforce Opportunity. The Collection's stage field (Draft, In Progress, Won, Lost) maps to StageName, and any amount field maps to Amount. If the Collection has a date field, it maps to CloseDate. Owner resolution happens by email match against the Salesforce User table. If the destination org uses multiple sales processes, we configure Record Types during schema design before migration.

Kinabase text fields map to Salesforce Text (255 chars), Text Area (255 chars, displayed as textarea), or Long Text Area (131,072 chars) depending on the source field's max length and whether it is expected to contain multi-line content. Multi-line text that is displayed as rich text in Kinabase maps to Long Text Area without formatting preservation.

Kinabase numeric fields map to Salesforce Number, Currency, or Percent depending on the business meaning. We inspect whether the number has a currency symbol, a percentage sign, or a decimal precision requirement to select the correct Salesforce field type. Number fields with no semantic modifier default to Number(18,2).

Kinabase date and datetime fields map directly to Salesforce Date and Datetime. We handle timezone normalisation at migration time—Kinabase stores dates in the configured org timezone, and we convert to UTC before writing to Salesforce Datetime to avoid off-by-one-day errors on date-only fields.

Kinabase single-select dropdown fields map to Salesforce Picklist. We export the distinct values from Kinabase and create matching Picklist values in Salesforce during schema design. If a Kinabase value contains a character not allowed in Picklist API names (e.g., a slash or ampersand), we strip or replace it and maintain an internal cross-reference.

Kinabase multi-select dropdown fields map to Salesforce Multi-Select Picklist. Values are semicolon-delimited in both systems, so the migration is a direct value transfer. Multi-Select Picklist fields have a 255-character combined value limit; we flag Collections where concatenated multi-select values may exceed this and propose a truncation strategy during scoping.

Kinabase Computed Fields evaluate dynamically by formula and are not stored as persistent data. We evaluate each formula at migration time and write the resulting value as a static Salesforce field. The formula definition does not transfer—only the snapshot value at the time of migration. We flag this explicitly in the pre-migration field audit and document every Computed Field that maps to a static value so the customer understands the limitation before cutover.

A Kinabase linked-collection field (e.g., a Projects Collection with a Client field pointing to the Clients Collection) is a cross-collection reference with no Salesforce-native equivalent. We resolve the reference at migration time: if the target Collection maps to Account, we write the resolved AccountId as a Lookup field; if the target has no direct Account equivalent, we write the Kinabase record ID as a Text field and document the relationship for manual re-establishment or a custom Lookup formula. This requires exporting Collections in dependency order (parents first) so that parent IDs are available when child records are loaded.

Kinabase Tasks map directly to Salesforce Task. We preserve Status (Open, Completed), Priority (High, Normal, Low), ActivityDate (due date), Subject, and Description. Assignee resolution maps the Kinabase owner reference to Salesforce OwnerId via email match against the User table. Tasks linked to a Kinabase Collection record map to a Salesforce Task with the appropriate WhatId (for Account/Opportunity-linked tasks) or WhoId (for Contact-linked tasks) resolved at migration time.

Kinabase Collections that track work history (emails, calls, meetings, notes) map to Salesforce Task (for calls and tasks), Event (for meetings), and EmailMessage (for emails). Each Kinabase record type is identified during scoping by inspecting the Collection's fields for type indicators (duration for calls, attendees for meetings, body for emails). Emails also create a paired Task record for the activity timeline. Activity timestamps are preserved as ActivityDate and CreatedDate in Salesforce.

Kinabase stage fields (Draft, In Progress, Approved, Closed Won, Closed Lost) are categorical values that map to Salesforce StageName on Opportunity or to a custom Picklist if the Collection does not represent a revenue pipeline. Stage probability percentages from Kinabase map to Salesforce StageProbability values, rounded to the nearest integer allowed by Salesforce.

Kinabase documents attached to records are exported as filenames and URLs (not file content). We map each document association to a Salesforce ContentDocumentLink linking the document to the parent Account, Contact, or Opportunity record. Actual file content migration depends on whether the documents are stored in a connected cloud location (SharePoint, S3) that can be re-linked; if content is embedded in Kinabase, we migrate the filename reference only and flag for manual re-upload to Salesforce Files or Documents.

Kinabase workflows define stage progression, trigger-based rules, and approval gates. These are process-layer constructs that do not represent data records. We do not migrate workflows as executable code. We audit every active Kinabase Workflow and deliver a written inventory listing the trigger, conditions, actions, and a recommended Salesforce Flow equivalent (record-triggered Flow, path, or approval process). The customer's Salesforce admin or a certified consultant rebuilds them post-migration.

Kinabase Views and Filters are saved query definitions scoped to a Collection. They are UI-layer constructs with no underlying data representation. We do not migrate views; we export the underlying records that views query. Salesforce List Views and Reports serve a similar purpose, but their creation is part of the post-migration administration work, not the migration itself.

Kinabase integrations are platform-level connection configurations. These cannot be migrated to Salesforce. We document the active integrations (which users have connected, which Collections are affected) in the migration handoff so that the customer's IT team can re-establish equivalent connections in Salesforce—Outlook sync via Salesforce Inbox, SharePoint via Files Connect, and Entra ID SSO via Salesforce Identity.