CRM migration
Field-level mapping, validation, and rollback between Case UI and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.
Case UI
Source
Odoo CRM
Destination
Compatibility
10 of 12
objects map 1:1 between Case UI and Odoo CRM.
Complexity
BStandard
Timeline
48–72 hours
Overview
Case UI stores law-firm data as a normalized schema of clients, cases, contacts, documents, and custom fields specific to legal practice management. Odoo CRM uses a different object model: res.partner for clients and companies (as contacts), crm.lead for leads and opportunities (which can represent cases), ir.attachment for documents, and account.analytic.account for billing matters. We extract Case UI data via the platform's export API and REST endpoints, map client records to res.partner with partner_category assignments for matter types, translate case records to crm.lead entries with type='opportunity' for billable matters, preserve document references as ir.attachment links, and carry forward custom fields as ir.model.fields definitions in Odoo Studio. Workflows, document templates, and billing rules do not transfer — we export those definitions as JSON blueprints for manual reconstruction in Odoo's automation engine and accounting modules. The migration runs in three phases: schema discovery, sample migration with field-level diff, then full load with a 24–48 hour delta window for in-flight changes.
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 UI 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 UI
Case UI Client
Odoo CRM
res.partner
1:1Case UI clients map directly to Odoo's res.partner model. Each client becomes a partner record with partner_latitude, partner_longitude, and category_id set from Case UI's client type field. Companies and individual attorneys each become partner records differentiated by the is_company flag.
Case UI
Case UI Case
Odoo CRM
crm.lead
1:1Case UI case records become Odoo crm.lead entries with type='opportunity' since Case UI cases represent billable matters rather than pre-sale leads. The case number maps to Odoo's name field, and case status maps to stage_id via value_mapping against Odoo's stage definitions. Attorney assignment maps to user_id by email resolution.
Case UI
Case UI Contact
Odoo CRM
res.partner
1:1Contacts linked to Case UI clients become res.partner records with parent_id pointing to the client-partner record. This preserves the client-contact hierarchy in Odoo, allowing contact-level communication history while maintaining the client-level billing relationship. Each contact inherits the parent's partner_category assignments, ensuring that matters associated with the contact inherit the correct categorization for reporting and segmentation in Odoo CRM views and filters.
Case UI
Case UI Document
Odoo CRM
ir.attachment
1:1Case UI document records map to Odoo's ir_attachment model. The original filename, MIME type, and file content transfer to Odoo's filestore. Each attachment is linked to its parent case record via res_model='crm.lead' and res_id set to the migrated case's Odoo ID.
Case UI
Case UI User (Attorney)
Odoo CRM
res.users + res.partner
many:1Case UI users are split across two Odoo objects: res_users for login credentials and res_partner for the user record that holds name, email, and phone. Attorney billable rates stored in Case UI map to account_analytic_account records linked to the Odoo user for time-tracking purposes.
Case UI
Case UI Custom Field (Matter-Specific)
Odoo CRM
ir.model.fields (Studio-created)
1:1Case UI custom fields — such as opposing counsel, case venue, court jurisdiction, or insurance carrier — require pre-creation in Odoo Studio before migration data can populate them. We deliver a field-creation script that mirrors each Case UI custom field definition as an Odoo ir.model.fields entry with the correct ttype, relation, and required flags.
Case UI
Case UI Time Entry
Odoo CRM
account.analytic.line
1:1Billable hours logged in Case UI migrate to Odoo's account_analytic_line model, linked to the analytic account of the case (crm.lead). The Case UI attorney's hourly rate maps to the Odoo unit_amount field, and the entry description maps to name. Billing approval status is preserved in a custom stage field.
Case UI
Case UI Expense Entry
Odoo CRM
account.move.line (vendor bill)
1:1Case UI expenses charged to a matter become Odoo account_move_line entries attached to a vendor bill (account_move with move_type='in_invoice'). The expense description and amount transfer directly; Odoo's expense module can generate these entries or they can be imported as journal items linked to the case's analytic account.
Case UI
Case UI Calendar Event
Odoo CRM
calendar.event
1:1Scheduled hearings, depositions, and attorney meetings in Case UI map to Odoo's calendar_event model. Start and stop timestamps, attendees linked to res.partner and res.users, and location details transfer directly. Reminder settings are preserved as Odoo alarm records with corresponding alarm_type and duration values. Recurring event patterns in Case UI become recurring calendar.events in Odoo using the base.action.domain expression syntax for recurrence rules.
Case UI
Case UI Task / To-Do
Odoo CRM
project.task
1:1Case UI task items map to Odoo project_task records. We create a project record per case (or per practice area) and link tasks to it via project_id. Tasks not already tied to a project are routed to a default 'Case UI Migration' project. Custom task statuses require stage configuration in Odoo's project module settings.
Case UI
Case UI Billing Profile
Odoo CRM
res.partner (billing fields)
many:1Client billing profiles in Case UI — payment terms, billing contact, invoice delivery method — merge into the res.partner record's address fields and property_payment_term_id. Odoo's sale_order and account_move models reference these partner fields when generating invoices, so the billing profile data maps to fields the accounting module already reads.
Case UI
Case UI Opposing Party
Odoo CRM
res.partner (separate partner record)
1:1Opposing parties and opposing counsel listed in Case UI become separate res.partner records with a custom partner_category set to 'Opposing Party' or 'Opposing Counsel'. This keeps opposing parties out of the firm's primary client contact list while preserving them in Odoo's partner database for case-related correspondence.
| Case UI | Odoo CRM | Compatibility | |
|---|---|---|---|
| Case UI Client | res.partner1:1 | Fully supported | |
| Case UI Case | crm.lead1:1 | Fully supported | |
| Case UI Contact | res.partner1:1 | Fully supported | |
| Case UI Document | ir.attachment1:1 | Fully supported | |
| Case UI User (Attorney) | res.users + res.partnermany:1 | Fully supported | |
| Case UI Custom Field (Matter-Specific) | ir.model.fields (Studio-created)1:1 | Fully supported | |
| Case UI Time Entry | account.analytic.line1:1 | Fully supported | |
| Case UI Expense Entry | account.move.line (vendor bill)1:1 | Fully supported | |
| Case UI Calendar Event | calendar.event1:1 | Fully supported | |
| Case UI Task / To-Do | project.task1:1 | Fully supported | |
| Case UI Billing Profile | res.partner (billing fields)many:1 | Fully supported | |
| Case UI Opposing Party | res.partner (separate partner record)1: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 UI gotchas
No public API documentation found
On-Premise perpetual license has upgrade isolation risk
No verified public reviews or G2/Capterra feedback
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
Extract Case UI data via export API and generate Odoo field-creation script
We connect to Case UI's export endpoints using scoped read access to pull all clients, cases, contacts, documents, users, time entries, and custom field definitions. The extraction runs against a test copy of the database to avoid any production impact. From the export we generate an Odoo field-creation script that defines every Case UI custom field as an ir.model.fields entry — including field type (char, text, selection, many2one), required flags, and default values. This script runs against your Odoo instance before migration data arrives, ensuring the ORM can validate incoming records. We deliver the script as a Python file you run via Odoo's shell or as a Studio-exported data file you import through the Settings > Technical > Models interface.
Resolve Case UI attorneys and users to Odoo res.users by email match
Case UI user records — attorneys, paralegals, admins — are matched against existing Odoo user accounts by email address. Any Case UI user without a corresponding Odoo account is flagged in the migration plan with two options: create a placeholder Odoo user before migration (recommended so owner assignments resolve correctly) or assign their records to a migration fallback user. We also capture each user's role and hourly rate from Case UI to populate Odoo's groups_id and account_analytic_account records for billing. If Case UI users have no email (rare but documented in on-premise deployments), we match by full name and validate uniqueness before assigning.
Migrate res.partner records first, then crm.lead cases, then attachments and time entries in dependency order
Odoo's foreign-key constraints require partners to exist before cases can reference them (partner_id on crm.lead) and cases to exist before attachments can link to them (res_id on ir.attachment). We sequence the migration in four passes: Pass 1 creates all res.partner records from Case UI clients and contacts with parent_id assignments; Pass 2 creates crm.lead records from Case UI cases with user_id and partner_id resolved from the previous pass; Pass 3 uploads ir.attachment records linked to the crm.lead IDs from Pass 2; Pass 4 imports account_analytic_account and account_analytic_line records for billing history. Each pass generates a validation report showing record counts, skipped rows, and error reasons so you can inspect before the next pass runs.
Run a sample migration on a 200–500 record slice and generate field-level diff
We select a representative slice of Case UI records spanning the main object types — a mix of open and closed cases, clients with multiple contacts, documents of varying types, and time entries from multiple attorneys. This sample runs against your live Odoo database (in a test environment) and produces a field-level diff showing what each Case UI field value became in Odoo. You can verify that case status values map to the correct Odoo stage, that attorney assignments resolve to the right Odoo user, and that document attachments appear under the right case record. The diff report is the go/no-go checkpoint — if anything looks incorrect in the sample, we adjust the mapping configuration before the full migration runs.
Execute full migration with delta-pickup window and one-click rollback availability
The full migration runs against your production Odoo instance. We use Odoo's XML-RPC or JSON-RPC API with batch sizes of 500 records per call to avoid timeouts. After the initial load completes, a delta-pickup window of 24–48 hours captures any Case UI records modified or created during the cutover period — typically new time entries or case updates from attorneys still working in Case UI while the Odoo setup is finalized. All operations are logged to an audit table we create in your Odoo database. If reconciliation fails (record counts don't match, validation errors exceed threshold), one-click rollback reverts all migration-created records using the audit log. The rollback does not touch pre-existing Odoo data.
Platform deep dives
Case UI
Source
Strengths
Weaknesses
Odoo CRM
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 2 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 Case UI and Odoo CRM.
Object compatibility
2 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
Case UI: Not publicly documented.
Data volume sensitivity
Case UI 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 UI to Odoo CRM migration scoping. Not seeing yours? Book a call.
Walk through your Case UI 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 UI
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.