Migrate from Mekari Qontak to Salesforce Sales Cloud

Qontak Contacts map to Salesforce Contact for qualified buyers and to Salesforce Lead for unqualified prospects. We use Qontak's contact status property (if populated) or the last channel attribution to determine the split at migration time. The original contact source channel (WhatsApp, Instagram, Email) is preserved in a custom field qontak_channel_source__c on both Lead and Contact for reporting continuity.

Qontak Company records map directly to Salesforce Account. The company name becomes Account Name; the domain or website maps to Account Website. Account is created before any Contact import so the AccountId Lookup is satisfied at the moment of Contact insert. We use Company Name as the dedupe key during import to catch any duplicate Account records.

Qontak Deals map to Salesforce Opportunity. Qontak's dealstage property maps to Salesforce StageName, and pipeline assignment maps to a Salesforce Record Type or Sales Process that we configure before migration. Qontak's plan-tier-specific stage list (enumerated values that vary by package) is enumerated during scoping and mapped to the nearest Salesforce stage equivalents. Closed-Won and Closed-Lost reason fields migrate as custom Opportunity fields.

Each Qontak pipeline's stage list is extracted during scoping and mapped to Salesforce Stage values within a Salesforce Sales Process. Stage probability percentages migrate from Qontak to Salesforce StageProbability. If Qontak's pipeline stage count exceeds Salesforce's 15-stage maximum per Sales Process, we split across multiple Record Types with distinct Sales Processes.

Qontak's multiple deal pipelines map to Salesforce Record Types on Opportunity. Each Record Type receives its own Page Layout and Sales Process so stage values remain scoped per line of business. Pipeline-level configurations (e.g., deal-to-invoice linkage) are documented as Salesforce setup recommendations since they have no direct equivalent.

Qontak Tickets migrate to Salesforce Case if the destination org includes Service Cloud licensing. Ticket status values (enumerated per Qontak plan tier) map to Salesforce Case Status values. Custom ticket fields migrate as Case custom fields. If Service Cloud is not included in the destination Salesforce edition, Tickets migrate as Salesforce Tasks with a custom qontak_ticket_type__c flag to distinguish them from standard sales tasks.

Qontak omnichannel conversation messages migrate to Salesforce Task and EmailMessage records linked to the parent Contact and Account. WhatsApp messages migrate as EmailMessage records (the channel-appropriate structure for Messaging sessions in Salesforce). Instagram, LINE, and Email conversations migrate as Task records with the channel noted in a custom field. Activity ordering is preserved by setting ActivityDate to the original Qontak timestamp. This is the highest-risk migration phase because message content is stored in Qontak's media CDN and must be downloaded before re-upload.

Approved WhatsApp message templates are tied to the Qontak-hosted WABA account. They cannot be exported in a portable format and cannot be registered to a new WhatsApp Business API number without going through WhatsApp's template review process. We export a text inventory of all approved templates with their content, variable placeholders, and category for the customer to re-submit through a new BSP (Salesforce's WhatsApp Cloud API partner or another WhatsApp Business Solution Provider) after migration.

Qontak chatbot flows use a Qontak-internal JSON schema that is not portable to any other platform. We extract the full decision tree structure including trigger conditions, message blocks, conditional branches, and API call actions and document them in a detailed flow map. The rebuild recommendation (Einstein Bots, Service Cloud Chat, or Flow) is included based on the destination feature set. The customer or a Salesforce implementation partner rebuilds the flows in the destination platform.

Qontak automation rules (trigger conditions, action sequences, scheduled broadcasts) use a Qontak-specific workflow schema. We document every active automation with its trigger type, conditions, delay rules, and action sequence in a written inventory. The rebuild recommendation (Salesforce Flow record-triggered or scheduled variants) is included. Workflow rebuild is outside the migration scope; it is a separate engagement or an internal admin task.

Qontak list membership and segmentation criteria are exported as static lists. Dynamic segment membership recalculates based on current contact data and is not preserved at the migration timestamp; we export the segment definition criteria and the member list as of the migration date. Salesforce Campaign records are created for each Qontak list, with Campaign Members populated from the static membership snapshot. Salesforce static Campaigns do not auto-update; the customer sets up any dynamic segmentation in Salesforce post-migration.

Qontak agent records (name, email, role as Supervisor or Agent, channel allocation rules) map to Salesforce User records. We resolve agents by email match against the Salesforce User table. Qontak-specific role hierarchy (Supervisor-Agent reporting relationships) is preserved in custom fields qontak_original_role__c and qontak_supervisor_id__c on the User record. Agents without a matching Salesforce User go to a reconciliation queue for the customer's admin to provision before record import.

Qontak custom Contact and Deal properties are fully accessible via the Mekari API. We extract the full schema and migrate property values to Salesforce custom fields. Qontak field types (text, number, date, dropdown) are mapped to equivalent Salesforce field types (Text, Number, Date, Picklist). Multi-select or checkbox fields in Qontak map to Salesforce Multi-Select Picklist. We pre-create all custom fields in Salesforce before any data import using the metadata API or change set.

File attachments in Qontak conversations are stored in Qontak's media CDN. We download all attachments during the migration window before WABA offboarding and re-upload to Salesforce Files (ContentDocument and ContentVersion objects). Long-term media hosting in Salesforce depends on the org's file storage allocation (5 GB base per org, additional storage purchased separately). We flag storage headroom during scoping to avoid mid-migration capacity issues.