Migrate from OneSuite to Freshsales

Discovery and scope enumeration

We audit the source OneSuite account across plan tier, total Client count, Project count, Lead pipeline structure, Invoice volume and currency complexity, Member count, and custom field inventory. We pre-scan storage consumption to flag accounts approaching tier limits, enumerate the total Lead count against the plan cap, and identify any custom field slugs that require Freshsales custom field pre-provisioning. The discovery output is a written migration scope document with record counts per entity and a list of fields requiring destination-side configuration before migration runs.

Schema design and object mapping configuration

We design the destination Freshsales schema to accommodate the OneSuite data model. This includes creating custom fields on Contact, Account, Lead, and Deal objects to receive the remapped OneSuite custom field values. We configure Deal stages to map from the OneSuite Lead pipeline. For the Client-to-Project relationship, we define custom fields on the Deal object to store the project reference and create any necessary custom objects if the customer requires a formal project hierarchy. We deploy the schema to a Freshsales trial or sandbox environment first for validation.

Test migration in Freshsales sandbox or trial

We run a test migration using a representative sample of OneSuite data (typically 50-100 records per entity type) into a Freshsales trial account. This validates the custom field mappings, the slug remapping logic, the Client-to-Contact-or-Account split rule, and the Project-to-Deal custom field mapping. Any import errors, dropped values, or record truncation issues surface here. We reconcile record counts and spot-check mapped values against the source before committing to a production migration date.

Data extraction from OneSuite

We extract all records from OneSuite using the officially documented CSV and JSON import paths. We chunk large datasets into multiple files to avoid import buffer limits, sequence the extraction by entity dependency, and validate record counts at the source before initiating the Freshsales import. We also extract document metadata and URLs separately from binary content, which we flag for manual handling post-migration. All custom field slug names are captured in the extraction manifest for the remapping phase.

Data transformation and import into Freshsales

We transform extracted records using the configured object mapping: Clients split into Contacts and Accounts based on record type; Projects map to Deals with custom fields for project metadata; Leads map directly to Freshsales Leads with score and source preserved; Invoices map to Deals with financial fields retained. We remap every custom field slug to its Freshsales equivalent. Member emails are resolved against the Freshsales User table. We import in dependency order (Users, Accounts/Contacts, Leads, Deals, Notes) and emit row-count reconciliation reports at each phase.

Validation, cutover, and rebuild handoff

We validate the production migration by reconciling record counts against the source data across all entities. We spot-check a sample of migrated records against OneSuite for field-level accuracy. We deliver the migration report alongside a written rebuild inventory for any project structures, automations, and pipeline configurations that require manual recreation in Freshsales. We support a one-week hypercare window for reconciliation issues raised during initial team use. We do not rebuild workflows, sequences, or project task structures as part of the standard migration scope.