Migrate your Fireberry data

Standard Contact object with name, email, phone, address, owner assignment, and lifecycle stage. Fireberry exposes all standard fields via its export mechanism. We map contact records 1:1 and preserve the Owner/User linking to ensure reassignment is intact at the destination.

Company records store business details, industry, size, and address. The Company-to-Contact relationship is preserved during migration by maintaining the foreign-key linkage in our import sequencing.

Deals carry standard fields: amount, stage, probability, expected close date, and pipeline assignment. We map deal records including their linked Company and Contact references and preserve stage ordering from the source pipeline.

Fireberry supports multiple named pipelines each with configurable stages. We extract pipeline definitions and stage ordering and reconstruct them at the destination, flagging any stages that have no associated deal records for the customer's review.

Activities include notes, calls, meetings, and tasks. Fireberry's export includes activity records with timestamps and owner IDs. We map them but note that activity timestamps and linked records may require post-migration validation for large histories.

Custom Objects are user-defined containers with custom fields — Fireberry's 'Components' system extends standard objects this way. We discover the full schema at migration time via the customer's Fireberry export and map custom object records field-by-field, flagging any relationship fields that need manual re-linking at the destination.

Standard objects like Contact and Deal can carry additional custom fields beyond the base schema. The export must be scoped to include these. We flag any picklist or formula-type custom fields that may not round-trip cleanly and recommend a field-mapping review before import.

Fireberry automations are defined as trigger-action pairs (time-based, event-based, or URL-call). Our export captures workflow definitions as structured records, but rebuilding equivalent automations in the destination system requires a rules-translation step per workflow — we document each one for the customer to review.

Fireberry supports tagging on Contacts and Companies. Tags are exported as flat lists per record. We map tags as a comma-separated custom field or as native tags at the destination if the target supports it.

File attachments stored against records are included in Fireberry exports as download references. We preserve attachment links and note that any attachments hosted internally by Fireberry require re-upload to the destination's storage during migration.

User records include name, email, role, and team assignment. We map active users and flag any inactive or deactivated accounts so the customer can decide whether to include historical owner data or reassign records to active owners.

Fireberry's reporting views are configuration-dependent and not exportable as reusable report definitions. We migrate the underlying data so dashboards can be rebuilt in the destination system, but the report configurations themselves do not transfer.