Migrate from Fireberry to Pipedrive

Fireberry Contact records map 1:1 to Pipedrive Person. The standard name, email, phone, address, and owner fields transfer directly. Fireberry lifecycle stage properties map to a custom picklist field on Person since Pipedrive Person has no native lifecycle stage concept. We resolve owner assignments by email against the Pipedrive User table during import.

Fireberry Company records map to Pipedrive Organization. Business details, industry classification, size, and address fields transfer directly. The Company-to-Contact relationship is preserved by maintaining Organization ID references on the Person records during import sequencing. We create Organization records before Person records so that the Organization lookup is satisfied at the moment of Person insert.

Fireberry Deals map directly to Pipedrive Deals with amount, stage, probability, expected close date, and pipeline assignment preserved. Fireberry custom fields on Deal migrate to Pipedrive custom fields on Deal. We map the dealstage property to the Pipedrive stage_id within the designated pipeline. Closed-Won and Closed-Lost reasons from Fireberry custom properties map to Pipedrive Lost Reason custom fields.

Fireberry pipelines with configurable stages map to Pipedrive pipelines. We extract pipeline names, stage names, stage ordering, and probability percentages and configure matching Pipedrive pipelines and stages. Fireberry stages with no corresponding Pipedrive stage are flagged for the customer to decide whether to create new stages or consolidate into existing ones before migration. This step requires Pipedrive Advanced tier or above for multiple pipelines; Lite is limited to one pipeline.

Fireberry activity records (calls, emails, meetings, tasks) do not have a native Pipedrive equivalent because Pipedrive has no activity object. We transform activities into Pipedrive Notes attached to the relevant Person, Organization, or Deal. Each Note includes the original activity type, timestamp, duration (for calls), and body content. The customer reviews the mapping strategy during scoping to determine whether they want all activities migrated or a filtered subset of the most recent ones.

Pipedrive does not have native custom objects. We map Fireberry custom objects to a dedicated Organization record (created per unique custom object instance) with all custom object fields stored as custom fields on that Organization. For Fireberry custom objects that represent independent entities rather than related records, we recommend mapping them to Pipedrive Organizations and using a naming convention (e.g., ObjectName_RecordId) to distinguish them from actual business organizations. The customer chooses the strategy during schema design.

Standard Fireberry objects carrying custom fields (Contact, Company, Deal) migrate to Pipedrive custom fields on the equivalent object. We discover all active custom fields during the schema-discovery step before migration. Picklist-type custom fields in Fireberry map to Pipedrive select or multiple-select custom fields; text and number fields map to text or number fields respectively. Formula-type custom fields require business logic review because Pipedrive does not support formula fields.

Fireberry User records (name, email, role, team assignment) map to Pipedrive Users. We resolve owners by email match during migration. Any Fireberry Owner without a matching Pipedrive User goes to a reconciliation queue for the customer's admin to provision before record import resumes, because OwnerId is a required reference on Person, Organization, and Deal records in Pipedrive.

Fireberry tags on Contacts and Companies migrate as a comma-separated text value in a Pipedrive custom field named Tags. Pipedrive has no native tag object on Person or Organization, so the tag list is stored as a read-only or manually-editable text field. The customer chooses whether to use a text field or suppress tag migration during scoping.

File attachments stored in Fireberry export as download references or file blobs. We preserve attachment URLs in a Pipedrive custom field or Note on the parent record. Any attachments hosted internally by Fireberry require re-upload to Pipedrive's file storage because Fireberry's internal hosting does not persist after account closure. We document every attachment reference and the parent record it belongs to so the customer can re-upload manually or via the Pipedrive Files API.

Fireberry automations are Component-based trigger-action pairs (time-based, event-based, or URL-call) stored as configuration that cannot be exported as reusable definitions. We capture each workflow's trigger, conditions, and actions as a structured record during migration scoping and deliver a written inventory mapping each Fireberry automation to a Pipedrive Workflow equivalent (or flagging that no direct Pipedrive equivalent exists). The customer's Pipedrive admin rebuilds the automations in Pipedrive's Workflow editor post-migration. This applies to Pipedrive Advanced tier and above.