Migrate from D-Tools to Odoo CRM

D-Tools clients map to Odoo res.partner records in company mode. Client name, address, phone, and website export from D-Tools and land as fields on the Odoo partner record. D-Tools does not have a separate company/contact split — we create a primary res.partner in company mode and attach contacts as child partner records.

D-Tools contacts export with name, email, phone, and title. Each contact maps to a res.partner in individual mode linked to the parent client partner. D-Tools primaryContact flag determines the commercial partner_id on opportunities. Email addresses are used to resolve Odoo user/owner assignments during migration.

D-Tools projects are the richest data container — project name, value, status, phases, change orders, and job-costing data. Odoo has no project-management object in CRM alone. We map each D-Tools project to a crm.lead in the Convert to Opportunity state and create Odoo custom fields (x_dtools_project_id, x_project_value, x_project_status, x_project_start_date, x_project_end_date) to preserve the project context. Odoo Project app handles true project management separately.

D-Tools locations model work-site addresses that differ from client billing addresses. We map D-Tools location names and addresses to the street fields on the res.partner record. When multiple locations exist per project, we concatenate them into a custom Char field (x_project_locations) on the crm.lead to preserve the full site context without splitting into separate partner records.

D-Tools i3 product library stores manufacturer SKUs, dealer pricing, specifications, and product images per project line item. Odoo CRM has no native product library. We preserve D-Tools product data as custom Char/Number fields on crm.lead (x_product_sku, x_dealer_price, x_product_description) so opportunity line context survives the migration even without native library linkage.

D-Tools service plans track recurring billing with plan name, feature list, dynamic/fixed pricing, and billing frequency. Odoo CRM has no service-plan object. We map plan name to x_service_plan_name (Char), monthly cost to x_service_plan_cost (Float), and billing frequency to x_billing_frequency (Selection). Recurring revenue tracking requires Odoo Subscriptions app post-migration.

D-Tools workflow rules fire notifications and field updates based on project status changes and user assignments. Odoo Studio automations handle the equivalent logic but require manual rebuild using Odoo's automation designer. FlitStack AI exports the full D-Tools workflow rule definitions as a JSON reference document so your Odoo admin can recreate each rule accurately.

D-Tools project tasks and checklists are project-management constructs. Odoo CRM supports activities (mail.activity) on leads but not full task management. We export D-Tools task names, statuses, and assignments as a structured custom note field (x_task_list) on the crm.lead. True task management requires Odoo Project app post-migration.

D-Tools change orders track approved scope and price changes on a project. Odoo CRM has no native change-order construct. We preserve change order data as a custom JSON/Char field (x_change_orders) on the opportunity so historical pricing adjustments are not lost during the migration.

D-Tools file attachments on projects (drawings, photos, spec sheets) export from the D-Tools filestore. We re-upload each file as an ir.attachment linked to the corresponding crm.lead in Odoo. D-Tools file size limits apply at export time; Odoo's attachment storage limits are set by your hosting configuration (Odoo.sh or self-hosted).

D-Tools owner assignment on projects maps to the salesrep on the Odoo crm.lead. We resolve owners by matching D-Tools owner email addresses against Odoo res.users records. Unmatched owners are flagged in the migration report — your Odoo admin creates the user accounts before the full run so no opportunity lands without an assigned salesrep.

The original D-Tools API record identifier is stored as x_dtools_id on every target Odoo record. This field serves three purposes: enables delta-run de-duplication (records modified in D-Tools after the initial export are matched by x_dtools_id), provides traceability for audit purposes, and allows your team to cross-reference source records during the post-migration reconciliation window.