Migrate from VBOUT to Salesforce Sales Cloud

VBOUT Contacts map to Salesforce Lead or Contact depending on qualification status. We use the VBOUT Lead Score and any pipeline stage Tags to determine the split: Contacts with a positive lead score or active pipeline stage assignment map to Salesforce Contact attached to an Account (created from the VBOUT Company if present). Contacts without a lead score and no pipeline stage map to Salesforce Lead. The original VBOUT contact ID, lead score, and any Tags preserving lifecycle context migrate as custom fields on both Lead and Contact (vbout_contact_id__c, vbout_lead_score__c) for audit and reconciliation.

VBOUT Company records map directly to Salesforce Account. The Company domain or website field becomes the Account Website. We use Company name as the dedupe key during import. Account is created before any Contact import so that the AccountId Lookup is satisfied at Contact insert time. If a VBOUT Contact has no associated Company record, we create a Account using the Contact's domain as a fallback and flag it for manual merging post-migration.

VBOUT Leads (distinct from Contacts in VBOUT's soft CRM model) map directly to Salesforce Lead. Lead Score, Source Attribution, and Owner Assignment from VBOUT migrate as custom fields on Salesforce Lead (vbout_lead_score__c, vbout_source__c). VBOUT Lead Status maps to Salesforce Lead Status with a custom mapping table produced during scoping. Owner email resolution runs against the Salesforce User table before Lead import to avoid orphaned records.

VBOUT Tags on Contacts and Leads serve two distinct use cases that we resolve during scoping. Tags used for pipeline stage or segment classification migrate as Salesforce custom Multi-Select Picklist fields on Contact and Lead. Tags used for campaign audience membership migrate as Salesforce Campaign records with CampaignMember records linking the VBOUT contacts/leads to the Campaign. The customer selects the tag strategy during discovery before migration begins.

VBOUT Smart Audiences are dynamic segmented lists based on behavioral and demographic criteria. The segmentation rule definitions (filters, conditions, combinators) are not directly portable to Salesforce. We extract the full audience membership (the flattened contact and lead IDs at the time of export), create a corresponding Salesforce Campaign for each Smart Audience, and populate CampaignMember records for all members. The segmentation logic is documented in a structured text artifact for manual rebuild in Salesforce Campaigns or Campaign Lists.

VBOUT custom fields on Contacts and Leads migrate as Salesforce custom fields on the corresponding object (Contact or Lead). Field type mapping is required: VBOUT dropdown fields map to Salesforce Picklist, conditional fields map to Checkbox or dependent Picklist, payment fields map to Currency or Number. We pre-create the Salesforce custom fields via metadata API before migration begins and assign field-level security per profile during the import phase. VBOUT's lack of a public object schema reference means field discovery is performed by querying the VBOUT API's contact and lead endpoints directly during scoping.

VBOUT pipeline stages (stage name, order, assignment rules) map to Salesforce Opportunity Stage values within a configured Sales Process. We create a Salesforce Record Type per VBOUT pipeline, assign each Record Type a Sales Process that whitelists only the relevant stage values, and map stage probabilities from VBOUT to StageProbability on Salesforce. VBOUT Tags encoding pipeline context migrate as a Multi-Select Picklist field on Opportunity to preserve the original stage label if Salesforce stage names differ from VBOUT's.

VBOUT's pipeline object (containing multiple pipeline stages) maps to a Salesforce Record Type on Opportunity, with a corresponding Sales Process that defines the allowed stage progression and probability mapping. If the customer has multiple VBOUT pipelines for different lines of business or product categories, each maps to a distinct Salesforce Record Type with its own Page Layout and Sales Process, deployed via Salesforce metadata API into the Sandbox org first for validation.

VBOUT sent email campaign history (subject, send date, open rate, click rate, bounce data) migrates as Salesforce Task records linked to the Contact or Lead (WhoId) and optionally to a Campaign (WhatId) for attribution. Open and click interaction data migrates as custom Task fields (vbout_open__c, vbout_click__c) so the customer can segment by engagement level in Salesforce reports. Email template bodies export as HTML artifacts but must be manually rebuilt in Salesforce Email Templates or Marketing Cloud Content Builder.

VBOUT automation workflows export as structured JSON artifacts documenting trigger conditions, filter criteria, delay durations, and action sequences. The JSON is not directly portable to Salesforce Flow because VBOUT's trigger-action builder uses a different execution model. We produce a written rebuild guide per workflow that maps each VBOUT step to the equivalent Salesforce Flow element (trigger type, decision element, action element). The customer's Salesforce admin or a certified Flow builder executes the rebuild post-migration; we do not configure Flow as part of the data migration scope.

VBOUT call logs, task records, and notes map to Salesforce Task with the appropriate TaskSubtype (Call for call logs, default for tasks). Activity timestamps preserve ordering on the Salesforce activity timeline. Call duration and disposition migrate as custom Task fields. Notes migrate as Salesforce Note records linked via ContentDocumentLink to the parent Contact, Lead, Account, or Opportunity. Engagement records are processed via Salesforce Bulk API 2.0 due to volume; we chunk by parent record and resolve WhoId (Contact or Lead) and WhatId (Opportunity or Account) before batch submission.

VBOUT landing pages are stored as VBOUT-specific page definition files that cannot be imported into Salesforce or any other platform. We export page metadata (page title, URL slug, form field configurations, redirect rules, and publish status) as a structured CSV artifact. The customer uses this metadata to rebuild pages in Salesforce Experience Cloud, HubSpot, or another page builder. The visual layout, copy, and styling cannot be transferred and require manual recreation.