Migrate from The Service Program to Zoho CRM

TSP technician records do not map directly to Zoho CRM Users

The Service Program stores technicians as staff records with names, phone numbers, and dispatch zones. Zoho CRM's User object represents licensed application users — field technicians who do not need a Zoho CRM seat should not receive a full User license. FlitStack matches each TSP technician email against Zoho users by email, flags unmatched technicians, and surfaces a recommendation: create a Zoho User for the technician or map their work orders to a fallback technician Contact record. If your team uses TSP's dispatch board to assign work, Zoho FSM (a separate Zoho product) provides the closest functional equivalent — your admin decides the licensing approach before migration.

TSP service categories require a custom Case field in Zoho CRM

The Service Program uses service categories — pool cleaning, pest control, HVAC repair, landscaping — to classify every service request. Zoho CRM's standard Case object has no category dimension; it relies on Case Origin, Status, and Priority. If your team filters or reports by service category in TSP, that dimension disappears unless you create a custom pick-list field (Case_Category__c) on the Zoho Case module before migration. FlitStack creates this field during the pre-migration schema setup phase, but your admin must define the pick-list values to match TSP's service category vocabulary.

TSP customer-to-service-location relationship is 1:N in Zoho Accounts

The Service Program stores one service location per customer record by default, but many service businesses have multiple service sites per customer account (e.g., three branch locations for a restaurant chain). Zoho CRM Accounts support multiple shipping addresses via the Address subform, but TSP does not natively model multi-site customers — your TSP data may contain separate customer records per location that FlitStack collapses into one Account with multiple address subform entries, or preserves as separate Accounts with a parent-child hierarchy. This decision affects reporting and needs admin input before migration.

Zoho CRM does not have a native equipment or asset module in standard plans

TSP tracks equipment (model, serial number, install date, warranty expiration) as a first-class record type linked to customers or service locations. Zoho CRM's standard modules (Accounts, Contacts, Cases, Tasks) contain no equipment object. FlitStack creates a Zoho Custom Module named 'Equipment' with all TSP equipment fields mapped as custom fields, linked to the parent Account via a lookup. Note that Zoho Inventory or Zoho Asset Management (available in higher Zoho One tiers) provides a more robust equipment model — if you hold those licenses, FlitStack can map to those modules instead.

TSP dispatch and routing logic has no equivalent in Zoho CRM workflows

The Service Program's core value is route optimization and technician dispatch — the rules that assign the nearest available technician to a service request based on zone, skill set, and availability. Zoho CRM has no native dispatch or routing engine; Zoho FSM provides a field service module with scheduling and dispatch capabilities, but it is a separate product and its data model differs from TSP. FlitStack migrates the work order data but cannot migrate TSP's dispatch algorithm. Your team will need to define new scheduling rules in Zoho FSM or a third-party scheduling tool. We export TSP's dispatch rules as a process document for your implementation team.