Migrate from Forms On Fire to Odoo CRM

Form field JSON values require field-by-field parsing before Odoo write

Forms On Fire stores all field values for a submission in a single JSON body keyed by the field's data_name. A Location field stores {latitude, longitude, address_string} in one key; a Choice field stores the selected row key. Odoo's crm.lead.create() method requires values for each field by ORM field name. FlitStack parses the JSON per field type — extracting lat/lon from Location objects, resolving Data Source row keys to Odoo partner IDs for many2one targets, and writing float values for numeric fields. Any field type not recognized is written as-is to a generic x_raw_data text field and flagged in the audit log. This parsing step is the primary reason Forms On Fire migrations require a custom migration script rather than a generic CSV import.

GPS location captures do not write to Odoo's native address fields without geo_coding

Odoo CRM stores location on res.partner via street, city, state_id, country_id, and zip — it does not have a native latitude/longitude field on crm.lead. Forms On Fire's Location field captures GPS coordinates directly from a device sensor, bypassing address entry. FlitStack writes the address string (when present) to the partner's address fields for Odoo's geo_coding widget to resolve coordinates. When only GPS lat/lon is present without an address string, FlitStack stores the coordinates in x_gps_latitude__c and x_gps_longitude__c on the lead — the admin must enable Odoo's geo_localize feature or run a geo-coding batch job to plot them on a map view. This is a manual post-migration step that teams should plan for.

Data Source filter formulas cannot be migrated — rebuild is required

Forms On Fire Data Sources support formula-based row filtering using expressions like [field] > value or referencing other form fields. Odoo ir.model.fields.selection lists are static and do not support formula-driven filtering. When a Data Source is the source of a Choice field on a form, FlitStack migrates the current row values as static selection options or creates partner lookup records, but the filter formula logic is lost. Teams must rebuild dynamic filtering as Odoo onchange methods, domains on many2one fields, or Studio conditions. FlitStack exports the full Data Source configuration including filter formulas as a JSON document for the Odoo developer to reference during rebuild.

Forms On Fire Standard plan 1,500-entry cap truncates large historical datasets

Forms On Fire Standard edition limits submissions to 1,500 per user per month. Teams with multi-year histories accumulating tens of thousands of entries may have truncated or archived data depending on their plan tier and data retention settings. FlitStack's pre-migration audit reports the total submission count versus the exportable count so the team can determine whether to purchase a higher-tier export, use an API-based extraction on a higher plan, or accept that older archived submissions are not recoverable. This is disclosed upfront in the scoping report and affects whether the migration covers 100% of historical data.

Attachment files stored outside Odoo's filestore require re-upload with new URLs

Forms On Fire manages its own blob storage for photo, signature, and document attachments, accessible via API with signed URLs or download tokens. Odoo stores attachments in its own filestore (filestore/ directory) or as base64 in the database's ir.attachment.datas column. FlitStack downloads each attachment from Forms On Fire, uploads it to the target Odoo instance via /api/attachment/endpoint, and writes the returned Odoo ir.attachment.id back to the lead record. Large photo attachments exceeding Odoo's file size limits (default 25MB per file) are split with a warning in the audit log. Inline images embedded in text notes are extracted and saved as separate ir.attachment records.