Migrate from PropFlo to Odoo CRM

Audit PropFlo data model and Odoo schema dependencies

FlitStack extracts the full PropFlo object inventory via API: leads, contacts, companies, deals, demand notes, AOS records, payment history, channel partners, and activity logs. We map PropFlo's custom fields (tower, unit, floor, carpet area, facing, unit status, booking reference) to Odoo crm.lead custom fields (x_tower_name, x_unit_number, x_floor_number, x_carpet_area, x_facing, x_unit_status, x_booking_reference). We audit Odoo's installed modules to determine whether res.partner, crm.lead, account.payment, and ir.attachment are available, and document any missing dependencies. The output is a field-level mapping spreadsheet with source API paths, destination model/field names, and mapping type (direct, value-map, or custom-field-required). This spreadsheet is reviewed with your Odoo admin before migration runs.

Pre-create Odoo custom fields and stage configuration

Before data moves, your Odoo admin (or our team) creates the custom fields required for real estate data: x_tower_name, x_unit_number, x_floor_number, x_carpet_area, x_facing, x_unit_status, x_booking_reference, x_demand_note_json, x_commission_rate, x_broker_code, and x_original_create_date on crm.lead and res.partner. We also configure crm.stage records matching PropFlo's pipeline stage names and sequence (Inquiry, Site Visit, Token Amount, Booking, Agreement Signed). If PropFlo has multiple pipelines, we create one crm.team per pipeline and map stage names within each team. The Odoo database must have API access enabled (Settings > Developer Mode > API). We deliver a step-by-step checklist with exact Odoo UI paths and field technical names so the schema is ready before any record lands.

Resolve owner and user mappings by email

PropFlo deal and lead owners are user email addresses. Odoo uses res.users records with login credentials. We match PropFlo owner emails against Odoo res.users login values. Any PropFlo owner without a matching Odoo user is flagged before migration with three options: invite the user to Odoo first, assign their records to a fallback Odoo user, or leave user_id blank and reassign manually after go-live. No record migrates without a documented owner resolution decision. Channel partner email addresses that do not match any Odoo user are preserved in a custom field (x_original_owner_email) on the crm.lead record for reference.

Migrate in dependency order with foreign key resolution

We sequence the migration to respect Odoo's foreign key constraints. First: res.partner records for developers, companies, and channel partners with is_company and parent_id resolved. Second: res.partner contact records linked to parent company partners. Third: crm.lead records with type='lead' for PropFlo leads not yet converted to deals. Fourth: crm.lead records with type='opportunity' for PropFlo deals, linked to the partner_id and user_id resolved in step 3. Fifth: account.payment records linked to sale.order or crm.lead by booking reference. Sixth: mail.message activity records linked to crm.lead by original record ID. Seventh: ir.attachment records for AOS PDFs and demand notes linked to crm.lead. Each batch runs against Odoo's XML-RPC API in chunks of 100–500 records with transaction rollback on error. The migration log records the external ID mapping from PropFlo object IDs to Odoo record IDs so subsequent batches can reference them correctly.

Run sample migration with field-level diff

A representative slice migrates first—typically 100–300 records spanning leads, opportunities, channel partners, and a sample demand note or AOS attachment. We generate a field-level diff report comparing source PropFlo values against destination Odoo field values for every mapped column. You verify that unit numbers, deal amounts, stage names, owner assignments, and property custom fields match the PropFlo source. The diff report flags any Odoo field that is blank, truncated, or contains a mismatched value. You approve the sample before the full migration commits. Common verification points include: crm.lead.stage_id corresponds to the correct PropFlo deal stage, x_unit_number is populated on opportunity records, ir.attachment records are linked to the correct crm.lead IDs, and res.partner.parent_id resolves correctly for company-contact hierarchies.

Cut over with delta-pickup and audit log

The full migration runs against Odoo with all records batched and loaded. A delta-pickup window (24–48 hours from the migration start time) captures any PropFlo records modified or created during the cutover—new leads, updated deal stages, or additional payments recorded in PropFlo after the migration snapshot. These delta records are extracted, mapped, and inserted into Odoo as a final batch. FlitStack generates an audit log detailing every record inserted, the source object ID, destination Odoo record ID, and the timestamp of insertion. If reconciliation fails—record count mismatch, missing foreign key references, or data integrity error—one-click rollback reverts the Odoo database to its pre-migration state. Rollback uses a database snapshot taken before the first migration batch. After rollback, the process restarts from the audit point with the corrected mapping.