Migrate from Thomson Reuters Case Center to Odoo CRM

Export Case Center data via structured spreadsheet and API

FlitStack begins by extracting Case Center data through the available export channels — spreadsheet exports for structured fields (case name, status, dates, party information) and the Thomson Reuters API for file metadata and exhibit records. We validate record counts against your reported volumes and flag any records with missing required fields (cases without parties, exhibits without a parent case) before mapping begins. This discovery step identifies data quality issues — duplicate party entries, orphaned exhibits, missing email addresses for owner resolution — that need cleansing before Odoo import.

Create Odoo custom fields for court-specific metadata

Before any records are written to Odoo, FlitStack creates the custom fields required to hold Case Center data that has no native Odoo equivalent: Case_Reference__c, Party_Role__c, Exhibit_Number__c, Is_Privileged__c, Next_Hearing_Date__c, Judge__c, Courtroom__c, Hearing_Type__c, and Parent_Case_ID__c. Custom fields are created on crm.lead, res.partner, and ir.attachment as appropriate. We configure field types (Char, Selection, Boolean, Datetime) based on the source data types. This step requires Odoo admin credentials with field creation permissions.

Resolve users and owners by email match

Case Center user accounts are matched against Odoo res.users by email address. Unmatched users are flagged before migration — your team either creates Odoo user accounts for them first or assigns their records to a fallback owner. Party records with no email are created as inactive res.partner records with a note indicating they require manual activation. This step ensures every crm.lead created in Odoo has a valid user_id and owner_id, avoiding orphan records that appear in Odoo's 'Unassigned' view.

Migrate parties to res.partner, then cases to crm.lead

FlitStack sequences the migration to respect Odoo's foreign-key dependencies: res.partner records are created first, then crm.lead records reference them via partner_id. Subcases are written after parent cases so the Parent_Case_ID__c field can reference existing records. Each batch is validated before committing — party record counts, case-to-party linkage counts, and exhibit-to-case linkage counts are checked against source totals. Any record that fails validation (missing required field, broken linkage) is written to an exception report for manual review.

Re-upload exhibit files as ir.attachment and link to parent crm.lead

Exhibit files are downloaded from Case Center, verified against original file hashes, and re-uploaded to Odoo's filestore as ir.attachment records. Each attachment is linked to its parent crm.lead via res_model='crm.lead' and res_id set to the migrated case ID. Custom exhibit metadata fields (Exhibit_Number__c, Exhibit_Description__c, Upload_Date__c, Is_Privileged__c, Privilege_Reason__c) are populated from the Case Center export. Privileged exhibits are flagged for post-migration security review. File integrity hashes are stored in a custom field (Original_File_Hash__c) so exhibit authenticity can be independently audited in Odoo.

Run delta-pickup and validate field-level completeness

After the full migration commit, FlitStack captures a delta snapshot of Case Center records modified during the cutover window (typically 24–48 hours). New or updated parties, cases, and exhibits are written to Odoo in a second pass. A field-level diff report compares source and destination values across all mapped fields for a representative sample of records (typically 50–100 cases). You review the diff to confirm party role mapping, exhibit number continuity, and hearing date accuracy before go-live. Audit log is delivered in CSV format; one-click rollback reverts the Odoo database to pre-migration state if reconciliation fails.