Migrate from WennSoft to Salesforce Sales Cloud

Equipment parent-child hierarchies require a custom object — Asset does not support equipment-to-equipment lookups

WennSoft's Equipment Manager module stores parent-equipment relationships natively, enabling multi-level equipment hierarchies (e.g., HVAC unit → compressor → individual parts). Salesforce's native Asset object is flat — it supports an AccountId lookup and a ContactId lookup, but no parent-asset relationship. Migrating multi-level equipment structures requires creating a custom Equipment__c object with a Parent_Equipment__c self-lookup field. Without this, equipment hierarchies flatten and parent-child maintenance histories break. FlitStack creates this custom object and maps the hierarchy during migration.

Unbilled costs require a custom staging object — Salesforce has no native concept for unposted service-call billing

WennSoft tracks unbilled labor and parts separately from posted invoices, surfacing them in the Unbilled Costs report for each service call with a status other than Complete. Salesforce has no equivalent staging construct for unbilled service costs. FlitStack creates an Invoice__c custom object with status='Unbilled' linked to the Work_Order__c, preserving the unbilled labor, parts, and cost-plus amounts. This allows your billing team to reconcile and post after cutover without re-entering data manually.

Extended pricing matrices do not migrate as data — they require a Salesforce CPQ rebuild guide

WennSoft's Extended Pricing Matrix defines billing rates by call type, problem type, equipment type, and technician rate. This is a rule-based calculation engine, not a simple data table. Salesforce has no native equivalent; the closest construct is Salesforce CPQ with product rules and price actions. FlitStack exports the extended pricing matrix as a structured reference document and delivers a CPQ configuration guide, but the pricing rules themselves must be rebuilt by your Salesforce admin. This is not a limitation of the migration — it is a structural difference between the platforms.

Scheduling and dispatch rules do not migrate — no Salesforce equivalent exists in Sales Cloud

WennSoft's Scheduling module assigns technicians to service calls based on territory, skill match, and availability, with a dispatch board UI. Salesforce Sales Cloud has no native scheduling or dispatch board. Salesforce Field Service (a separate product) or Flow-based custom scheduling must be rebuilt. FlitStack preserves technician-to-call assignments as a custom Assigned_Technician__c field on Work_Order__c, but the assignment logic, territory rules, and availability engine are not transferable. We deliver a scheduling-requirements document to guide the rebuild.

Foreign key resolution requires Accounts to load before service calls — sequencing matters

WennSoft service calls link to customers and locations via IDs. Salesforce requires AccountId on Work_Order__c before the record can be saved. FlitStack sequences the migration as: (1) Customers → Accounts, (2) Locations → custom Location__c, (3) Contacts → Contacts, (4) Equipment → Assets or Equipment__c, (5) Service Calls → Work_Order__c, (6) Time Entries and Job Costs linked to work orders. Attempting to load service calls before accounts creates null-AccountId records that require cleanup. Our migration runner enforces this sequence automatically.