Migrate from Spiro to Odoo CRM

Spiro Companies map to Odoo res.partner records with partner_type set to company. The company name, address fields, phone, website, and industry classification migrate directly. We use company name as the dedupe key during import and resolve any duplicate Spiro Companies representing the same legal entity into a single Odoo partner record with address fields merged. Spiro Company custom fields are pre-created as ir.model.fields on res.partner before import.

Spiro Contacts map to Odoo res.partner records with partner_type set to individual and a parent_id linking to the mapped Company partner. Name, email, phone, mobile, job title, and department migrate directly. The parent partner must exist before contact import so the parent_id foreign key is satisfied. Spiro Contact custom fields migrate to custom ir.model.fields on res.partner.

Spiro Opportunities map to Odoo crm.lead records. The Spiro Opportunity name becomes crm.lead.name; stage maps to Odoo stage_id via the stage name lookup within the target crm.team pipeline; expected_revenue and probability migrate to the Odoo fields of the same name. Close date maps to date_deadline. We flag any Spiro Opportunities with unrecognised stage names for manual Odoo stage creation before import.

Spiro Opportunity stage names are extracted during discovery and mapped to Odoo crm.stage records within the target crm.team. Each Spiro stage gets a corresponding Odoo stage with the same sequence order and a probability percentage matching Spiro's values. Odoo's default stages (New, Qualified, Proposal Sent, Won, Lost) are used as the base template if the Spiro pipeline stages do not map cleanly to a custom set.

Spiro's single workspace pipeline maps to one Odoo crm.team with the team's default stage set created in the previous step. If the customer uses Spiro's pipeline structure to separate lines of business, we create multiple crm.team records in Odoo and assign Opportunities to the correct team during import based on Spiro's pipeline assignment metadata.

Spiro Users map to Odoo res.users records. We match by email address during import. Any Spiro User without a matching Odoo User is held in a reconciliation queue; the customer's Odoo admin provisions the missing User before record import resumes. Owner assignments on Opportunities and Activities resolve via the User mapping at migration time.

Spiro email engagements map to Odoo mail.message records with message_type=email, linked to the target res.partner via res_id and model=res.partner. Email subject, body, sender, and recipient migrate. If Spiro email sync was broken at any point (a known Spiro gotcha), those emails are absent from the export and cannot be backfilled post-migration.

Spiro call engagements map to Odoo mail.activity records with activity_type_id referencing the built-in Call activity type. Call duration, disposition, and notes migrate to activity-specific custom fields we create on mail.activity. The activity_date_deadline is set to the original Spiro call timestamp, and the activity is linked to the res.partner Contact record.

Spiro meeting engagements map to Odoo mail.activity with activity_type_id referencing the built-in Meeting type. If the customer requires full calendar event detail, we also create calendar.event records linked to the activity. Meeting title, start datetime, end datetime, location, and attendee list migrate.

Spiro task engagements map to Odoo mail.activity with activity_type_id = Task. Spiro note engagements (free-text notes attached to a Contact or Company) map to mail.message records with subtype comment, linked to the parent res.partner. Note body migrates as plain text; any embedded file references are resolved separately.

Spiro stores attachments as linked URLs rather than embedded blobs. During migration we verify each attachment URL is reachable, download the file content, and create Odoo ir.attachment records linked to the target res.partner or crm.lead via res_id and model. If the Spiro workspace access is revoked post-migration, attachment links become orphaned. We recommend downloading critical files before the migration window closes.

Spiro custom field definitions (on Companies, Contacts, and Opportunities) must be extracted from Spiro's UI during discovery or confirmed with a Spiro CSM since there is no documented public endpoint. We pre-create matching custom ir.model.field records in Odoo before data import begins, using field type mapping (Spiro text -> char, Spiro number -> float, Spiro date -> date, Spiro picklist -> selection). Custom field values migrate with the parent object.

Spiro's Data Collector produces CSV file drops in a Dropbox folder. We do not rely on Data Collector as the primary export path because it requires CSM enablement (adding 3-5 business days) and produces flat CSV files without relationship keys. We use Data Collector as a reference export for data validation, and we extract the primary record data directly via Spiro's internal export endpoints or UI-based extraction when available. The Odoo import runs via XML-RPC batch calls with 500-record chunks and exponential backoff on rate-limit responses.