Migrate from OneSuite to Microsoft Dynamics 365 Sales

OneSuite's Client is a unified entity holding both person-level contact details and company-level information. We split Clients into Dynamics 365 Accounts (company data: name, domain, address, industry) and either Contacts (qualified buyers: direct phone, email, title) or Leads (unqualified prospects: source attribution, initial interest). The split rule is defined during scoping, typically using OneSuite's ICP status flag or revenue tier property. OneSuite's original Client ID is preserved in a custom field src_client_id__c on both the Account and the related Contact or Lead for cross-reference.

OneSuite's distinct Lead object (pipeline stages, source attribution, scoring) maps directly to Dynamics 365 Lead. The leadstage property maps to Lead Status, source tracking maps to LeadSource, and scoring values transfer to a custom field src_lead_score__c. We preserve the full pipeline stage order as Lead Status values configured in Dynamics before import.

OneSuite Projects link directly to Clients. We map Projects as a custom entity in Dynamics 365 (or msdyn_project if the customer licenses Project Operations) and reconstruct the Client-to-Project relationship by resolving the Account or Contact lookup at migration time. Project tasks and milestones migrate as related custom records with a parent_project__c lookup field.

OneSuite Invoices reference Clients and contain line items, tax rates, payment status, and currency. We map standard invoice fields (invoice number, date, due date, total amount, tax amount) to Dynamics 365 Invoice if the customer holds Sales Enterprise, or to a custom Invoice entity for Sales Professional. Multi-currency and complex tax configurations are flagged for manual reconciliation post-migration because Dynamics 365 handles currency at the org level via the TransactionCurrency entity, which requires pre-configuration.

OneSuite Documents can be associated with Clients or Projects. We transfer document metadata (name, type, URL, associated Client reference) and map the URL to a SharePoint location linked from the Dynamics 365 Account or Contact. Binary file content does not migrate directly; we flag any Documents exceeding the account's plan storage cap (30 GB Freelancer, 60 GB Growing Agency) before committing the import so the customer can provision additional SharePoint capacity separately.

Files attached to Projects, Tasks, or Invoices migrate as ContentDocument records linked via ContentDocumentLink to the parent Account, Contact, or custom Project entity. File URLs transfer to SharePoint document locations. Files approaching or exceeding plan storage caps are flagged for separate SharePoint provisioning; binary content is not duplicated into Dataverse storage unless the customer has confirmed available capacity.

OneSuite returns custom fields flattened onto the entity with their original slug as the property key (e.g., clientTier appears as clientTier on the Client record). We parse each slug, create the equivalent custom field in Dynamics 365 using the default new_ prefix (e.g., new_clienttier), and preserve the mapping in the migration manifest so no custom field values are dropped. If a custom field in OneSuite has no equivalent in Dynamics, we flag it for creation before migration runs.

OneSuite Members are team users assigned to Projects, Clients, and Invoices. We map Members to Dynamics 365 User records by email match. Any OneSuite Member without a matching User in the destination org is held in a reconciliation queue for the customer's admin to provision before record import resumes because OwnerId references are required on most standard objects.

OneSuite Templates (Project and Document templates) contain metadata and field structure but no automation logic. We migrate template metadata and note the field tokens for manual rebuild in Dynamics 365 Email Templates or SharePoint library templates. Template automation logic (auto-assignment, workflow triggers) does not replicate and is documented separately for admin rebuild.

OneSuite's user-defined lead pipeline stages vary by agency configuration. We map stage names and order to Dynamics 365 Lead Status values and create a custom Option Set for any pipeline-specific stage semantics that do not map directly to the standard Lead Status picklist. Stages with custom automation or scoring rules are flagged for manual reconfiguration post-migration.