Migrate from Cronberry to Salesforce Sales Cloud

Cronberry's unified Contact model has no direct Salesforce equivalent. We split at migration time: Contacts with lifecycle status indicating qualified prospect (e.g., sales qualified lead, customer) map to Salesforce Contact attached to an Account; Contacts with pre-sale status (subscriber, marketing qualified lead, lead) map to Salesforce Lead. We compute the split using Cronberry's segment membership and any lifecycle or status fields present in the export, then preserve the original Cronberry segment assignments in a custom multi-select picklist cronberry_segments__c on both Lead and Contact for audit and future segmentation rebuild.

Cronberry company records map to Salesforce Account. The company name becomes the Account Name; website and domain fields map from Cronberry's company URL. Because Cronberry's company schema varies by implementation and may include custom properties, we perform a field-level inventory during scoping and map every populated custom company field to a corresponding custom Account field. Account is created before any Contact import so the AccountId Lookup is satisfied at Contact insert.

Cronberry Campaigns carry channel information (Email, SMS, Push, WhatsApp), timing rules, and target segment assignments. We extract these and map them to Salesforce Campaign with the Cronberry channel stored as a custom campaign channel field. Campaign type and status migrate from Cronberry campaign state. Target segment size is preserved as a custom field for campaign sizing validation. Note that Cronberry campaign performance metrics (opens, clicks, bounces) are behavioral event data that migrates separately as Activity records.

Cronberry Smart Segments are built from field-value conditional rules that are not exported as a reusable schema. We reverse-engineer segment membership by querying which contacts belong to each segment, then document the implied conditions so they can be reconstructed manually in Salesforce using List Views, Reports with filters, or Salesforce Data Cloud audience segments. We deliver a written segment inventory with original conditions, contact counts, and recommended Salesforce rebuild path.

Cronberry contact tags (single or multi-value) migrate to Salesforce multi-select picklist fields on Lead or Contact depending on the split. Tags used for campaign attribution or audience segmentation migrate to Salesforce Campaigns with CampaignMember records linking the tagged contacts.

Cronberry's channel credentials (Email, SMS, Push, WhatsApp sender IDs, API keys) are platform configuration data that cannot be migrated. We extract channel configuration metadata and document it in a configuration checklist so the customer's admin can reconfigure each channel in Salesforce (or via Salesforce's preferred third-party SMS/Push integrations such as Twilio, AWS SNS, or a WhatsApp Business API partner). Channel associations on contacts (which channels a contact is subscribed to) migrate as opt-in fields on Lead or Contact.

Cronberry form definitions including field structure and conditional logic are extractable. We map the form schema to Salesforce Web-to-Lead configuration or to a custom Salesforce object if the form captures non-standard data. Visual layout and drag-and-drop design do not migrate; the customer's admin recreates the form in Salesforce's Form Builder or a third-party tool like FormAssembly or JotForm integrated via Salesforce.

Cronberry tracks behavioral events (opens, clicks, push interactions, form submissions) as event logs linked to contacts. We map these to Salesforce Task and Event records with a custom event type field that captures the original Cronberry interaction (e.g., email_open, sms_delivered, push_clicked). The custom Task field cronberry_event_type__c preserves the behavioral category, and the original timestamp migrates to ActivityDate for timeline ordering. Event schema mapping requires field-level review during scoping because behavioral event structure varies by Cronberry implementation.

Message templates with personalization variables are migratable. We extract template content and variable placeholders from Cronberry and map them to Salesforce EmailTemplate (for email) or document them in a template handoff specification for SMS and Push templates that will be recreated in the destination channel tool (Twilio, AWS SNS, etc.). Rich formatting and HTML layout require manual review and may need adjustment in Salesforce's Content Builder or the destination channel platform.

Cronberry user and agent records map to Salesforce User. We resolve owners by email match against the Salesforce destination org's User table. Role and permission structures differ significantly between platforms and we do not map Cronberry role hierarchies to Salesforce profiles and permission sets. Users without a matching Salesforce User go to a reconciliation queue for the customer's admin to provision before record import resumes.

Landing Pages are rendered platform assets in Cronberry with no standard export format. We do not migrate Landing Pages. Page content must be recreated manually in Salesforce Experience Cloud or an external landing page tool. We document which landing pages exist in Cronberry (by URL if available) as part of the migration scope so the customer's marketing team can prioritize recreation.

Cronberry campaign workflows built with visual builders have no Salesforce Flow equivalent that we migrate as code. We extract every active Cronberry workflow, document its trigger conditions, action sequence, delays, and channel assignments, and deliver a written workflow inventory with recommended Salesforce Flow rebuild steps. The customer's admin or a Salesforce partner rebuilds the automations post-migration. This is outside standard migration scope.