Migrate from ServiceMax to Salesforce Sales Cloud

ServiceMax Work Orders map to Salesforce Cases as the primary service record. The SVMXC__Work_Order__c object is a custom Force.com object; Case is Salesforce's standard service object. All SVMXC__ custom fields on the work order become Case custom fields (__c). Owner is resolved by email match to a Salesforce User. If the SVMXC__tech record has no Salesforce user match, the case lands under a designated fallback owner.

ServiceMax work order status values (Open, In Progress, Completed, Cancelled, On Hold) map to Salesforce Case Status pick-list values. Each SVMXC__ status value is mapped value-by-value to a Salesforce Case Status label. If Salesforce lacks a matching status label, a custom Status__c pick-list field is created and the mapping documented for admin review before migration.

ServiceMax priority values (Critical, High, Medium, Low) map to Salesforce Case Priority pick-list values. The pick-list mapping is defined in the migration plan. If the destination org uses different priority labels, a custom Priority__c field is created rather than overwriting the standard pick-list which may be referenced in active Flows or validation rules.

ServiceMax Work Order Line Items have no direct Salesforce Sales Cloud standard equivalent. We create a CaseLineItem__c custom object with fields for product, quantity, cost, and a lookup to the parent Case. If the destination org uses Opportunity Products for billable line items, CaseLineItem__c is supplemented by Opportunity Product records generated from the line item cost data.

ServiceMax Product records map to Salesforce Product2. Product code, description, and unit cost are mapped directly. Family values in ServiceMax map to Product2 Family pick-list; mismatched values are flagged for pick-list alignment. If the Product2 records already exist in the destination org, de-duplication is performed using Product2.ProductCode as the matching key.

ServiceMax Installed Product (SVMXC__Installed_Product__c) maps to Salesforce Asset. AccountId is mapped from SVMXC__Company__c to Asset.AccountId. SerialNumber, InstallDate, Status, and UsageEndDate map directly. The SVMXC__Product__c lookup maps to Asset.Product2Id. Asset.Name is generated from serial number and product name per the destination naming convention.

ServiceMax Product Item tracks parts and inventory against work orders. This splits into two Salesforce destinations: the stocking location maps to a custom Stocking_Location__c field on Asset, and the parts-on-order detail maps to a custom Inventory__c object with a lookup to Asset and fields for part number, quantity on hand, and reorder threshold. The split is documented in the migration plan so the admin can configure the Inventory__c object before the full run.

ServiceMax Service Report documents are stored as Salesforce Files (ContentVersion) linked to the parent Case via ContentDocumentLink. The original report URL is preserved as a custom Service_Report_URL__c text field on Case for reference. If ServiceMax stores reports in a separate document store, the files are downloaded and re-uploaded to Salesforce Files.

ServiceMax Skill records have no Salesforce standard equivalent. We migrate skill definitions to a Skill__c custom object with Name, Description, and IsActive fields. The skill requirement on a work order maps to a custom Skill_Required__c multi-select pick-list on Case. If the destination uses Salesforce Field Service, skills are migrated using the Field Service Managed Package skill model instead.

ServiceMax Service Contract maps to Salesforce Contract. Contract Number, AccountId (from SVMXC__Company__c), StartDate, EndDate, and Status map directly. Line items on the service contract (coverages, SLAs) map to ContractLineItem if the destination org uses the Contract Line Item object; otherwise they are stored as a custom ContractLineItem__c object.

ServiceMax SFM Transactions (Smart Field Maps defining field-to-field mappings in Service Flows) have no Salesforce Sales Cloud equivalent. We export SFM Transaction definitions as JSON via the ServiceMax Migration Tool for use as a rebuild reference in Salesforce Flow or Apex. The data itself migrates; the FSM logic does not.

ServiceMax counter readings (maintenance cycle counters on installed products) map to a custom CounterReading__c object linked to Asset. Each reading stores the counter name, reading value, reading date, and related work order. Salesforce Field Service Managed Package includes a native counter model; if that package is not in scope, the custom object approach provides the same data without the package dependency.

ServiceMax Mobile Configurations define what fields and actions appear in the ServiceMax Go mobile app. Salesforce Field Service Mobile has its own configuration model; if the destination is Salesforce Sales Cloud without Field Service, the mobile experience requires a separate mobile app strategy. We export the mobile configuration JSON for the admin to reference when scoping a mobile rebuild.

ServiceMax Account records (SVMXC__Company__c) map to Salesforce Account. Name, BillingAddress, Phone, Industry, and NumberOfEmployees map directly. If ServiceMax stores parent-company relationships via SVMXC__Parent_Company__c, that maps to Account.ParentId. Accounts must be migrated before Work Orders so the AccountId lookup on Case resolves correctly during the migration run.

ServiceMax Contact records (SVMXC__Contact__c) map to Salesforce Contact. Name, Email, Phone, Title, and AccountId map directly. AccountId is resolved via the Account migration step. If ServiceMax stores multiple contact roles per work order, these map to CaseContactRole junction records. Owner resolution uses email matching to Salesforce users; contacts without a matched user land under the fallback owner.