CRM migration
Field-level mapping, validation, and rollback between Perfectview and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.
Perfectview
Source
Odoo CRM
Destination
Compatibility
9 of 12
objects map 1:1 between Perfectview and Odoo CRM.
Complexity
BStandard
Timeline
4-6 weeks
Overview
Moving from PerfectView to Odoo CRM requires resolving a fundamental schema mismatch at the outset. PerfectView organises data around a single Relation object that conflates company and individual contact data; Odoo CRM separates Companies (res.partner as organisation) from Contacts (res.partner as individual). We split each Relation into the correct Odoo pair using the role and address fields inside the Relation record, validate the split against live data before bulk migration, and preserve owner links throughout. Workflows, automations, and PerfectView's built-in billing logic do not migrate — Odoo implements its own workflow engine (Studio-based or Python) with a different trigger model, so we deliver a written inventory of every active workflow for the customer's admin to rebuild in Odoo Studio or via a certified Odoo partner. Invoice data migrates with line items and payment status, but invoice numbering may require re-sequencing in Odoo's Accounting module post-migration.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Perfectview object lands in Odoo CRM, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Perfectview
Relation
Odoo CRM
res.partner (Company) + res.partner (Contact)
1:manyPerfectView Relation is the primary migration object and conflates organisation and individual contact data into a single entity. We split each Relation into two Odoo res.partner records: one with is_company=True (the organisation) and one with is_company=False (the individual). Role fields inside the Relation determine contact placement; address fields become the organisation address. When a Relation contains only a company with no individual contact, we create only the Company record. We validate the split against a sample of 200-500 records before bulk migration to avoid creating orphaned or duplicate partners.
Perfectview
Activities
Odoo CRM
mail.activity
1:1PerfectView Activities (calls, emails, meetings, tasks) are well-structured and timestamped. They map directly to Odoo's mail.activity model with type field (call, email, meeting, task) preserved. Owner assignment maps to Odoo res.users by email match. Activity date and deadline migrate as activity_date_deadline. Linked Relation references are resolved to the split res.partner records after the Relation split is complete.
Perfectview
Leads
Odoo CRM
crm.lead
1:1PerfectView Lead tracking (whether implemented as a distinct object or a Relation lifecycle stage) maps to Odoo crm.lead. Lead status values from PerfectView map to Odoo stage_id values via a stage mapping table created during scoping. Lead source maps to Odoo's source_id (utm.source). When the source field references a Relation, we resolve the parent res.partner after the Relation split.
Perfectview
Cases (Support Tickets)
Odoo CRM
helpdesk.ticket
1:1PerfectView complaint management and support tickets map to Odoo helpdesk.ticket, which requires the Helpdesk app to be installed in the destination Odoo instance. Case status and priority migrate to ticket stage_id and priority fields. Conversation history inside PerfectView Cases migrates as mail.message records linked to the ticket. If the customer does not license the Helpdesk app, Cases map to crm.lead with a custom ticket_type field as a fallback.
Perfectview
Documents
Odoo CRM
ir.attachment
1:1PerfectView document storage migrates to Odoo ir.attachment records linked to the parent res.partner (for company documents) or crm.lead (for lead documents). Document metadata (filename, MIME type, size, created date) migrates from the PerfectView export. We retrieve documents via PerfectView's API where enabled, falling back to UI-based bulk export for bulk downloads. Odoo stores attachments in its database (filestore) by default; large attachment volumes may require the Odoo documents app for a file-system storage backend.
Perfectview
Quotes
Odoo CRM
sale.order (as quotation)
1:1PerfectView Quotes migrate to Odoo sale.order records in draft state. Quote line items migrate as sale.order.line records with product_id resolved to Odoo product.product entries. Quote pricing and currency migrate as order_line with price_unit and discount fields. Quote-to-Relation links are resolved to res.partner after the Relation split. If the Odoo Sale app is not installed, we flag this during scoping as a prerequisite.
Perfectview
Invoices
Odoo CRM
account.move
1:1PerfectView invoice records migrate to Odoo account.move (with move_type=out_invoice for sales invoices) under the Odoo Accounting module. Invoice line items migrate as move_line records. Payment status from PerfectView (paid, open, cancelled) maps to Odoo payment_state field. Invoice numbers may need renumbering in Odoo due to sequence constraints in the accounting journal; we flag this before migration and the customer's accountant confirms the sequence configuration. This mapping is only available if the Odoo Accounting app is active.
Perfectview
Users/Owners
Odoo CRM
res.users
1:1PerfectView User records and owner assignments on Relation, Activity, Case, and Quote records migrate to Odoo res.users. We resolve owners by email match. Any PerfectView Owner without a matching res.users in the destination Odoo instance is held in a reconciliation queue for the customer's admin to provision before record import resumes. Inactive PerfectView users map to Portal users (res.users with share=True) if the customer wants to grant the contact read-only access to their account.
Perfectview
Custom Fields on Relations
Odoo CRM
ir.model.fields (custom)
lossyCustom fields added to Relations in PerfectView are discovered during the discovery phase via export inspection. We pre-create the equivalent custom fields in Odoo using Developer Mode or an XML data file before migration. Field types are mapped (PerfectView text to Odoo char, PerfectView number to Odoo float or integer, PerfectView date to Odoo date). Selection fields in PerfectView become selection fields or many2one relations in Odoo depending on the number of distinct values.
Perfectview
Workflows/Automations
Odoo CRM
Server Actions (via ir.actions.server)
1:1PerfectView workflow rules, trigger conditions, and automated sequences are not publicly exportable through any PerfectView mechanism. We document all active workflows during the discovery call and deliver a written inventory with trigger, conditions, actions, and recommended Odoo Studio or ir.actions.server equivalent. Workflow reconstruction in Odoo is outside the data migration scope and should be handled by the customer's Odoo administrator or a certified Odoo partner as a separate engagement.
Perfectview
Relation Roles
Odoo CRM
res.partner.category or res.partner
lossyPerfectView Relations can contain multiple contact individuals with distinct roles (CEO, Sales Manager, Billing Contact). After splitting the Relation into a Company and individual Contact records, we preserve the role by linking the individual Contact to the Company via the parent_id field on res.partner. If multiple individuals share the same role, we create additional Contact records. Role labels from PerfectView are stored as a custom field on the individual Contact.
Perfectview
Communication History
Odoo CRM
mail.message
1:1PerfectView stores email threads and communication history linked to Relations. These migrate to Odoo mail.message records attached to the parent res.partner (for company-level communications) or crm.lead (for lead-level communications). Email content and timestamps migrate intact. Attachments within communications migrate as ir.attachment records linked to the mail.message.
| Perfectview | Odoo CRM | Compatibility | |
|---|---|---|---|
| Relation | res.partner (Company) + res.partner (Contact)1:many | Fully supported | |
| Activities | mail.activity1:1 | Fully supported | |
| Leads | crm.lead1:1 | Mapping required | |
| Cases (Support Tickets) | helpdesk.ticket1:1 | Fully supported | |
| Documents | ir.attachment1:1 | Mapping required | |
| Quotes | sale.order (as quotation)1:1 | Fully supported | |
| Invoices | account.move1:1 | Mapping required | |
| Users/Owners | res.users1:1 | Fully supported | |
| Custom Fields on Relations | ir.model.fields (custom)lossy | Fully supported | |
| Workflows/Automations | Server Actions (via ir.actions.server)1:1 | Fully supported | |
| Relation Roles | res.partner.category or res.partnerlossy | Fully supported | |
| Communication History | mail.message1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Perfectview gotchas
Relations object conflates Companies and Contacts
Bulk export function caps at 1000 records per operation
Workflows and automations cannot be exported
API rate limits are not publicly documented
Odoo CRM gotchas
Odoo.sh version gating blocks assisted migrations from trial
Enterprise modules fail to install on Community after database restore
Custom module view inheritance breaks between Odoo major versions
Custom fields risk losing their application context on Community
API access for Community is gated behind the Custom Plan
Pair-specific challenges
Migration approach
Discovery and account audit
We audit the source PerfectView account to establish the full data inventory: Relation count (with role distribution), Activity count by type, Lead status distribution, Case volume, document attachment count, Quote and invoice counts, and custom field definitions. We activate the PerfectView API in account settings during this phase and run a pre-migration load test to discover actual API rate limits. We document all active workflows and automations for the rebuild handoff inventory. The discovery output is a written migration scope with object-level row counts, the Relation split validation plan, and an Odoo edition and app recommendation based on which PerfectView modules are in active use.
Sandbox migration and Relation split validation
We run a sandbox migration using Odoo's database backup restore into a staging environment, or into a fresh Odoo Online trial if the destination is cloud-hosted. We apply the Relation split to a representative sample of 200-500 records and reconcile the output with the customer's admin team. The admin validates that contacts are linked to the correct companies, that role labels are meaningful, and that no duplicate partners were created. Any ambiguous Relations (Relations with no clear primary contact or company address) are triaged and resolved before bulk migration. Mapping corrections at this stage are cheaper than corrections in production.
Schema setup in Odoo destination
We configure the destination Odoo instance: we install the required apps (CRM, Helpdesk, Sale, Accounting based on scope), create custom fields via Developer Mode or XML module definition, configure the crm.lead stage pipeline with stages matching the source Lead status distribution, configure the helpdesk.ticket stages if Cases are in scope, and set the sale.order quotation template if Quotes are in scope. Owner-to-User mapping is validated at this stage. We also configure the ir.sequence for the accounting journal if invoices are in scope, working with the customer's accountant to set the starting sequence number.
Bulk data extraction from PerfectView
We extract all data from PerfectView using the API with chunking to handle the 1,000-record-per-operation cap on bulk export. For large databases, we run parallel export passes using date-range filters (created_after/created_before) to avoid overlap. All Relations are exported with their full field set including custom fields. Activities are exported with parent Relation references preserved for later lookup resolution. Documents and attachments are downloaded via API or UI export and stored in a structured directory tree keyed by Relation ID. GDPR-sensitive fields are flagged in the export for handling under the customer's data-processing agreement.
Production migration in dependency order
We run production migration in record-dependency order: res.partner records first (Relation split applied, companies and contacts created), crm.lead records with res.partner lookups resolved, mail.activity records with User and res.partner references resolved, mail.message records linked to parent records, helpdesk.ticket records, sale.order quotation records, account.move invoice records, ir.attachment records linked to parent records. Each phase emits a row-count reconciliation report and a sample validation against the source data before the next phase begins. Owner mismatches (no matching Odoo User) halt the phase and route to the reconciliation queue.
Cutover, validation, and workflow handoff
We freeze PerfectView writes at a defined cutover timestamp and run a final delta migration of any records modified during the migration window. We enable Odoo as the system of record once the delta phase is confirmed clean. We deliver the workflow inventory document to the customer's admin team with Odoo Studio equivalents for each PerfectView workflow. We support a one-week hypercare window resolving reconciliation issues raised by the customer's team. Post-migration admin support, Odoo Studio workflow rebuilding, and user training are outside the standard migration scope and can be scoped as a separate engagement or handled by a certified Odoo partner.
Platform deep dives
Perfectview
Source
Strengths
Weaknesses
Odoo CRM
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 4 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Perfectview and Odoo CRM.
Object compatibility
4 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
Perfectview: Not publicly documented in summary form..
Data volume sensitivity
Perfectview exposes a bulk API — large-volume migrations stream efficiently.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Perfectview to Odoo CRM migration scoping. Not seeing yours? Book a call.
Walk through your Perfectview to Odoo CRM migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Perfectview
Other ways to arrive at Odoo CRM
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.