Migrate from MyCase to Odoo CRM

MyCase contacts map 1:1 to Odoo res.partner records. The email field is used as the unique matching key for owner resolution. Contacts without an email receive a generated placeholder email and are flagged for manual review before the full migration commits.

MyCase companies map to Odoo res.partner with company_type set to 'company'. The primary address, phone, and website fields migrate directly. Parent-company relationships in MyCase map to res.partner parent_id — the parent company must be created before the child to resolve the foreign key.

MyCase cases become Odoo crm.lead records. The case number (e.g., '2024-CIV-001') is stored in a custom field x_mycase_case_number on crm.lead. Case type (litigation, transactional, estate) maps to a custom selection field x_practice_area on crm.lead. The crm.lead name field is populated with the case title for Odoo pipeline visibility.

The MyCase assigned attorney (user_id) resolves to an Odoo res.users record by email match. If the attorney does not have an Odoo user account, their MyCase ID is stored in x_mycase_former_owner for admin assignment after migration. Unresolved owners are reported before the migration run.

MyCase case status values (Active, Pending, Closed, Archived) map to corresponding Odoo CRM stage IDs. Stage names are mapped value-by-value. If MyCase has custom status labels, Odoo stage names are created to match them — the admin reviews stage colors and probability settings post-migration.

MyCase time entries become mail.message records attached to the parent crm.lead. Each message preserves the original description, hours, rate, and date as message body text. Billable vs non-billable flags are stored in a custom boolean field x_mycase_billable on the message record. This approach preserves activity history without creating Odoo account.analytic.line records.

MyCase invoices are not migrated as Odoo account.move records because Odoo invoicing requires chart-of-accounts and fiscal position configuration that is destination-side setup. Instead, MyCase invoice IDs, amounts, and statuses are stored in custom fields on the associated crm.lead as a billing reference record for your accountant to reconstruct in Odoo Accounting.

MyCase contact custom fields (e.g., bar_number, malpractice_carrier) are created as ir.model.field definitions on res.partner before the migration run. Field types map: text to char/text, picklists to selection, dates to date. The field x_mycase_record_id is created on every object to store the original MyCase ID for traceability.

MyCase file attachments are downloaded and re-uploaded to Odoo ir.attachment records. Each attachment is linked to the target res.partner or crm.lead via res_model and res_id. File size limits follow Odoo's default. Inline images in MyCase notes are extracted and stored as binary attachments. Folder hierarchy is flattened — the original MyCase Drive folder path is preserved in the attachment's description field.

MyCase trust account balances and transaction history have no direct Odoo CRM equivalent. The trust account name, type, and last known balance are stored as a custom note on the relevant res.partner for reference. Rebuilding trust accounting requires Odoo Accounting app configuration with dedicated IOLTA journals — handled separately from the CRM migration.

MyCase workflows and task-automation templates do not migrate. Their definitions are exported as a JSON schema document listing each workflow trigger, condition, and action. Your Odoo administrator uses this as a rebuild reference for Odoo Studio server actions and action rules — the logic models are fundamentally different between the two platforms.

MyCase's client-facing portal access and permissions have no direct Odoo CRM equivalent. Portal access in Odoo is controlled by the portal group and requires the website module or a dedicated portal configuration. Client-facing access is not migrated — it must be re-established after Odoo is configured.