CRM migration
Field-level mapping, validation, and rollback between Case Status and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.
Case Status
Source
Odoo CRM
Destination
Compatibility
10 of 10
objects map 1:1 between Case Status and Odoo CRM.
Complexity
BStandard
Timeline
24–72 hours
Overview
Case Status stores law-firm data around Clients, Cases, Messages, Documents, Appointments, and Billing items — a flat object model optimized for client-facing portals. Odoo CRM uses crm.lead for both leads and opportunities, res.partner for all contacts and organizations, crm.stage for Kanban pipeline stages, and ir.attachment for files. The migration requires flattening Case Status's case hierarchy into Odoo's crm.lead with a custom case_type field to distinguish matters, routing case statuses to Odoo stage names via value mapping, and preserving attorney assignments as opportunity owner fields. Activities migrate as Odoo CRM activities with original timestamps. Workflows, client portal settings, and billing automation do not transfer — those are rebuilt using Odoo's built-in automation rules and the Documents app after migration. FlitStack AI sequences the migration so partner records exist before case records (foreign-key dependency), runs a sample migration with field-level diff, and captures a 24–48-hour delta window for in-flight changes during cutover.
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 Case Status 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.
Case Status
Client
Odoo CRM
res.partner
1:1Case Status clients map directly to Odoo res.partner records. The client name splits into First Name and Last Name on res.partner; organization clients store as company_name on res.partner with is_company=True. Email, phone, and address fields map field-for-field. The original Case Status client ID is stored as an external ID field on res.partner for traceability.
Case Status
Case
Odoo CRM
crm.lead
1:1Case Status cases become Odoo crm.lead records. A custom selection field case_type__c distinguishes matters (e.g. Litigation, Corporate, Family Law) so each case type can route to a separate Odoo pipeline or sales team. The crm.lead functions as both lead and opportunity — cases that represent active matters land as Open opportunities; closed or archived cases migrate as Lost or Won leads for historical reference.
Case Status
Case Status
Odoo CRM
crm.stage
1:1Case Status status values (Intake, Active, Pending Review, Awaiting Response, Closed) map to Odoo crm.stage names. The mapping is value-by-value: each Case Status status string is assigned a target stage_id. If your firm uses multiple case types with different status sets, each status group maps to its own stage sequence within its pipeline. Stage-entered timestamps from Case Status are stored as custom datetime fields on crm.lead.
Case Status
Message
Odoo CRM
mail.activity
1:1Case Status messages (both inbound client messages and outbound attorney replies) migrate as Odoo mail.activity records linked to the corresponding crm.lead. The activity's note field contains the full message body. Activity type is set to 'communication' for portal messages and 'call' or 'email' for logged phone/email entries. Original message timestamps and sender/recipient details are preserved as fields on the activity record.
Case Status
Document
Odoo CRM
ir.attachment
1:1Case Status documents attached to cases migrate to Odoo ir.attachment records linked to the crm.lead via res_model='crm.lead' and res_id set to the target lead ID. Files are re-uploaded to Odoo's filestore. Document names and original upload dates are preserved. If a document was shared with the client in Case Status's portal, a note is appended to the attachment record indicating client-facing sharing status.
Case Status
Appointment
Odoo CRM
calendar.event
1:1Case Status appointments migrate as Odoo calendar.event records. Start and end datetimes transfer directly. Attendees are resolved by matching the client email to res.partner records already migrated. The event is linked to the related crm.lead via the event's opportunity_id field if Odoo Calendar CRM integration is active.
Case Status
Attorney / Team Member
Odoo CRM
res.users
1:1Case Status attorney and staff assignments on cases map to Odoo res.users as the crm.lead owner (user_id field). Users are matched by email address. Unmatched Case Status assignees are flagged pre-migration — your Odoo admin either creates the user record first or assigns those cases to a fallback attorney. This prevents crm.lead records from landing without an owner.
Case Status
Billing Item
Odoo CRM
account.move (separate scope)
1:1Case Status billing items (invoices, payments, trust ledger entries) are out of scope for CRM migration. These belong in Odoo's Accounting app (account.move, account.payment) and require a separate accounting-focused migration scope. FlitStack AI can migrate billing data as a follow-on engagement with an accounting-specific validation step.
Case Status
Client Portal Settings
Odoo CRM
portal.access (rebuilt)
1:1Case Status's branded client portal configuration — logo, welcome message, color scheme, and client-facing document sharing rules — has no equivalent in Odoo CRM. After migration, the Odoo Portal app is activated and client portal access is provisioned per res.partner. This is a configuration step, not a data migration.
Case Status
Custom Field (Case)
Odoo CRM
x_studio_* or ir.model.fields
1:1Case Status custom fields on cases (e.g. practice area codes, opposing counsel, court jurisdiction) migrate to Odoo as custom fields on crm.lead. Field types are matched: text to char, pick-lists to selection, numbers to float or integer. The field name in Odoo uses the custom field naming convention (x_studio_ prefix in Community edition). Notes 15–30 words each describing the actual translation, not 'we handle it'.
| Case Status | Odoo CRM | Compatibility | |
|---|---|---|---|
| Client | res.partner1:1 | Fully supported | |
| Case | crm.lead1:1 | Fully supported | |
| Case Status | crm.stage1:1 | Fully supported | |
| Message | mail.activity1:1 | Fully supported | |
| Document | ir.attachment1:1 | Fully supported | |
| Appointment | calendar.event1:1 | Fully supported | |
| Attorney / Team Member | res.users1:1 | Fully supported | |
| Billing Item | account.move (separate scope)1:1 | Fully supported | |
| Client Portal Settings | portal.access (rebuilt)1:1 | Fully supported | |
| Custom Field (Case) | x_studio_* or ir.model.fields1: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.
Case Status gotchas
No publicly documented public API for self-service exports
Portal data is partially decoupled from source case management
Add-on pricing model obscures true cost for migration assistance
Custom properties are stored as JSON key-value pairs with limited schema visibility
Client app notifications and push token state does not transfer
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
Audit Case Status data and deliver schema setup plan
FlitStack AI connects to the Case Status API and exports all records (clients, cases, messages, documents, appointments) as JSON. We profile field types, identify custom fields, count attachment sizes, and map Case Status status values to target Odoo crm.stage records. We deliver a schema setup plan listing every custom field to create on crm.lead, every stage name to create per sales team, and the value-mapping table linking Case Status statuses to Odoo stage IDs.
Create Odoo custom fields, stages, and user mappings
Your Odoo admin (or our team using Odoo Studio or direct ir.model.fields API calls) creates all required custom fields on crm.lead: case_type__c, case_number__c, opened_date__c, and any firm-specific attributes from Case Status. All target crm.stage records are created and sequenced. Attorney and staff emails from Case Status are mapped to res.users records — unmatched users are flagged so they can be provisioned before migration.
Migrate res.partner records first, then crm.lead, then activities
Odoo foreign-key dependencies require a specific load order. We migrate all Case Status clients to res.partner first, preserving the original Case Status client ID as cs_external_id__c for lookup. Then crm.lead records load — each case links to its client via partner_id resolved from the cs_external_id__c map, and attorney assignments resolve via user_id by email. Messages and appointments follow as mail.activity and calendar.event records linked to the crm.lead. Documents load last as ir.attachment records.
Run sample migration with field-level diff
A representative slice of records — typically 100–500 covering the full range of case types, statuses, and attorney assignments — migrates first. FlitStack AI generates a field-level diff comparing source values against destination field values, including stage-name mapping validation, owner resolution results, and attachment count. You review the diff and approve the mapping plan before the full run commits. This catches case_type routing errors and unmatched attorney assignments before they affect the entire dataset.
Full migration with delta-pickup and rollback readiness
The full migration runs against the Odoo instance. A delta-pickup window (24–48 hours) captures any cases, messages, or documents created or modified in Case Status during the cutover. Every operation is logged to an audit trail. One-click rollback reverts all migrated records to the pre-migration state if reconciliation finds discrepancies. Post-migration, we deliver a data reconciliation report comparing record counts and field coverage between the Case Status snapshot and Odoo destination.
Platform deep dives
Case Status
Source
Strengths
Weaknesses
Odoo CRM
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. All 8 core objects map 1:1 between Case Status and Odoo CRM.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Case Status and Odoo CRM.
Object compatibility
All 8 core objects map 1:1 between Case Status and Odoo CRM.
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
Case Status: Not publicly documented.
Data volume sensitivity
Case Status 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 Case Status to Odoo CRM migration scoping. Not seeing yours? Book a call.
Walk through your Case Status 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 Case Status
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.
