Migrate from OneSuite to Salesforce Sales Cloud

OneSuite's single Client entity holds both individuals and organizations. We pre-scan every Client record during discovery to classify by presence of a company name field. Clients with a company name populate Account.Name, Website, Industry, and phone; clients with only personal name fields populate Contact.FirstName, LastName, Email, and Phone. All Client-level custom fields (clientTier, clientSource) are mapped to the corresponding Account or Contact custom field by slug. Account records are created first so that the AccountId lookup on Contact is satisfied at insert time. Any Client-to-Project relationships are preserved as Account-to-Custom_Project__c lookups after the custom object is provisioned.

OneSuite Leads map 1:1 to Salesforce Lead. Pipeline stage names from OneSuite map to Salesforce Lead Status picklist values, which we validate and extend if needed before migration. Source attribution (leadSource) and any scoring values migrate to Salesforce LeadSource and a custom lead_score__c field. The one structural difference is that converted Leads in OneSuite may carry Account or Contact associations; these associations are resolved through the Client split above.

OneSuite's native Project entity (with tasks, milestones, status, and dates) has no direct Salesforce standard object equivalent. We create a custom Project__c object in the destination org before migration, mapping Project.Name, status, start and end dates, and description to typed Salesforce fields. The Client-to-Project relationship is preserved by storing the OneSuite Client ID as an external ID field on Project__c and resolving the AccountId lookup at migration time. Customers with Salesforce Project Management (formerly PF) licensed can use that app as the destination instead; we flag this as a configuration choice during scoping.

Salesforce has no standard Invoice object. We evaluate the customer's invoice complexity during discovery: simple single-currency invoices with line items map to Salesforce Orders; complex multi-currency, tax-configuration-heavy invoices map to a custom Invoice__c object with custom line item and tax fields. Stripe and Quickpay payment integration from OneSuite does not migrate; we flag payment gateway reconfiguration as a post-migration step.

OneSuite Documents (associated with Clients or Projects) map to Salesforce ContentDocument. Document name, type, and URL migrate as metadata fields. Binary content requires file export via OneSuite's UI because no bulk API is available; we chunk files to avoid timeout and pre-validate that individual files are under the 25 MB UI import ceiling. ContentDocumentLink records are created to attach each document to the resolved Account or Project.

OneSuite Files attached to Projects, Tasks, or Invoices migrate to Salesforce ContentDocument with the same ContentDocumentLink attachment pattern. We pre-scan total file volume against OneSuite's plan storage cap (30 GB Freelancer, 60 GB Growing Agency) and flag any account exceeding the cap before migration so that binary content is handled as a post-migration step while metadata and URLs migrate on schedule.

OneSuite's API returns custom fields flattened directly onto the entity with their original slug as the property key. A field named 'client-tier' appears as clientTier on the Client record, not nested under a customFields object. We detect all custom field slugs during discovery, create the equivalent __c fields in Salesforce during schema design, and remap each slug value during transform. If a destination field does not yet exist, we flag it for creation before the migration run begins.

OneSuite Members (team users assigned to Projects, Clients, and Invoices) map to Salesforce User records resolved by email match. Member-to-Project and Member-to-Client assignment relationships migrate to a custom Assignment__c junction object with lookups to User and the relevant parent record. Owners without a matching Salesforce User are held in a reconciliation queue for the customer's admin to provision before record import resumes.

OneSuite Project and Document templates carry metadata and field structure. We map template metadata to Salesforce EmailTemplate (for email-based templates) or to a custom Proposal__c object (for proposal and document templates). Template automation logic, auto-assignment rules, and workflow triggers cannot be replicated automatically; we document the full template logic in the handoff inventory for the admin to rebuild in Salesforce Flow.

OneSuite's user-defined Lead pipeline stages migrate to Salesforce Lead Status picklist values. We extract the full stage list (names, order, and any probability mappings) during discovery, validate them against the destination org's picklist, and extend the picklist with any new values before Lead migration. Stages with custom automation or scoring rules are flagged for manual reconfiguration in Salesforce Flow.

OneSuite stores engagement history on Client records. Calls map to Salesforce Task with TaskSubtype=Call and CallDurationInSeconds; emails map to Salesforce EmailMessage linked to a Task; meetings map to Salesforce Event with start and end time preserved; notes map to Salesforce Note linked via ContentDocumentLink. Activity timestamps are preserved as ActivityDate on the Salesforce records. We use the Salesforce Bulk API 2.0 for large engagement volumes with batch chunking and parent-record lookup resolution.

OneSuite tags stored as multi-checkbox properties on Clients, Projects, or Leads migrate to Salesforce multi-select picklist fields on the corresponding object. Tags used for content or classification purposes migrate to Salesforce Topics with TopicAssignment records. The customer selects the tag strategy during scoping based on how tags are consumed in reporting.