Migrate from Forms On Fire to Pipedrive

Form submissions are not CRM contacts — mapping requires a decision on what becomes a Person vs a Deal

Forms On Fire stores submission records that contain field values but do not follow a contact-object model. Pipedrive's data model requires either a Person, an Organization, or a Deal as the primary record. We recommend routing form submissions with person-identifying fields (name, email, phone) to Pipedrive Person records, with the full submission payload attached as a Note and key values promoted to custom fields. Submissions that represent deal-worthy events (e.g., a quote-request form) may warrant a Deal record instead. This routing decision must be made per form before migration begins — Pipedrive has no equivalent concept of a raw form submission that sits between a contact and a deal.

Pipedrive custom field keys are per-account hashes — pre-creation is mandatory before bulk write

Pipedrive generates a unique 40-character hex hash as the key for each custom field at the time of creation. The same field name in two different Pipedrive accounts produces different keys. This means a migration script built for one Pipedrive account cannot be reused for another without re-creating the custom fields first. We create all required Pipedrive custom fields in the destination account before the migration run, capture the generated hash keys, and then use those keys to write submission data. This two-step process (create-then-write) adds planning time but is required — Pipedrive API does not support referencing custom fields by human-readable name in write operations.

Forms On Fire file attachments require download and re-upload — max 25MB per file in Pipedrive

Forms On Fire stores file attachments (photos, signatures, documents) in its own cloud storage. Pipedrive Files attach to CRM records via its own file storage. We download each attachment from Forms On Fire and upload it to Pipedrive. Pipedrive enforces a 25MB per-file limit. Files exceeding this limit must be flagged for manual handling or stored externally with a link in Pipedrive. This handling adds time for migrations with heavy photo or document attachment volume — especially field inspection forms with multiple image fields per submission.

Forms On Fire Data Source tables have no Pipedrive equivalent — pick-list size and rebuild scope matter

Forms On Fire Data Sources are standalone tables (product catalogs, price lists, employee directories) that power Choice and Data field lookups within forms. Pipedrive has a Products catalog for product pricing but no general-purpose reference-table feature. Small Data Source lists (under 100 rows) can be recreated as Pipedrive custom field enum options. Larger lists require a rebuild strategy: either the Pipedrive Products catalog, a custom integration with an external data store, or a no-equivalent reference preserved as a CSV export. The size and update frequency of each Data Source must be inventoried before migration to determine the appropriate rebuild path.

Pipedrive API v2 token-based rate limits affect extraction duration for large Forms On Fire datasets

Pipedrive introduced token-based API rate limits in December 2024, with limits varying by plan tier. Large migration extractions from Forms On Fire — especially those with 50,000+ submission records and multiple file attachments — may hit Pipedrive write rate limits during the migration run. We implement exponential backoff and batch sizing adjustments per Pipedrive's 429 responses. Enterprise and Power plan users receive higher rate limits; Essential and Advanced plan migrations may require extended overnight runs. This is surfaced during scoping so expectations are set before migration day.