Migrate from KulaHub to Salesforce Sales Cloud

KulaHub Contact records contain both individual person fields and business entity fields (company name, industry, website) stored as properties on the same record. We extract company name and domain data during discovery and apply a customer-provided split rule to create Salesforce Account records. Each KulaHub Contact then becomes a Salesforce Contact with the AccountId lookup resolved to the corresponding Account. Any contact without a resolvable company association becomes a Salesforce Contact on a placeholder Account for the customer's admin to reassign post-migration.

KulaHub engagement history (telephone calls, emails, meetings, system events) stores a timestamp and type per contact. We export this as a chronological time-series and load it in date order into Salesforce. Calls map to Task with TaskSubtype=Call; meetings map to Event with StartDateTime and EndDateTime preserved; emails map to EmailMessage linked to a Task; system events and other tasks map to Task. ActivityDate is set to the original KulaHub timestamp to preserve timeline ordering in Salesforce's activity feed.

KulaHub campaigns, templates, and tracking data (opens, clicks, unsubscribes) migrate as Salesforce Campaign records with CampaignMember linking contacts to the campaign. Open and click tracking data from KulaHub stores as custom numeric fields on Campaign (e.g., TotalOpportunitiesCreated, AmountAllOpportunities) to preserve historical campaign performance data. GDPR unsubscribe preferences from KulaHub set HasOptedOutOfEmail on the corresponding migrated Contact.

Documents attached to KulaHub contacts are stored as binary blobs linked by a foreign key. We extract each document blob and re-upload it to Salesforce as ContentVersion, then create a ContentDocumentLink pointing to the corresponding migrated Contact, Account, or Opportunity. Document filenames and any KulaHub attachment notes migrate as ContentVersion Description fields.

KulaHub tasks are assigned to specific users and linked to contacts. We map tasks 1:1, preserving Status, Priority, and ActivityDate. Task owner resolution uses the User mapping table (see below) to resolve KulaHub user references to Salesforce OwnerId at migration time.

KulaHub users appear in activity logs and task assignments. We export the full user list first so owner-ID mapping is resolved before any records that reference users are loaded. Owners resolve by email match against the destination Salesforce org's User table. Any KulaHub user without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before the production migration phase begins.

KulaHub captures website enquiries via forms linked to contacts, but the form-field schema is not publicly documented. We request a sample export of form-submission data during discovery to enumerate the fields. Form submissions that have a clean mapping to KulaHub contact properties load into Salesforce as custom contact fields. Any unmapped or ambiguous fields are held in a staging table (a Salesforce custom object) and presented to the customer for manual mapping before the production run.

KulaHub reports (system activity logs, CRM activity reports, All Contacts export) are included as a data export for the customer to use in rebuilding reports inside Salesforce. Report definitions and dashboards do not migrate; KulaHub's reporting format has no Salesforce equivalent. We deliver the exported data in CSV format alongside the migrated records so the customer's admin can rebuild reports from the same underlying data.

KulaHub does not expose a separate Company or Account object. All business entity data stored in KulaHub Contact records (company name, domain, industry, employee count) is extracted during discovery and used to create Salesforce Account records before the Contact migration phase. The Account creation uses company name as the primary dedupe key; duplicate company names are flagged in the reconciliation report for the customer to resolve.

KulaHub has no Deals or Pipeline object. If the customer maintains deal history in spreadsheets, shared documents, or KulaHub notes fields, we offer a deal reconstruction engagement as a separate scoping item. We define the Opportunity fields (Stage, Amount, CloseDate, AccountId, OwnerId) based on the customer's deal data format, load the reconstructed Opportunities after Account and Contact migration, and configure the Salesforce Sales Process with stages that match the customer's historical deal pipeline.

KulaHub's custom field schema is not publicly documented. We request a full field inventory from KulaHub support during discovery and compare it against the standard KulaHub contact property list to identify any custom additions. Custom fields that are confirmed are created in Salesforce as custom contact fields (text, number, date, or picklist depending on the inferred type). Any fields whose type cannot be confirmed are flagged in the mapping document for the customer's admin to validate and assign a Salesforce field type before migration.

KulaHub stores email unsubscribe states and GDPR preference flags per contact. The internal data format for these flags is not documented. We export the preference flags as both Salesforce's standard HasOptedOutOfEmail boolean and as custom contact fields (e.g., gdpr_marketing_consent__c, gdpr_third_party_consent__c) so the destination system respects suppression lists and retains the granular preference data for any future GDPR audit.