Microsoft Dynamics 365 · Migration
We migrate from eight typical source systems to Microsoft Dynamics 365 — structured, without data loss. With a clear 4-phase model, fixed-price migration packages from €25,000, and a hypercare phase that doesn't end when the cutover runs but only when the new system really carries. Microsoft Dynamics 365 migration with 20+ years of practice since CRM 3.0.
Terminology
Three terms are used interchangeably in the market — and lead to different project scopes, risk profiles, and investment corridors. We separate them deliberately at the start of every migration conversation.
System migration. You change the CRM system as a whole — from Salesforce, HubSpot, SugarCRM, or an on-premises Microsoft CRM to Microsoft Dynamics 365. Data, processes, customizations, integrations, and users all move along. The hard cutover date separates an old world from a new one. This is the most common case in the mid-market and the focus of this topic page.
Data migration. You keep an existing Microsoft Dynamics 365 system but pull in data from an additional source system — typically after a company acquisition, a subsidiary consolidation project, or system outsourcing. Here it's not the platform that changes but data ownership. The effort sits in mapping and cleansing logic, not in cutover choreography.
Hybrid migration. For a transition period you run two systems in parallel — usually during a phased migration of a group with several subsidiaries, or in a module-by-module migration (Sales first, Customer Service later). Complexity shifts to integration: data must be kept in sync during the transition without forgetting conflict logic.
Which migration type describes your situation is something we clarify in the first discovery conversation. The answer decides methodology, tools, and timeline — it's not a detail to be sorted out later.
Migration paths
In two decades of CRM practice, eight source-system constellations recur. Per path, methodology, effort, and pitfalls differ — what you find here is an initial classification, not a fixed-price offer.
Path 01 · most common
By far the most common migration path in our portfolio. Full data migration via the Salesforce Bulk API combined with the Microsoft Data Migration Tool. Accounts, contacts, opportunities, activities, custom objects, files, and attachments can be moved cleanly on a technical level. Effort drivers: number of custom fields, Apex code rebuild, and Salesforce reports mapping to Power BI.
Path 02 · complex
Complex path with custom-logic reimplementation on Microsoft Power Platform. ABAP logic isn't ported but rebuilt based on documented requirements. Benefit: you free yourselves from technical debt accumulated over years. Effort: 3–6 times the implementation share compared to standard paths. Often triggered by SAP license consolidations or group strategy shifts.
Path 03 · marketing-centric
Often driven by the need to tie sales pipeline and ERP integration more tightly together. HubSpot contacts, companies, deals, and pipeline stages can be extracted via the HubSpot API. Effort drivers: marketing automation workflows have to be translated to Microsoft Customer Insights Journeys, which is rarely 1:1. Realistic expectation steering is part of the discovery phase.
Path 04 · simple
The simplest migration path — typical for a growing mid-market company outgrowing an SMB tool. Pipedrive offers a clean REST API, the data model is manageable, the number of customizations usually low. SMB quick migration in 8 to 12 weeks realistic, often as an entry into a larger D365 rollout across multiple modules.
Path 05 · Microsoft lift-and-shift
The underestimated path: Microsoft itself does not offer a fully automatic lift-and-shift. Plug-ins, workflows, and JavaScript customizations must be reviewed individually — many are compatible, but not all. Solution export, customization inventory, and sandbox test belong to the standard methodology. Advantage: the data model is already Microsoft-native, the lift share considerably higher than for foreign source systems.
Path 06 · mid-market growth
Typical mid-market growth trigger: the current tool hits limits in ERP integration, permission model, or European data residency. Data migration usually uncritical (clean APIs, manageable model). Effort comes from different conceptual worlds — account hierarchies, lead scoring models, and service case structures are modeled differently per tool and need a conscious remap.
Path 07 · first CRM introduction
The "first real CRM" path: sales teams today work with Excel sheets, an old Access database, or a Notion collection. Data volume small, data quality very variable. The focus isn't on technical migration but on data cleansing and process modeling. Often combined as an SMB quick migration with a greenfield D365 introduction — migration and introduction projects merge.
Path 08 · major version upgrade
Pure major version upgrade. Microsoft renamed the product to Microsoft Dynamics 365 with the 2017 wave and restructured the CE apps. Customizations from CRM 4.0 or 2011 are largely incompatible with modern Power Apps components and have to be rebuilt. Advantage: you clear up 10–15 years of customization sprawl in one conscious step.
4-phase model
Four clearly separable phases with their own deliverables, quality gates, and cost corridor. The model scales for SMB quick migrations (8–12 weeks) just as for enterprise migrations (9–18 months) — the phases are stretched, not skipped.
Data audit at entity, field, and record level. License mapping between the source model and Microsoft Dynamics 365 licenses. Assessment of technical debt in the source system — what's worth migrating, what deliberately isn't.
Cleansing source data in close coordination with the business owners. Mapping sheets per entity, documented non-migration decisions, ETL scripts or Microsoft Data Migration Tool for the technical bridge.
Full test migration into a sandbox environment. At least two runs before the real cutover. Structured user acceptance testing with key users, target-vs-actual validation at record level, documented acceptance criteria per entity.
Cutover with defined data-freeze window, rollback plan, clear communication choreography. Hypercare support with daily office hours in the first two weeks and weekly in the four following weeks.
Selection criteria
Vendor-neutral wording — you should check these six criteria with any migration partner under consideration, regardless of whether arades is the answer in the end or another provider.
Generic CRM migration experience isn't enough. Ask concretely about completed migrations from your current system — Salesforce, SAP CRM, on-premises Microsoft CRM. Get the number of projects, the data volume, and the typical pitfalls explained. Each source system yields different tool stacks and different risk profiles that only come from practice.
A serious partner has a documented methodology: which tools are used for what — Microsoft Data Migration Tool, KingswaySoft, Azure Data Factory, custom scripts. Which quality gates exist between phases. How target-vs-actual validation is performed. An answer like "we use our experience" isn't enough — you need a methodological framework.
Data migration is never just a technical topic. An insurer migrates differently than a machinery manufacturer, an association differently than an IT service provider. The partner should know the typical entity structures, compliance requirements, and stakeholder constellations of your industry — otherwise translation loss arises in every workshop.
Where is data located during the migration process? In which region does the sandbox run? Who has access to which data at what time? Data processing agreement, EU data residency, and a deletion concept for the migration sandbox must be in writing before project start — not just before cutover.
What happens if a blocking problem shows up after go-live? Is there a written rollback plan? Which decision levels, which maximum decision times, which responsibilities? A partner without a documented rollback strategy hasn't thought their methodology through to the end.
Fixed-price migration packages (with clearly defined scope) or pure time-and-materials? Both are legitimate — but you should know what you're buying. Fixed price protects against budget explosions, T&M is more flexible with unclear source data. Caution with hybrids sold as fixed price but triggering change requests for every discovery finding.
Where arades is strong
We don't sell a migration where our strengths don't fit. If another partner is better suited for your constellation, we say so in the discovery conversation.
The Salesforce-to-Dynamics 365 path is the most common in our portfolio. We know the Salesforce Bulk API as well as the typical pitfalls — Apex trigger rebuild, Process Builder migration, Salesforce Reports mapping to Power BI, Lightning Component translation to model-driven apps. We know where lift-and-shift ends and conscious rebuild begins.
SAP CRM migrations are rare — and that's exactly why few partners work on them. We have several completed projects out of SAP CRM and Hybris in our history and know the rebuild approach on Microsoft Power Platform. ABAP logic isn't ported but rebuilt based on documented requirements — a conscious, calculable step.
We have built implementations since Microsoft CRM 3.0 (2005). We have supported every CRM version since 2011 in productive projects. Solution export, customization inventory, plug-in sandbox test, and JavaScript revalidation are standard tools for us, not new territory. That saves significant time in the discovery phase.
Our migration methodology follows CMMI-oriented quality gates: documented transitions between phases, risk reviews before every gate, written approvals per entity mapping. In enterprise migrations with multiple stakeholder groups this protects against misunderstandings that later become expensive.
From over 20 years of practice we have developed our own tools that we deploy in migration projects — for data-quality analysis, mapping-sheet generation, and target-vs-actual validation. These own solutions are not a mandatory component but measurably shorten the Phase-02 efforts in many constellations.
From the first discovery conversation to the end of hypercare you speak with the same practice-tested advisors who also write the mapping sheets and accompany the cutover. No account-manager layer, no handover to an offshore team. In migration projects with a hard cutover date, this continuity is not nice-to-have — it's risk reduction.
Migration packages
Indicative fixed-price ranges from real projects of the last 24 months. The concrete fixed price stands at the end of the discovery phase, not before — a serious migration calculation needs a documented source-system picture.
For smaller sales teams with a manageable source system (Pipedrive, HubSpot, Excel, SugarCRM). Standard entities, few custom fields, no ERP integration in the migration scope.
For mid-market organizations with multiple sales teams, a service area, and at least one ERP integration. Salesforce, SugarCRM, or on-premises Microsoft CRM as typical source systems.
For groups and holdings with a complex source system (SAP CRM, Hybris), custom-logic rebuild, multiple tenants, and compliance requirements from industry specifics.
Trust signal
What we've seen again and again in over 20 years of CRM practice — and what you should avoid regardless of the partner you choose.
01 · Data migration is treated as a pure IT task. Anyone who "hands over" the migration to the IT department and only worries about business after cutover ends up with a technically clean system carrying business-unusable data. A migration is at least 60% a business task — cleansing rules, non-migration decisions, mapping logic belong in the business areas, not in a database console.
02 · Pre-cleansing is skipped. "We'll clean that up later" is the most expensive sentence in any migration project. What you don't clean up before the migration, you drag as technical debt into the new system — including reporting distortions, search performance problems, and user frustration. Data quality investments before cutover pay off many times in the hypercare effort.
03 · UAT phase is planned too short. A user acceptance testing phase of one week is not enough for any serious migration. Realistic is 3 to 6 weeks, with two complete test migration runs. The UAT phase is the moment when business gaps become visible — compressing it means finding problems only after go-live, when they're ten times more expensive to fix.
04 · Cutover window is underestimated. A cutover is a choreography of 30 to 80 documented steps. Anyone wanting to "migrate over the weekend" without an hour-by-hour runbook goes into an avoidable crisis mode. Data-freeze window, role responsibilities, escalation stages, and rollback triggers belong fixed in writing — a week before go-live, not in the moment of the problem.
05 · License takeover is planned wrong. Source system and Microsoft Dynamics 365 have different license models. Anyone calculating a 1:1 takeover of user counts typically pays 20–40% too much. Before cutover should come a license optimization: who needs a full-user license, who is fine with Team Member, where do Device licenses fit. Our License Cost Calculator maps this logic for Microsoft Dynamics 365.
06 · Hypercare phase missing or too short. The cutover does not complete the migration — it starts it. The first two weeks after go-live bring a mountain of questions, small adjustments, and operating corrections. Anyone not planning a dedicated hypercare phase with a fixed daily structure loses users at the decisive moment. A hypercare phase shorter than 4 weeks is unrealistic for mid-market migrations.
Frequently asked questions
An SMB quick migration for 10 to 30 users with a manageable source system (Pipedrive, HubSpot, Excel) is offered as a fixed price from €25,000 net. A mid-market migration for 30 to 150 users from Salesforce or an on-premises CRM runs €60,000 to €180,000. Enterprise migrations with an SAP CRM background, multiple tenants, or complex custom logic start at €250,000. We calculate the concrete fixed price after the discovery phase, not before.
An SMB quick migration takes 8 to 12 weeks from the discovery workshop to the end of hypercare. Mid-market migrations run 4 to 7 months. Enterprise migrations from SAP CRM or Hybris with a custom-logic rebuild take 9 to 18 months. Duration is driven not by data volume but by the number of customizations in the source system.
For standard entities the Microsoft Data Migration Tool and the KingswaySoft SSIS toolkit. For complex mappings and transformations our own ETL scripts in Azure Data Factory or Python. For Salesforce sources the Salesforce Data Loader combined with the Power Platform Dataflows engine. We choose the tool in the discovery phase, not via dogmatic upfront commitment.
With our methodology near zero — structurally. We run at least two complete test migrations into a sandbox environment before the real cutover. Every test migration ends with a target-vs-actual validation at record level. The source system remains read-accessible during the hypercare phase. Data losses typically arise from deliberate non-migration (historical baggage, cancelled opportunities older than 5 years) — which you approve upfront.
Before every migration we check GDPR compliance along three axes: which personal data may be migrated at all (retention periods, consent statuses), where the data is located during the migration process (EU region, no US transit), and how the data processing agreement with all migration subcontractors looks. Microsoft Dynamics 365 in the EU region and a DPA with arades cover the standard. For special categories (health, finance) we deliver an extended compliance concept.
Yes. Every migration of ours plans a rollback point: the source system remains in read-write mode frozen at the cutover-date state during the first two weeks after go-live. If blocking problems arise in that phase, we return in a controlled manner. The rollback plan is fixed in writing before go-live, including responsibilities, escalation stages, and maximum decision time (typically 48 hours).
If you currently buy licenses from another Microsoft Partner, you can switch to arades as your Microsoft CSP during the migration — or stay with your current provider. We do not couple migration advisory to a CSP switch. Practically, a switch makes sense when you want tighter coupling between implementation and license optimization. Details on the topic page for Microsoft Dynamics 365 licensing, pricing, and cost.
Partly — and that's a deliberate architecture decision. For Microsoft Dynamics CRM on-premises estates (2011, 2013, 2015, 2016), many classic plug-ins, JavaScript customizations, and workflows are directly portable. For Salesforce Apex code or SAP CRM ABAP logic there is no lift-and-shift — the logic is rebuilt on Microsoft Power Platform and plug-ins. We calculate the rebuild effort per custom function separately and decide together what really needs to be migrated.
In a migration there is a live source system with real users, real data, and real process logic — and a hard cutover date. In a greenfield introduction the design starts on a blank slate. Migration projects additionally require data-freeze planning, parallel training while the legacy system still runs, and a hypercare phase in which two worlds briefly coexist. More on the regular introduction on the topic page for the Microsoft Dynamics 365 introduction.
The business responsibility for data quality stays with the customer — arades provides the tools, methodology, and experience, but not the business owner. A proven setup is a data steering committee made of sales, service, IT, and management that makes conscious decisions per entity: what gets migrated, what deliberately doesn't, what cleansing rules apply. Without this internal data owner every migration fails — regardless of tool or partner.
Further reading
Discovery, strategy workshop, and architecture review as three formats before the migration decision. Module choice, license architecture, and roadmap — before money flows in the wrong direction.
From the first sprint to go-live. For migration projects often the second half — after the data migration completes, the implementation share for process customization and new features follows.
Three introduction packages (Quick-Start from €60,000, Mid-Market €120,000–€280,000, Plus from €350,000), 4-phase model, and TCO transparency with three calculation examples — as the greenfield variant without migration complexity.
Full-user, Team Member, Device licenses, and add-ons. Before every migration cutover should come license optimization — a 1:1 takeover approach typically costs 20–40% too much.
Microsoft ERP, Dynamics ERP, D365 ERP — terminology after the F&O split of 2024. Business Central for SMB, Finance/SCM/Commerce/Project Operations for demanding mid-market companies.
After go-live and hypercare: predictable Application Care contract with monthly flat fee, SLA-based. Releases, hotfixes, enhancements, tenant hardening — continuous support rather than ticket-only response.
Six integration patterns (API-to-API, iPaaS, ETL, custom connectors, webhooks, direct database) and ten typical scenarios in the mid-market. Migration and integration often run in parallel — the integration layer determines how cleanly legacy data and new processes converge.
30 min · free · no obligation
Tell us about your current source system, your data situation, and your time horizon. We listen, classify, and give you an honest first assessment — which migration path is realistic, what you'll invest, and what to prepare for.
