CRM migration
Field-level mapping, validation, and rollback between Lawmatics and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.
Lawmatics
Source
Odoo CRM
Destination
Compatibility
14 of 14
objects map 1:1 between Lawmatics and Odoo CRM.
Complexity
BStandard
Timeline
3–5 days
Overview
Lawmatics structures legal intake around three core objects — Matters, Contacts, and Companies — with a pipeline model that tracks intake status per matter and a separate automation engine for workflow sequences. Odoo CRM unifies leads and opportunities into a single crm.lead model and uses res.partner for both contacts and companies (distinguished by the company_type field). The migration carries every Lawmatics data object — Matters to crm.lead, Contacts to res.partner, Companies to res.partner with company_type set to 'company', plus activities, notes, files, and custom fields — via Lawmatics' REST API using read-access credentials scoped to the migration session. We surface the full list of active Lawmatics automations and custom fields during the pre-migration audit so your Odoo administrator can rebuild workflows in Odoo's Automated Actions and recreate custom fields via Studio before the data lands. Owner resolution uses email matching against Odoo res.users so every migrated record lands under a real user. A delta-pickup window captures in-flight changes during cutover so your Odoo instance reflects Lawmatics' final state at go-live.
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 Lawmatics 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.
Lawmatics
Matter
Odoo CRM
crm.lead
1:1Lawmatics Matters are the primary legal-intake record and map to Odoo crm.lead. The Matter's intake_status maps to stage_id via a value-mapping table built during the pre-migration audit. Law-firm-specific fields (practice_area, court_jurisdiction) migrate as custom fields on crm.lead. The original Lawmatics matter ID is stored in x_lawmatics_id for traceability.
Lawmatics
Contact
Odoo CRM
res.partner
1:1Lawmatics Contacts map to Odoo res.partner with partner_type = 'contact'. When a Lawmatics contact has an associated primary company, the migration sets parent_id to the migrated company partner. Email and phone are stored as email and phone on res.partner. All custom contact fields (e.g., bar_number, client_type) become custom fields on the partner record.
Lawmatics
Company
Odoo CRM
res.partner
1:1Lawmatics Companies map to Odoo res.partner with company_type = 'company'. The parent-child hierarchy in Lawmatics (parent_company_id) maps to the parent_id field on res.partner. Lawmatics company domains and industry values are mapped to the website and industry_id fields in Odoo. Annual revenue and employee count from Lawmatics become custom fields if they do not have a native Odoo equivalent.
Lawmatics
Automation
Odoo CRM
No equivalent (export-for-rebuild)
1:1Lawmatics automations are stored as separate workflow objects with triggers, entry conditions, and multi-step action chains. Odoo CRM has a separate Automated Actions module with different schema and trigger semantics. FlitStack exports all automation definitions as a JSON reference document so the Odoo administrator can rebuild each automation in Odoo's Automated Actions UI or via server actions.
Lawmatics
Task
Odoo CRM
crm.activity
1:1Lawmatics tasks (calls logged, emails, follow-ups) map to Odoo crm.activity records linked to the crm.lead via res_id. The activity_type (call, email, meeting) maps to the activity_type_id field. Original owner, create date, and completion status are preserved as fields on the activity record.
Lawmatics
Note
Odoo CRM
mail.message (as note)
1:1Lawmatics notes migrate as Odoo mail.message records with message_type = 'note' linked to the crm.lead or res.partner. Note body text maps to the body field. Rich-text formatting from Lawmatics is preserved in HTML where the source note uses it. Multiple notes on a single matter may create multiple Odoo message records.
Lawmatics
File / Attachment
Odoo CRM
ir.attachment
1:1Lawmatics file attachments linked to matters or contacts migrate as Odoo ir.attachment records. Files are downloaded from Lawmatics storage and uploaded to Odoo's filestore with the original filename preserved. Each attachment is linked to the target record (crm.lead or res.partner) via the res_model and res_id fields. File size limits from Odoo's configuration apply.
Lawmatics
Custom Field (Matter type)
Odoo CRM
ir.model.fields (custom field on crm.lead)
1:1Every Lawmatics custom field defined on Matters becomes a custom field on Odoo's crm.lead model. The migration plan documents each field name, type (char, date, selection, etc.), and current values so the Odoo admin can create the corresponding field via Studio before the migration run. Values are loaded in the same sequence as standard field data.
Lawmatics
Custom Field (Contact type)
Odoo CRM
ir.model.fields (custom field on res.partner)
1:1Lawmatics contact-level custom fields (e.g., bar_license_number, referral_source) map to custom fields on Odoo res.partner. The migration plan lists each field name and type. Odoo Studio or direct XML field creation is required before the full data load, and the field mapping plan is delivered before the migration run.
Lawmatics
Pipeline Stage (Matter status)
Odoo CRM
crm.stage
1:1Lawmatics intake_status values (e.g., New Inquiry, Under Review, Intake Complete) map to Odoo CRM stage records. Each unique status value in Lawmatics becomes a crm.stage entry in Odoo's pipeline. Probability values are assigned per stage. Stage-entry timestamps from Lawmatics are preserved in a custom datetime field x_stage_entered_date for reporting continuity.
Lawmatics
User / Owner
Odoo CRM
res.users
1:1Lawmatics user accounts are resolved against Odoo res.users by email address matching. The user's Lawmatics ID and display name are stored in a custom field x_lawmatics_owner_id on the migrated record so audit trails remain traceable. Users without an Odoo match are flagged before migration; a fallback owner (admin) is assigned to prevent orphaned records.
Lawmatics
Event (Appointment)
Odoo CRM
calendar.event
1:1Lawmatics events (appointments with date, time, location, and attendees) map to Odoo calendar.event records. The event is linked to the corresponding crm.lead via res_model and res_id. Attendee information from Lawmatics creates calendar.attendee records linked to the event. Start and end times are preserved from the source.
Lawmatics
Tag
Odoo CRM
crm.tag
1:1Lawmatics tags applied to matters and contacts map to Odoo crm.tag records. Tags are associated with crm.lead via the tag_ids many2many field. Tag names are preserved exactly as they appear in Lawmatics. If a tag name collides with an existing Odoo tag, the existing tag is used to avoid duplicates.
Lawmatics
Payment / Invoice
Odoo CRM
account.move (Odoo Invoicing app)
1:1Lawmatics invoices and payment records are legal-financial records that require the Odoo Accounting app (account.move model) rather than the CRM module. FlitStack can export invoice data as a structured file for import via Odoo's accounting import wizard, but full invoice-to-payment reconciliation requires the accounting app to be installed and configured. This is flagged in the pre-migration scope discussion.
| Lawmatics | Odoo CRM | Compatibility | |
|---|---|---|---|
| Matter | crm.lead1:1 | Fully supported | |
| Contact | res.partner1:1 | Fully supported | |
| Company | res.partner1:1 | Fully supported | |
| Automation | No equivalent (export-for-rebuild)1:1 | Fully supported | |
| Task | crm.activity1:1 | Fully supported | |
| Note | mail.message (as note)1:1 | Fully supported | |
| File / Attachment | ir.attachment1:1 | Fully supported | |
| Custom Field (Matter type) | ir.model.fields (custom field on crm.lead)1:1 | Fully supported | |
| Custom Field (Contact type) | ir.model.fields (custom field on res.partner)1:1 | Fully supported | |
| Pipeline Stage (Matter status) | crm.stage1:1 | Fully supported | |
| User / Owner | res.users1:1 | Fully supported | |
| Event (Appointment) | calendar.event1:1 | Fully supported | |
| Tag | crm.tag1:1 | Fully supported | |
| Payment / Invoice | account.move (Odoo Invoicing app)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.
Lawmatics gotchas
Matter vs. Contact export schema isolation
Time and billing add-on gating
Contact tier limits affect migration scoping
Automations are not data objects
API rate limits 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
Audit Lawmatics data via API export
We connect to Lawmatics using scoped read-access credentials and export all record types — Matters, Contacts, Companies, Tasks, Notes, Attachments, and Custom Fields — via the Lawmatics REST API. The audit phase produces record counts, field inventory, active automation definitions (exported as JSON), and an initial data quality report flagging duplicates, missing required fields, and unmapped pick-list values. This audit result drives the scope and pricing proposal.
Build Odoo CRM target schema
We deliver a schema setup plan specifying the crm.lead fields, res.partner fields, and crm.stage records needed for the migration. The plan includes custom field definitions for all Lawmatics law-firm properties (practice_area, statute_of_limitations, etc.), stage-mapping tables for intake_status values, and user-resolution rules for owner matching. The Odoo admin creates the fields and stages before the migration run. We validate the schema via a test import before the full load.
Resolve owners and map user relationships
Lawmatics user accounts are matched against Odoo res.users by email address. Records with matched owners assign user_id correctly in Odoo. Records with no matching email are flagged in a pre-migration exception report with the Lawmatics user name and email so the Odoo admin can create the corresponding user or assign a fallback owner. No record lands in Odoo without a resolved owner, preventing orphaned lead assignments after go-live.
Migrate partners, then leads with field-level diff
The migration runs in dependency order: res.partner records (companies first, then contacts) load first because crm.lead requires partner_id to be set. Matters migrate as crm.lead records with all mapped fields including custom fields, tags, stage assignments, and ownership. Activities (calls, emails, meetings) attach to their parent leads. Files are loaded into ir.attachment and linked to the correct res_model and res_id. A field-level diff compares a 100-record sample against the source before the full run commits, allowing the client to verify mapping correctness.
Delta-pickup and go-live validation
After the full migration, a delta-pickup window (24–48 hours) captures any Lawmatics records created or modified during the cutover period. FlitStack re-runs the migration against this delta set and merges changes into Odoo. An audit log records every operation. Go-live validation compares record counts and a random sample of field values between Lawmatics and Odoo. One-click rollback reverts the Odoo database to its pre-migration state if reconciliation fails.
Platform deep dives
Lawmatics
Source
Strengths
Weaknesses
Odoo CRM
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 3 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 Lawmatics and Odoo CRM.
Object compatibility
3 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
Lawmatics: Not publicly documented.
Data volume sensitivity
Lawmatics 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 Lawmatics to Odoo CRM migration scoping. Not seeing yours? Book a call.
Walk through your Lawmatics 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 Lawmatics
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.