Migrate from Bizstim Business Management Software to Freshsales

Tier confirmation and scoping

We confirm the source Bizstim account holds an active Enterprise licence (required for API key generation) and document the full object inventory: client count, practitioner count, service catalogue size, payment record volume, and any binary attachments or file uploads stored within client records. We identify which Freshsales tier the customer has selected (Growth at $15/user, Pro at $49/user, or Enterprise at $79/user) and confirm that API access is enabled on the destination. The scoping output is a written migration scope with object counts, a mapping matrix, and a confirmed timeline.

Schema setup in Freshsales

We create the destination schema in the customer's Freshsales environment before any data extraction. This includes custom Contact fields for availability windows (minTime, maxTime, slotDuration, sessionLimit), custom User fields for practitioner wage and session rate data, Product Categories mirroring the Bizstim group_id hierarchy, and any custom fields needed for payment history if Deals are used for transaction tracking. Schema is deployed into the customer's Freshsales sandbox or test environment first for validation before production migration.

API extraction with rate-limit handling

We extract Bizstim data object-by-object through the Enterprise-tier REST API in dependency order: Service Groups (for catalogue structure), Services (with group_id references), Users and Staff (deduplicated), Practitioners (merged with Staff), Clients (with availability windows), Payments (with client and practitioner references). We implement exponential backoff on 429 responses and segment large extractions across off-peak windows. The 1,000 req/hour per-key limit is tracked throughout and a secondary API key is requested from the Enterprise account if total record count exceeds 50,000 to avoid throttling delays.

Owner and practitioner reconciliation

We extract every distinct Bizstim Practitioner and Staff record and resolve them to Freshsales User records by email match. Practitioners who are also customer-facing contacts receive both a User record (for pipeline assignment) and a Contact record. Practitioners who are only internal staff receive a User record only. Any Practitioner or Staff record without a resolvable email is held in a reconciliation queue for the customer's admin to provision the appropriate Freshsales User before record import resumes.

Production migration in dependency order

We run production migration into the live Freshsales environment in record-dependency order: Product Categories (from Service Groups), Products (from Services), Users (resolved Practitioners and Staff), Contacts (with availability custom fields), Deals (if payment history is mapped to pipeline Deals), Notes and attachments. Each phase emits a row-count reconciliation report before the next phase begins. Binary file attachments stored in Bizstim client records are identified separately during scoping and migrated as Freshsales document attachments or as a reference link to the customer's document storage.

Cutover, validation, and automation inventory handoff

We freeze Bizstim write access during the cutover window, run a final delta migration of any records modified during the migration process, then enable Freshsales as the system of record. We validate a random sample of 25-50 records against the source data and deliver the automation inventory document covering every active Bizstim SMS reminder, auto-invoice rule, and reminder schedule with a recommended Freshsales Flow equivalent. We support a one-week hypercare window for reconciliation issues. Workflow rebuild, Freshsales Flow configuration, and SMS template recreation sit outside the migration scope as a separate admin task or engagement.