Migrate from The Service Program to Freshsales

No public API forces migration against CSV exports or direct database reads

The Service Program has no documented public REST API. Migration runs against CSV data exports generated from within the application or a direct database read for customers on the Desktop edition. CSV exports do not include timestamps in a machine-readable format by default — the date columns must be parsed and validated for format consistency (MM/DD/YYYY vs DD/MM/YYYY) before field mapping can begin. If your export uses a merged customer-and-work-order format rather than separate tables, a pre-migration data-splitting step is required before FlitStack AI can map fields correctly. This step adds scope that does not apply to CRMs with standard API access.

Work-order lifecycle statuses require value-by-value stage mapping

The Service Program stores job lifecycle as a pick-list: Dispatched, In Progress, On Hold, Completed, Invoiced. Freshsales has no native job-lifecycle concept on Deals — stage is the primary progress indicator. Mapping requires a value-by-value decision for each TSP status: Does Dispatched map to Prospecting or Qualification? Does Invoiced close the deal as Closed Won or remain open pending payment confirmation? FlitStack AI delivers a stage-mapping plan before migration runs so your team approves the mapping logic. Pipeline-specific stage sets in Freshsales require this mapping to be repeated per pipeline if you run multiple sales processes.

Technician-to-user email resolution can leave orphaned assignments

The Service Program assigns work orders by technician name, not by email. Freshsales records require an OwnerId that points to an actual user record. If your technician roster uses a naming convention (e.g., first initials or abbreviations) rather than email addresses that match Freshsales user emails, FlitStack AI cannot auto-resolve the assignment. A technician-to-user lookup table must be built before migration — either by your admin providing the mapping or FlitStack AI inferring it from the user list. Unresolved technicians result in work orders assigned to a fallback owner and flagged for manual correction post-migration.

Service-address context lives outside Freshsales' standard account model

Field-service companies often service a location that differs from the customer's billing address. The Service Program stores a separate Service Address on work orders. Freshsales Accounts and Contacts hold one billing address and one shipping address — neither of which maps cleanly to a service-location field. FlitStack AI migrates the service address as a custom Work_Order__c.Site_Address__c field, but this field is not native to Freshsales' standard UI layouts and must be added to the Work_Order__c page layout manually by your admin after migration.

Workflows, routing rules, and QuickBooks sync do not transfer

The Service Program's dispatch routing rules, scheduling constraints, and QuickBooks sync triggers are application configuration, not data. They have no Freshsales equivalent and cannot be migrated as records. FlitStack AI delivers a configuration audit export — a structured list of every routing rule and workflow in The Service Program — so your Freshsales admin has a rebuild reference. Route-optimization logic is not rebuildable in Freshsales' standard automation tools and may require a third-party routing add-on or a custom integration.