Migrate from Optimove to Salesforce Sales Cloud

Optimove Customer records map to Salesforce Contact. Each Customer has a unique CustomerID used across all engagements and Data Share exports. We preserve CustomerID as a custom external ID field (optimove_customer_id__c) on Contact for referential integrity during the migration and for any future Optimove integrations. Customer attributes map to standard Contact fields (Name, Email, Phone, Address) and custom fields for any non-standard attributes within the 50-attribute ceiling.

Optimove's custom attributes (up to 50 combined across API, batch, and real-time) map to Salesforce custom fields on Contact. We audit the current attribute count during discovery and flag any that exceed Salesforce field type equivalents (dates, numbers, text, picklists). Attributes added via Optimove's UpdateCustomerAttributes API function require the same API-based update in Salesforce rather than batch load, which affects migration sequencing. Any overflow beyond the 50-attribute ceiling is documented and the customer decides which attributes to drop or consolidate before import.

Optimove Lifecycle Stages (such as Prospect, New Customer, Active, At Risk, Churned) map to a custom multi-select picklist or text field on Contact (optimove_lifecycle_stage__c). There is no native Salesforce equivalent; Lifecycle Stage is a derived Optimove concept from behavioral aggregation, not a standard CRM field. We preserve stage assignments and transition history exported from Migration Explorer as dated entries in a related custom object (Lifecycle_Stage_History__c) with Stage, TransitionDate, and Reason fields. Stage definitions are delivered as a configuration guide for the customer's admin to map to Salesforce automation triggers if desired.

Optimove Target Groups are dynamic customer segments built from attribute rules. We export the customer membership lists (the actual customer IDs in each group) and recreate them as Salesforce Campaigns with Campaign Members. Complex nested rules are documented as written segment logic for the admin to recreate using Salesforce Reports, List Views, or Flow-based segmentation. Dynamic re-evaluation of segments requires a different mechanism in Salesforce (typically scheduled Flows or a third-party segmentation tool) because Salesforce does not have a native equivalent to Optimove's real-time segment recalculation.

Optimove generates proprietary predictive scores and OptiGenie AI next-best-action recommendations that cannot migrate as functional equivalents. We export raw numerical scores (such as churn probability, LTV prediction, engagement score) to custom numeric fields on Contact (optimove_churn_score__c, optimove_ltv_score__c) for reference and audit. These values are static at migration time and will not update post-migration. The customer should plan to rebuild predictive scoring in Salesforce Einstein (if licensed) or a third-party scoring tool integrated via Salesforce Data Cloud.

Optimove Campaign records (metadata including name, type, channels, schedule, and audience size) map to Salesforce Campaign. The channel type (email, SMS, push, web) migrates to a custom field because Salesforce Campaign does not natively distinguish multi-channel campaign types. Campaign performance metrics (sends, opens, clicks, conversions, control group results) migrate to Campaign statistics fields and a related Campaign_Performance__c custom object for historical reference. Journey orchestration logic, wait conditions, and branching rules cannot migrate and are documented as a written journey map for the admin to rebuild in Salesforce Flow or Marketing Cloud Journey Builder.

Optimove campaign engagement data (individual sends, opens, clicks, conversions per Customer) maps to Salesforce Campaign Member records and Activity history (Tasks and Events). Each engagement record links to the migrated Contact via optimove_customer_id__c. Control group membership assignments migrate to a custom field on Campaign Member (optimove_control_group__c) to preserve experimental design for post-migration ROI analysis. Engagement metrics are aggregated from Optimove's Data Share exports and written to Campaign statistics fields.

Optimove Control Group assignments migrate to a custom checkbox field on Salesforce Campaign Member (optimove_control_group__c). Control group percentages and experiment designs are documented in the campaign metadata handoff document. Salesforce does not have native control group functionality for Campaigns; the admin recreates this using Lightning Experiment or a custom tracking setup if ongoing campaign testing is required.

Optimove multi-brand architecture with separate customer databases per network maps to Salesforce Account hierarchies (parent Account per brand with child Accounts per sub-brand or region) or separate Salesforce orgs per brand depending on the customer's preference. We identify all separate networks during discovery, map each network's Customer database to the appropriate Account hierarchy, and handle schema differences between networks in separate mapping workstreams. If networks have different attribute sets, we consolidate to the union of all attributes and flag any network-specific attributes that cannot map to a shared schema.

Optimove user accounts and roles are listed via the platform admin interface and exported for migration. Role permissions and access levels (which are Optimove-specific) require manual recreation in Salesforce because Optimove's permission model does not map to Salesforce profiles and permission sets. We map Optimove users to Salesforce Users by email and flag any Optimove roles that have no direct Salesforce equivalent (such as Optimove-specific marketing roles) for the admin to assign appropriate Salesforce profiles post-migration.

Optimove does not expose a documented Custom Objects API equivalent to standard CRM objects; only Customer-level custom attributes are supported via the API. If the customer has data that lives in external systems connected to Optimove (such as subscription data, loyalty points, or product usage), we map these to Salesforce Custom Objects during scoping. We pre-create the destination schema including all custom fields and lookup relationships before any data import. Custom object naming follows Salesforce __c convention matched to the original Optimove object names.

Optimove is a data and orchestration platform, not a content management system. Media assets used in campaigns are stored in connected ESPs or content tools, not in Optimove itself. We do not migrate media assets. If the customer has attachment data stored within Optimove (such as exported reports or customer documents), we map these to Salesforce ContentDocument via ContentDocumentLink to the parent Contact or Account record. Customer should identify all external content tools (ESP, SMS provider, push notification service) for reconnection planning post-migration.