Migrate from Checkbox to Odoo CRM

Checkbox contact profiles (respondent name, email, phone) map directly to Odoo res.partner records. Email address is the primary key for de-duplication. If Checkbox stores a respondent without a company, res.partner is created as an individual contact with no parent_id. Additional fields such as job title, street, city, and website are transferred when present, ensuring the Odoo partner record reflects the full respondent profile.

Checkbox company records associated with a submission map to res.partner with is_company=True. Parent-child company hierarchies in Checkbox translate to parent_id on res.partner in Odoo. Multi-company associations on a single contact are resolved to a primary partner_id with others stored as contact relations.

Checkbox intake form submissions translate to Odoo crm.lead records with type='opportunity'. Each distinct Checkbox form becomes a separate Odoo pipeline or a named tag on crm.lead so teams can filter by originating intake workflow. The submission's status field in Checkbox maps to the crm.lead stage_id.

Each Checkbox form field becomes an Odoo custom field on crm.lead (x_checkbox_field_name). Field type is preserved: text fields map to char/text, date fields to date, pick-list fields to selection. Original submission ID is stored as x_checkbox_submission_id for traceability. The naming convention (x_checkbox_) avoids conflicts with standard Odoo fields. Required Checkbox fields are set as required=True in Odoo, and help text is copied to the custom field description for user guidance.

Odoo's create_date on crm.lead reflects the migration date, not the original Checkbox submission date. FlitStack preserves the original submission timestamp as x_checkbox_submission_date so reporting shows the correct historical timeline. This ensures that Odoo dashboards, activity deadlines, and scheduled actions based on date criteria use the actual intake date rather than the migration import date. The custom field is indexed for fast filtering and used in all standard Odoo reports.

Checkbox user assignments on submissions are resolved by email match against Odoo res.users. Unmatched owners are flagged before migration for team assignment to a fallback Odoo user. No submission lands in Odoo without an assigned user_id on the crm.lead. If multiple Odoo users share the same email (e.g., aliases), the primary user is selected, and the alias mapping is recorded for future reference.

Approval comments and review notes from Checkbox workflows migrate as mail.message records on the crm.lead in Odoo, preserving the original reviewer name, timestamp, and comment text. This maintains the full audit trail of the intake review process. The mail.message records also retain any attachments linked to the review, ensuring that supporting documents are accessible directly from the Odoo lead chatter.

Checkbox file attachments are downloaded and re-uploaded to Odoo as ir.attachment records linked to the target crm.lead or res.partner. Odoo's 25MB per-file limit applies; files exceeding this are flagged for chunked upload or alternative storage before migration. During re-upload, the original file name and MIME type are preserved in the ir.attachment's name and mimetype fields, and the attachment's res_model and res_id are set to reference the correct Odoo record.

Checkbox custom form objects that have no direct Odoo CRM equivalent are created as custom Odoo models via Studio or Python module, then linked to crm.lead via a many2one field. The migration plan identifies these during the assessment phase. These custom models include fields for each data element captured in the Checkbox form, and they are registered in the Odoo registry to ensure proper data integrity during the migration run.

Checkbox integrations with Slack, Salesforce, Ironclad, or other third-party tools do not transfer. They must be reconfigured in Odoo using Odoo's native connectors, webhooks, or the Odoo App Store integrations. FlitStack documents each integration for manual rebuild. Each documented integration includes the original trigger conditions, payload structure, and recommended Odoo configuration steps to streamline the rebuild process.