Migrate from FastTrack to Freshsales

FastTrack lifecycle property maps to Freshsales lifecycle_stage but requires value-by-value validation

FastTrack stores lifecycle data as a custom property with arbitrary string values. Freshsales lifecycle_stage is a native pick-list field with specific allowed values (Subscriber, Lead, MQL, SQL, Opportunity, Customer). When FastTrack lifecycle values do not match Freshsales's enum exactly, the migration flags them as unmapped and your admin must decide whether to collapse values into the closest Freshsales stage or create a custom field that preserves the original FastTrack value. This validation step adds planning time before the migration runs and must not be skipped.

Lead-to-Contact conversion in Freshsales requires pre-migration schema decisions on the Lead object

FastTrack does not have a separate Lead object—every person record is a Contact. Freshsales distinguishes between Leads and Contacts with a formal Lead Conversion process that creates Account, Contact, and Deal records simultaneously. If you want your FastTrack Contacts to become Freshsales Leads initially (preserving the ability to run them through Freshsales's lead scoring), we need to know before migration so the record type mapping can be set correctly. If you prefer Contacts only, we map FastTrack Contacts directly to Freshsales Contacts without the Lead step. This decision affects downstream Freshsales automation triggers.

FastTrack custom objects require Freshsales custom fields or Custom Objects (Enterprise plan required)

FastTrack custom objects with their own schema do not map 1:1 to any Freshsales native object on Growth or Pro plans. On those plans, FastTrack custom object fields must be redistributed as Freshsales Custom Fields on the appropriate native object (Contact, Account, or Deal). The Enterprise plan includes Custom Objects with full relationship support, which handles many-to-many associations more cleanly. We audit your FastTrack custom object schema before migration and recommend the correct Freshsales target for each custom property based on which entity it semantically belongs to.

FastTrack automation rules and workflows do not migrate and must be rebuilt in Freshsales

FastTrack automation rules—conditional logic that updates fields, assigns owners, or triggers notifications—have no Freshsales equivalent that can import them. Freshsales Workflows use a different trigger-action model with different field names and operators. We export a JSON representation of your FastTrack automation rules as a rebuild reference for your Freshsales admin, but the logic must be reconstructed manually. Freshsales's Automation section supports time-based triggers, territory rules, auto-assignment, and Freddy AI actions that can replicate most FastTrack workflows.

Freshsales API rate limits require batched loading with exponential backoff

Freshsales REST API enforces rate limits that vary by plan tier (Pro and Enterprise have higher limits than Growth). During migration, we batch FastTrack records into groups of 100–500 and use exponential backoff with retry logic when 429 responses occur. Large migrations with 100,000+ records may require multi-day API windows to avoid hitting throttling. We monitor rate limit headers and adjust pacing dynamically so the migration completes without manual intervention while respecting Freshsales's infrastructure constraints.