Portmux is a Salesforce to Dynamics 365 migration service that moves your accounts, opportunities, custom entities, and security model into Dynamics 365 Sales with the role-based access and business process flows your sales ops team designed.
Salesforce-to-Dynamics is rarely a downgrade decision, it's usually about Microsoft 365 entitlements, Power Platform consolidation, or Copilot for Sales. The data models are conceptually similar (Accounts, Contacts, Opportunities), but Dynamics security uses Business Units and Security Roles where Salesforce uses Sharing Rules and Profiles. We map both data and access so your reps don't lose visibility on day one.
Salesforce Accounts mapped to Dynamics Accounts with parent/child hierarchies and Account Team Members carried over as Access Team rows.
All Contacts with custom fields, primary Contact role, and Contact-to-Account relationships preserved.
Opportunities mapped to Dynamics Opportunities with stage history, ForecastCategory translated to Sales Stage, and Products imported as Opportunity Products.
Leads migrated to Dynamics Leads with Lead Source, qualification status, and qualified Lead lineage tracked back to Account/Contact/Opportunity.
Salesforce custom objects recreated as Dynamics custom entities with all fields, relationships, option sets, and forms.
Tasks, Events, Calls, and EmailMessages mapped to Dynamics Activities (Phone Call, Appointment, Task, Email) with original Regarding records.
Notes and ContentDocumentLinks moved to Dynamics Annotations; large files routed to SharePoint integration if enabled.
Salesforce Profiles and Permission Sets analyzed and re-implemented as Dynamics Security Roles within the appropriate Business Units.
Sales Process pipelines re-implemented as Dynamics Business Process Flows with stage gating and required fields.
Salesforce Email Templates ported to Dynamics Email Templates with merge field syntax converted to Dynamics dynamic content.
Critical Salesforce Reports rebuilt as Dynamics Views, Charts, and Power BI dashboards.
Active Workflows and Process Builder re-implemented as Power Automate Cloud Flows and Dynamics Real-Time Workflows.
We connect to Salesforce via OAuth and to Dynamics 365 via Azure AD application registration with the System Administrator role. Salesforce metadata API enumerates every entity, custom field, sharing rule, and Process Builder flow. The schema map identifies entities that need to become Dynamics custom entities versus extensions of standard entities.
Mapping covers four layers: data (Salesforce field → Dynamics attribute), security (Profile + Permission Set → Security Role + Business Unit), process (Sales Process → Business Process Flow), and integration (Outbound Messages → Power Automate). Your sales ops lead approves each layer before we touch Dynamics.
We load Dynamics in a sandbox first and run a side-by-side test for a week with your power users. On cutover day, the sandbox is promoted to production, Salesforce is set to read-only, and we redirect all Outlook, mobile, and integration clients to Dynamics with a guided sign-on flow.
Every migration has its own gotchas. Here's what we plan for on this specific path.
Salesforce uses Profiles + Permission Sets + Sharing Rules + Roles. Dynamics uses Security Roles + Business Units + Teams. There's no automatic mapping. We build a matrix of who-sees-what in Salesforce today and re-design it in Dynamics terms before any user is provisioned.
Salesforce Sales Process is a picklist with required-fields-per-stage. Dynamics Business Process Flow is a workflow object with branching, stage skipping, and immutable stage history. The migration recreates each stage but the user experience is different and reps need a 30-minute orientation.
Apex Triggers and Classes need to be re-implemented as Power Automate flows, Dynamics Plugins (.NET), or Azure Functions. We don't port Apex automatically, we deliver a Power Automate replacement spec and either implement it in scope or hand it to your devs.
Dynamics Annotation has a 32MB attachment limit. Larger Salesforce ContentDocuments are routed to SharePoint via the Dynamics-SharePoint integration during migration, with a stub Annotation linking back to the SharePoint location.
Single-system migrations like Salesforce to Dynamics 365 run as Track A engagements: one source, one destination, up to 1M records, 4–6 weeks. Final price depends on object volume, custom field count, and integrations, scoped on a 20-minute call before any commitment. See full pricing →
Tell us what's in the source, where it's going, SaaS or custom, and when you need to be live. You'll walk away with a scoped quote, a named engineer, and a go-live date.