Migrate from Fireberry to Salesforce Sales Cloud

Fireberry's Contact object has no separate Lead equivalent — all person records live as Contact with no pre-conversion state. We map Fireberry Contacts to Salesforce Leads if they represent unqualified prospects with no associated Opportunity, and to Salesforce Contacts if they have an associated Company and Deal history. We use Fireberry's contact status property to determine the split and preserve the original Fireberry contact record identifier in a custom field fb_contact_id__c for audit reconciliation.

Fireberry Company records map directly to Salesforce Account. The Company name becomes Account Name, industry and size fields map by type, and the address structure migrates as billing or shipping address depending on how the customer uses the field. Account is created before Contact import so the AccountId Lookup is satisfied at insert time.

Fireberry Deals map to Salesforce Opportunity. The deal amount, stage, probability, and expected close date migrate directly. We resolve the linked Company (Account) and Contact (Contact) references before Opportunity insert so that related records are intact at import time. Closed-Lost and Closed-Won dates preserve from Fireberry's stage-history timestamps if available.

Each Fireberry Pipeline becomes a Salesforce Opportunity Record Type with a corresponding Sales Process that whitelists the pipeline's stage values. Stage ordering and probability percentages migrate to Salesforce StageName and StageProbability. We configure these in the destination org before any Opportunity data loads so that stage validation rules do not reject records on import.

Fireberry stage names map to Salesforce StageName values. We preserve the stage sequence order and probability. If Fireberry uses custom stage colors or labels, we capture these in the migration manifest and recommend equivalent Salesforce Lightning stage picklist styling as a post-migration configuration step.

Fireberry Custom Objects — exposed via the Component system and identified during schema discovery — map to Salesforce custom objects with __c API names. We pre-create the destination schema including all custom fields, field types (text, number, picklist, date, lookup), and any lookup relationships to standard objects before importing custom object records. The customer reviews the schema mapping document and approves field-type decisions before migration begins.

Standard objects in Fireberry (Contact, Company, Deal) may carry additional custom fields beyond the base schema. We enumerate these during schema discovery, map each to a Salesforce custom field on the equivalent standard object, and flag any picklist, formula, or rollup-type fields that require special handling during import. Picklist value sets are pre-created in Salesforce to avoid import rejections from undefined picklist values.

Fireberry Activities map to Salesforce Task (for calls and tasks) and Event (for meetings). We use the Bulk API 2.0 to handle volume efficiently and preserve ActivityDate timestamps so that the Salesforce activity timeline reflects the correct chronological order. Call disposition and duration migrate to custom Task fields if configured. Notes migrate as Salesforce Note records linked via ContentDocumentLink to the parent Contact, Account, or Opportunity.

Fireberry tags on Contacts and Companies migrate as a multi-select picklist field or as a comma-separated custom text field depending on the customer's downstream use case. The customer chooses during scoping. If tags are used for segmentation, we recommend a multi-select picklist; if used for flexible categorization, a text field preserves more tag variety without picklist value management overhead.

Fireberry file attachments stored against records export as download references. We preserve the original filename, file type, and download URL in a Salesforce custom field fb_attachment_ref__c. The customer reviews and re-uploads files post-migration if the original hosting is not accessible, or we upload directly if the source export includes binary content. This is a manual handoff step noted in the migration manifest.

Fireberry Users map to Salesforce Users by email address match. We extract every distinct Owner referenced on Contact, Company, Deal, and Activity records. Owners without a matching Salesforce User go to a reconciliation queue. The customer's Salesforce admin provisions missing Users (active or inactive depending on whether the original Fireberry user is still employed) before record import resumes.

Fireberry automation rules are captured as structured text records during migration scoping — trigger type, conditions, and actions — but cannot be exported as reusable definitions. We deliver a written inventory of every active automation with a recommended Salesforce Flow equivalent and the customer's admin rebuilds them post-migration. We do not migrate automations as code.