CRM migration
Field-level mapping, validation, and rollback between Rizer and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.
Rizer
Source
Odoo CRM
Destination
Compatibility
8 of 13
objects map 1:1 between Rizer and Odoo CRM.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Moving from Rizer to Odoo CRM is a cross-platform migration that requires careful handling of Rizer's dual-product data model, its restrictive Starter-tier API budget, and the structural differences between Rizer's flat contact-workflow architecture and Odoo's Lead-to-Opportunity pipeline model. We export from Rizer Social (marketing CRM) and Rize (time-tracking, if in scope) as two separate scoped passes against their respective login domains, normalizing custom field data types before writing to Odoo via its XMLRPC API. Rizer's referral attribution data has no native Odoo equivalent — we preserve it in custom fields. Rizer Workflow sequences do not migrate; Odoo uses stage-based pipeline automation rather than property-triggered branching sequences. We deliver a written Workflow inventory for your Odoo admin to rebuild using Odoo Studio or automated actions 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 Rizer 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.
Rizer
Contact
Odoo CRM
CRM Lead
1:1Rizer Contact maps to Odoo CRM Lead. Standard fields (name, email, phone, address) migrate directly. Rizer's lifecycle_stage property migrates as a custom selection field on the Lead since Odoo does not have a native lifecycle stage concept. Contact source (referral, organic, paid) migrates to a custom char field lead_source__c. We infer field data types from raw values before write because the Referrizer API does not enforce type constraints on custom field read.
Rizer
Company
Odoo CRM
res.partner (company type)
1:1Rizer Company maps to Odoo res.partner with is_company=True. The company_name maps to the partner name field, industry and domain data map to custom char fields, and website is preserved. Odoo uses a unified partner model for both companies and individuals, unlike CRMs that maintain a separate Account object. Company records are created before Lead import so that the parent_id lookup can be resolved at Lead insert time.
Rizer
Client (Rize product)
Odoo CRM
res.partner
1:1Rize Clients map to Odoo res.partner records, mirroring the Company mapping. If the customer uses both Rizer Social (marketing) and Rize (time-tracking), we run two separate export passes against rizersocial.io and rize.io respectively, then consolidate into the same Odoo partner records using email as the dedupe key. Client billing information that has no Odoo CRM equivalent migrates as custom fields on the partner record.
Rizer
Project (Rize product)
Odoo CRM
CRM Lead or custom project model
lossyRize Projects do not have a direct Odoo CRM equivalent. If Odoo Project app is available in the customer's Odoo instance, Projects map to project.project with the Rize Client as the partner_id. If only CRM is available, Projects map to CRM Lead records with a custom project_name__c field and a tag identifying them as converted projects rather than sales leads. We document the chosen strategy during scoping.
Rizer
Task (Rize product)
Odoo CRM
mail.activity or project.task
lossyRize Tasks nested under Projects map to project.task if Odoo Project is installed, or to CRM Lead activities (mail.activity) if only the CRM app is available. Subtask indicators (a boolean or count field in Rizer) expand into discrete activity records with a parent reference. We flatten the hierarchy during migration and tag each record with its source project context.
Rizer
Team Member
Odoo CRM
res.users
1:1Rizer Team Members map to Odoo res.users records. We match by email address. Any Rizer Team Member without a matching Odoo User goes to a reconciliation queue for the customer's admin to provision before Lead and Opportunity import resumes. Role assignments (admin, manager, member) map to Odoo access rights groups: system access maps to Settings > Users, sales access maps to Sales > User, and manager access maps to Sales > Manager.
Rizer
Referral Data
Odoo CRM
Custom fields on CRM Lead
lossyRizer's referral tracking sources, attribution windows, and UTM parameters are stored on Contact records with no native Odoo equivalent. We create custom fields on the CRM Lead — referral_source__c (char), referral_campaign__c (char), attribution_window__c (date range stored as two date fields), and utm_medium__c / utm_campaign__c (char) — to preserve this data. Attribution history spanning multiple sources is stored as a text field with pipe-delimited values. This data is preserved for future reporting once the customer rebuilds attribution logic in Odoo.
Rizer
Tag
Odoo CRM
crm.tag
lossyRizer Tags are flat string lists applied to Contacts. Odoo CRM uses crm.tag records attached via a many2many relation. We normalize tag values at migration time — removing duplicates, standardizing casing — and create crm.tag records on demand during import. Tags used for contact classification map directly; tags used for workflow routing do not migrate (Workflow rebuild is out of scope) but are preserved as crm.tag records for the admin to reassign post-migration.
Rizer
Custom Field (on Contact)
Odoo CRM
Custom field on CRM Lead
1:1Rizer custom fields on Contact map to custom fields on the CRM Lead created via Odoo Studio or directly in the data model. We inspect the raw field values to infer the correct Odoo field type — date strings become date fields, numeric strings become float or integer fields, delimited multi-select strings become char fields with the delimiter noted for the admin to convert to tags. Date fields stored as ambiguous strings are flagged for manual verification before write. This type-inference step is critical because the Referrizer API returns all values as strings without type metadata.
Rizer
Workflow
Odoo CRM
Written inventory (no code migration)
1:1Rizer Workflows are property-triggered email and SMS sequences with branching logic, delay rules, and tag triggers attached to Contact lifecycle stages. Odoo CRM uses stage-based automated actions and Odoo Studio rules, which are fundamentally different trigger models. We do not migrate Workflows as code. We deliver a written inventory of every active Rizer Workflow with its trigger condition, sequence steps, delays, tag actions, and a recommended Odoo automated action equivalent for the customer's admin to rebuild. The inventory is delivered as a structured document, not as migrated automation objects.
Rizer
Engagement: Email, Call, Meeting, Note
Odoo CRM
mail.message or mail.activity on Lead
1:1Rizer communication history (emails, calls, meetings, notes) attached to Contact records maps to Odoo mail.message records on the CRM Lead. Call duration and disposition migrate as custom fields on the message. Meeting time and location migrate as mail.activity records of type 'meeting'. The migration complexity depends on what Rizer's API exposes per engagement — we inspect the API response during discovery to determine whether engagements are available as structured records or require parsing from contact activity feeds. Historical engagement data is preserved as notes if structured records are unavailable.
Rizer
Engagement: Task
Odoo CRM
mail.activity on Lead
1:1Rizer Task engagements (separate from Rize Project Tasks) attached to Contact records migrate to Odoo mail.activity records on the CRM Lead. Task subject, due date, priority, status, and assignee migrate directly. HubSpot-style task assignment (hubspot_owner_id) resolves via the User email mapping to an Odoo res.users OwnerId equivalent on the activity.
Rizer
Rizer Marketing Automation Tier vs Rize Time-Tracking Tier
Odoo CRM
Separate scoped export passes
lossyRizer Social and Rize are separate products with separate login domains (rizersocial.io and rize.io), separate data models, and separate API endpoints. We treat them as two distinct export scopes. The marketing CRM migration covers Contacts, Companies, Workflows, and Engagements. The time-tracking migration covers Clients, Projects, Tasks, and Team Members. Both exports run in parallel passes and consolidate into the same Odoo instance via partner dedupe by email. Customers who only use Rizer Social scope the migration to the CRM data only.
| Rizer | Odoo CRM | Compatibility | |
|---|---|---|---|
| Contact | CRM Lead1:1 | Fully supported | |
| Company | res.partner (company type)1:1 | Fully supported | |
| Client (Rize product) | res.partner1:1 | Fully supported | |
| Project (Rize product) | CRM Lead or custom project modellossy | Fully supported | |
| Task (Rize product) | mail.activity or project.tasklossy | Fully supported | |
| Team Member | res.users1:1 | Fully supported | |
| Referral Data | Custom fields on CRM Leadlossy | Mapping required | |
| Tag | crm.taglossy | Fully supported | |
| Custom Field (on Contact) | Custom field on CRM Lead1:1 | Fully supported | |
| Workflow | Written inventory (no code migration)1:1 | Fully supported | |
| Engagement: Email, Call, Meeting, Note | mail.message or mail.activity on Lead1:1 | Fully supported | |
| Engagement: Task | mail.activity on Lead1:1 | Fully supported | |
| Rizer Marketing Automation Tier vs Rize Time-Tracking Tier | Separate scoped export passeslossy | 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.
Rizer gotchas
API call budget on Starter tier is migration-critical
Dual-product data model requires separate export scopes
Custom field data types are not validated at export time
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 tier assessment
We audit the Rizer account across both products (Rizer Social and Rize) to catalog all object types in active use, total record counts per object, active Workflow count and complexity, engagement history volume, and custom field definitions. We identify the Rizer tier in use and confirm API call budget against the export volume estimate. We assess the destination Odoo instance: edition, installed apps (CRM only vs CRM plus Project), existing custom fields, and current pipeline configuration. The discovery output is a written migration scope with record counts, a list of Odoo custom fields to create, and a Workflow inventory template for the Rizer admin to complete.
Odoo custom field creation and pipeline configuration
We create all required custom fields on the CRM Lead model in Odoo before any data migration begins. This includes referral_source__c, referral_campaign__c, attribution_start__c, attribution_end__c, utm_medium__c, utm_campaign__c, and any Rizer custom contact fields mapped during discovery. Custom fields are created via Odoo Studio or XMLRPC write to ir.model.fields. We configure the CRM pipeline stages to match the Rizer lifecycle stages where possible, and add a stage for converted Projects if the Project app is not available. The pipeline configuration is validated in a staging environment before production deployment.
Rizer export with rate-limit management
We export from Rizer using the documented API endpoints, with chunking and pagination to stay within the tier's API call budget. For Starter-tier accounts, we recommend upgrading to Growth before export begins. We run exports in dependency order: Companies first (for partner dedupe), then Contacts (with CompanyId resolved), then Team Members (for owner mapping), then Tasks and Projects (if Rize is in scope), then Engagements last. We apply the custom field type inference step to every Contact custom field value before staging the export data. If the 429 response is returned mid-export, we re-authenticate and resume from the last processed record ID.
Sandbox validation and owner reconciliation
We run the full migration into an Odoo staging or test database before production. The customer reconciles record counts (Leads in, Partners in, Activities in), spot-checks 25-50 records against the Rizer source, and validates that custom fields populated correctly. We run owner reconciliation: Rizer Team Members are matched by email against Odoo res.users. Any Rizer user without a matching Odoo User is held in a queue for the customer's admin to provision. Migration cannot complete the activity assignment step until all referenced owners have an Odoo User record.
Production migration in dependency order
We run production migration in strict dependency order: res.partner records first (from Rizer Company and Rize Client), then CRM Leads (with partner_id resolved where a company exists), then crm.tag records and Lead-tag associations, then mail.message and mail.activity records (engagement history), then project records and project.task records if Odoo Project is installed. Each phase emits a row-count reconciliation report before the next phase begins. Workflow records are not migrated as code — we deliver the written Workflow inventory at this point for the admin to begin Odoo Studio rebuild work.
Cutover, validation, and Workflow rebuild handoff
We freeze writes in Rizer during cutover, run a final delta migration of any records modified during the migration window, then enable Odoo CRM as the system of record. We deliver a cutover validation report: record counts per object, spot-check sign-off, and custom field fill rates. We deliver the Workflow inventory document to the customer's admin team with Odoo automated action equivalents documented for each Rizer Workflow. We support a one-week hypercare window for reconciliation issues. We do not rebuild Rizer Workflows as Odoo automated actions inside the migration scope; that is a separate engagement or an internal admin task.
Platform deep dives
Rizer
Source
Strengths
Weaknesses
Odoo CRM
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 1 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 Rizer and Odoo CRM.
Object compatibility
1 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
Rizer: 500 API calls/month on Starter; 5000 on Growth; Enterprise unlimited — exact per-second throttling not publicly documented.
Data volume sensitivity
Rizer doesn't expose a bulk API — REST + parallelization used for high-volume runs.
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 Rizer to Odoo CRM migration scoping. Not seeing yours? Book a call.
Walk through your Rizer 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 Rizer
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.