Migrate from ServiceMax to Odoo CRM

ServiceMax Work Orders carry a status, priority, scheduled date, assigned technician, and line items for parts consumed. We decompose the header into an Odoo crm.lead record and the parts-consumption lines into stock.move or sale.order.line records depending on whether the destination uses Odoo inventory. Original Work Order number preserved in a custom Char field for traceability.

ServiceMax Cases represent reported equipment issues logged by customers or technicians. Each case maps directly to an Odoo crm.lead with type 'lead' and the case subject as the lead name. Priority and reported-on date migrate as custom fields; resolved status maps to Odoo's won/lost stage states.

ServiceMax Installed Base stores per-serial product configuration, installation location, parent asset hierarchy, warranty end date, and entitlement status. We map each Installed Base record to an Odoo product.product variant with custom fields capturing serial number, installation date, parent asset reference, and warranty expiry. Entitlement status becomes a custom selection field or links to an Odoo subscription record.

ServiceMax Service Contracts define entitlement scope, covered products, billing frequency, and SLA terms. Odoo's subscription module handles recurring billing and contract-line coverage. Contract lines mapping to covered assets use Odoo's subscription.template line model. Contract status (Active, Expired, Cancelled) maps to Odoo subscription state with value mapping.

Standard Salesforce Product2 objects map directly to Odoo product.template with variants created per serial-number grouping for Installed Base entries. Serviceable flag and product type (Part vs. Service vs. Asset) migrate as custom selection fields. Product descriptions, list prices, and cost prices transfer to corresponding Odoo fields, while product categories map to Odoo product.category records for inventory grouping.

ServiceMax Accounts are Salesforce Contacts' parent organizations. Odoo collapses this into res.partner where the same record can act as both company (is_company=True) and individual contact. We map the primary Account to a company-type partner and all related Contacts to child partner records under the same parent_id.

ServiceMax Contacts and Odoo res.partner use the same relational model — individual person records linked to an organization. We migrate each Contact as a res.partner with is_company=False. Email, phone, mobile, job title, and address fields map directly. Multiple Contact roles per Account collapse to Odoo's partner function tags.

ServiceMax technicians and dispatch resources are Salesforce users with scheduling permissions. We match them to Odoo res.users by email. Unmatched technicians are flagged for team assignment before migration. Skill certifications, working hours, and territory assignments migrate as custom fields on the user record or as Odoo resource.calendar entries.

ServiceMax parts consumption and request records map to Odoo stock.picking (internal transfers or deliveries) and stock.move lines. Quantities, product variants, source/destination locations, and transaction dates carry over. Parts request status (Pending, Fulfilled, Back-ordered) maps to Odoo stock move state. Lot/serial numbers on parts transfer to Odoo stock.lot records linked to the relevant product variants.

ServiceMax Technical Attributes store dynamic property definitions on assets — temperature ranges, voltage specs, serial configuration. Odoo has no native equivalent. We create Odoo product.attribute lines per technical attribute group and store attribute values on the product.variant as attribute values. Complex multi-value attributes get custom fields on product.product.

ServiceMax SFM Transactions define custom data-entry screens, Smart Docs for field reports, and Checklist templates. Odoo has no equivalent object. We export SFM Transaction definitions as JSON from the ServiceMax Migration Tool and deliver them as documentation for Odoo custom module development. Workflow and data-entry logic must be rebuilt.

ServiceMax Counter Rules trigger preventive maintenance based on meter readings (hours used, cycles completed). Odoo maintenance module supports preventive maintenance schedules but lacks a counter-trigger model. We map active counter thresholds as maintenance frequency rules on the linked product.asset record and flag counter-rule logic for Odoo custom module implementation.