Migrate from Vortex Field Software to Salesforce Sales Cloud

Vortex customers map directly to Salesforce Accounts. Vortex stores the primary business name and billing address on the customer record — these migrate to Account.Name and Account.BillingAddress fields. For multi-site customers, each Vortex site becomes a separate Account with the parent account linked via Account.ParentId.

Vortex sites represent physical locations associated with customers. Each site address migrates as a separate Salesforce Account linked to the parent customer Account. Service addresses are stored in Account.ShippingAddress. The site identifier is preserved in a custom Legacy_Site_ID__c field for traceability.

Vortex contacts (site managers, dispatchers, billing contacts) map to Salesforce Contacts. Each Contact requires an AccountId lookup — the contact's primary site determines the parent AccountId. Multiple contacts per site are supported; Salesforce Contact object handles N:1 site relationships natively.

Vortex assets (equipment, devices, systems) map to Salesforce Asset records linked to AccountId. The asset serial number maps to Asset.SerialNumber, product model to Asset.Product2Id lookup, install date to Asset.InstallDate, and status to Asset.Status pick-list (Active, Shipped, Retired, etc.). Original create timestamps preserved as custom datetime field.

Vortex work orders are the primary service record — these map to Salesforce Cases with custom fields for service-type classification. Case.Status maps from work order status, Case.Priority maps from urgency level, Case.Description maps from work order notes, and Case.AccountId links to the customer Account. Work order number preserved in Legacy_WO_ID__c.

Vortex work order line items (parts used, labor hours, expenses) split into two Salesforce records: CaseComments for internal notes and a custom Service_Line_Item__c object linked to Case for structured billing data. Each line item type (Part, Labor, Expense) mapped to Service_Line_Item__c.Type__c pick-list.

Vortex service contracts with SLA terms map to Salesforce Contract records linked to Account. Contract.StartDate maps to Contract.ContractTerm start, Contract.EndDate to Contract.ContractTerm end, SLA tier to a custom SLA_Tier__c pick-list, and contract value to Contract.TotalContractAmount. Contract.Status defaults to Draft — activation handled post-migration.

Vortex technicians are internal users — they map to Salesforce Users by email match. Unmatched technicians are flagged before migration. User Role, Profile, and territory assignment requires post-migration Salesforce admin configuration. Vortex skill certifications migrate as custom skill fields on User (Technician_Skills__c).

Vortex service history entries (maintenance visits, repairs, inspections) map to Salesforce Tasks with Type='Field Service', Subject containing the service type, and Description with work details. Original service date preserved as Task.ActivityDate. Technician assignment maps to Task.OwnerId via email resolution.

Vortex custom asset properties (extended warranty tier, maintenance schedule, equipment model variant) require Salesforce custom fields on the Asset object. Each custom property becomes an Asset__c custom field with appropriate data type (Text, Picklist, Date, Number). Field names derived from Vortex property API names with __c suffix appended. For multi-select pick-list values, we recommend Text fields with semicolon-delimited values to avoid Salesforce pick-list limitations.

Vortex invoices do not map to standard Salesforce objects. For service organizations tracking billing through Salesforce, invoices migrate as a custom Invoice__c object linked to Account and Case. Alternatively, billable work orders map to Opportunity Products with custom pricing for time-and-materials billing.

Vortex payment collection records have no Salesforce equivalent. Payment history migrates as a custom Payment__c object linked to Account and Invoice__c for audit trail purposes. Salesforce Payments integration (if enabled) manages future payment processing post-migration. Historical payment data retains its original transaction dates, amounts, and payment methods to maintain complete financial records continuity.