Migrate from Bridgify to Odoo CRM

Bridgify contact records (travelers, program members) map to Odoo res.partner with is_company=False. The contact's email, phone, and address fields align directly. Owner assignment resolves by email match against Odoo res.users — unmatched owners default to the migration admin user. All original contact metadata is preserved through custom fields during migration.

Bridgify accounts representing travel brands, loyalty programs, or tour operators map to Odoo res.partner with is_company=True. The company name, domain, and industry fields map to name, website, and industry respectively. Parent-company hierarchies in Bridgify translate to parent_id on res.partner — circular references are flagged before import.

Confirmed Bridgify bookings migrate as Odoo crm.lead records with type='opportunity'. The booking amount maps to expected_revenue for pipeline visibility. Odoo lacks a native booking object, so crm.lead serves as the closest analogue for tracking pipeline value against travel experiences. The original booking ID is preserved as x_booking_id.

Bridgify booking status strings (confirmed, pending, cancelled) map to Odoo crm.stage records by value. Each Bridgify status value gets assigned to a corresponding Odoo stage ID based on your Odoo pipeline configuration — cancelled bookings route to the Lost stage, confirmed to Won or a custom Closed stage.

Bridgify experience records map to Odoo product.product (or product.template for experience categories). The experience name, description, pricing, and availability window transfer as standard Odoo product fields. Multiple Bridgify experience variants (e.g., group vs. private) map to Odoo product variants via product.attribute.line records.

Bridgify loyalty_tier values (Gold, Silver, Bronze, etc.) have no Odoo native equivalent. We create an ir.model.fields record (x_loyalty_tier) on res.partner as a selection field with the exact Bridgify tier values preserved. Points balance migrates as x_loyalty_points (float) on the same partner record.

Bridgify experience categories (tours, attractions, activities) map to Odoo product.category records. The category name and description transfer directly. Products link to categories via product.categ_id — this relationship is established during the product import phase. New categories are created in Odoo if the Bridgify category does not already exist.

Bridgify booking line items (individual experience reservations within a booking) merge into Odoo sale.order.line records linked to a parent sale.order. Each line references the corresponding product.product record migrated from Bridgify. Quantity and unit price map to product_uom_qty and price_unit respectively.

Bridgify owner_id on contacts and bookings resolves by email match against Odoo res.users. Unmatched owners are flagged — your Odoo admin either creates the user first or assigns records to a fallback owner. Bridgify user records with no Odoo counterpart become notes in the migration audit log.

Bridgify contact address fields (street, city, state, country, zip) map to Odoo res.partner address fields (street, city, state_id, country_id, zip). Country names resolve to Odoo res.country records by name match. State and province names resolve to res.country.state records where applicable. Incomplete addresses in Bridgify carry forward with null fields in Odoo.

Bridgify booking confirmation date maps to crm.lead.date_deadline for pipeline visibility and scheduling. The original booking creation timestamp is preserved as x_booking_create_date (custom datetime field on crm.lead) for audit continuity. Both dates are retained to support historical reporting and timeline analysis post-migration.

Bridgify contact tags (segment labels, traveler types) map to Odoo res.partner.category records. Tags that do not already exist in Odoo are created during migration. A contact can have multiple tags in both systems — the many-to-many relationship transfers via the res.partner.res_partner_category_rel junction table during the tag import phase.