Migrate from Perfect Books to Odoo CRM

Company-contact N:N relationships require partner category mapping

Perfect Books stores contacts and companies as separate objects with a native many-to-many relationship table. Odoo collapses both into res.partner, where the primary company link is the parent_id field — a one-to-one construct. When a contact in Perfect Books is associated with multiple companies, Odoo has no native equivalent for that N:N mapping. We surface these N:N associations during planning and offer two remediation paths: assign a single primary company per contact and tag secondary associations using partner categories, or retain the full association list in a custom text field on the contact record for manual reconciliation after migration.

Perfect Books Deal objects route to Odoo crm.lead with no lead-versus-opportunity distinction

Perfect Books Deal records have no separate concept of a 'lead' versus an 'opportunity' — deals exist as their own object regardless of qualification status. Odoo's crm.lead model supports both states, but the distinction is determined by the lead_type field and the presence of a partner_id link. When migrating all Perfect Books deals as opportunities, the lead_type is set to 'opportunity' and partner_id is populated from the linked contact or company. However, the logic that determines which Perfect Books records represent raw leads versus qualified deals must be expressed during migration planning — either by inspecting a status or stage field in Perfect Books, or by applying a business rule your team defines — because Odoo has no automated mechanism to retroactively split an already-imported crm.lead into a lead and an opportunity.

Odoo custom fields must exist in the database schema before migration data can map to them

Unlike some CRMs that accept custom field data on import even if the field definition does not yet exist, Odoo requires custom fields to be defined in its schema (via Settings > Technical > Models > Fields in the UI, or via ir.model.fields records) before import data can target those fields by name. FlitStack AI creates all Perfect Books custom field equivalents in Odoo during the planning phase, but if any custom property is missed or renamed during that step, the corresponding data cannot be written to those fields during the migration run. We cross-check the custom field list against the Perfect Books export before committing to the migration plan, and any gaps trigger a schema correction step before data moves.

Odoo Community Edition enforces XML-RPC rate limits that can block large API-based migrations

The Odoo External API (XML-RPC) has no published per-hour request limit in the Community edition, but real-world Odoo Community deployments throttle requests to approximately 5 per hour under heavy load. For migrations involving more than a few thousand records with many fields, this rate limit causes the migration to stall mid-run. FlitStack AI detects throttling during the migration and falls back to Odoo's data import module, which uses batch CSV upload via the web interface and bypasses the API rate limit entirely. This fallback is scoped at the same project price — the CSV import fallback is not an additional charge, but it does require that your Odoo user account has access to the data import module in your Odoo edition.

Perfect Books deal_score and hot_rating fields have no Odoo native equivalent

Perfect Books may carry numeric or categorical scoring properties on deal records — a hot/cold/warm rating or a calculated deal_score — that sales teams use for prioritization. Odoo CRM has no built-in deal scoring or rating field on crm.lead. The values from these fields are preserved as custom fields in Odoo (x_deal_score as an integer, x_rating as a selection field), but Odoo's kanban pipeline view does not natively sort or color-code cards based on these values. Teams that rely on deal_score for pipeline prioritization should plan to configure kanban card coloring or list sorting rules in Odoo after migration using Studio or a custom view.