- Why vendor-produced TCO comparisons between Salesforce and Dynamics 365 are structurally wrong — and what a rigorous comparison actually requires
- The true licensing picture including M365 bundle economics, price escalation clauses, and true-up provisions that vendors do not feature in their models
- Implementation and customisation cost differences — the SI day rate differential, the configuration versus development trade-off, and the project risk profile for each platform
- Operating and ongoing development costs — the staff model, managed service options, and the platform administration overhead that dominates cost over a five-year period
- How to build a five-year TCO model that produces a defensible, board-level recommendation — including the sensitivity analysis that surfaces the assumptions the decision is most dependent on
Why Most TCO Comparisons Are Wrong
Every vendor produces a TCO comparison that favours their platform. Salesforce's TCO models show Salesforce as lower cost. Microsoft's TCO models show Dynamics 365 as lower cost. Both are technically accurate within the assumptions they choose. Both are materially wrong because of the assumptions they choose.
The most common manipulations in vendor-produced TCO models are: selecting the licence tier that favours them; omitting implementation costs for their platform while including them for the competitor; using undiscounted list prices for the competitor and negotiated prices for themselves; ignoring ongoing development costs; ignoring staff costs; and using a three-year horizon rather than five years, which compresses the period in which operational costs dominate.
A rigorous TCO model makes none of these manipulations. It uses the same methodology for both platforms, models all five cost components (licence, implementation, operations, ongoing development, exit), applies realistic assumptions based on market data, uses a five-year horizon, and performs sensitivity analysis on the key assumptions. Anything less is not a TCO model — it is a commercial argument dressed as analysis.
This tutorial builds a rigorous framework for a Salesforce vs Dynamics 365 TCO comparison. It does not produce a definitive answer — because the right answer depends on your specific context — but it produces the analytical structure that will surface the answer for your organisation if you apply it honestly.
The only TCO model worth building is one that is built independently — not by the Salesforce partner, not by the Microsoft partner, and not by either vendor's account team. Engage a management consultancy or independent technology advisor with no implementation revenue stake in the outcome to build the model. The cost of an independent TCO analysis (£20,000-£60,000 depending on scope) is trivially small relative to the cost of a wrong platform decision at enterprise scale. If the decision is between two platforms at £5M+ of five-year investment, the cost of independent analysis is less than 1% of the decision value.
Licensing: The Visible Cost
Licensing is the most visible cost component and the one that receives the most attention in comparisons. It is also the cost component that is most susceptible to commercial manipulation — through negotiation, bundling, and pricing structure.
List Price Comparison
At list price, Salesforce Sales Cloud Enterprise is approximately £150 per user per month. Dynamics 365 Sales Enterprise is approximately £80 per user per month. At 1,000 users over five years, this difference — if taken at list price — represents approximately £4.2 million. This is a significant number, and it is real. But list price comparison is the beginning of the analysis, not the end.
The M365 Bundle Effect
For organisations with Microsoft 365 E3 or E5 licences — which covers the majority of large enterprises — Dynamics 365 Sales is available as an add-on to the M365 licence at substantially reduced pricing. The precise discount depends on contract negotiation and the specific M365 tier, but effective Dynamics 365 Sales pricing for an M365 E5 customer can be as low as £30-£50 per user per month for the Sales module. At this effective price, the Dynamics 365 advantage over Salesforce at list price is not £70 per user per month — it is £100-£120 per user per month.
This M365 bundle effect is the most powerful commercial argument for Dynamics 365, and it is context-dependent. It only applies to organisations that are already M365 E3 or E5 customers. It requires negotiation — it is not automatic. And it requires the organisation to be genuinely committed to the Microsoft ecosystem for the value to be sustainable over the contract period. But for the organisations where it applies, the licensing economics are decisive.
Price Escalation and True-Up
Both Salesforce and Microsoft contracts contain price escalation provisions — typically 3-7% per year — and true-up mechanisms for user count changes. These provisions are routinely modelled incorrectly in TCO analyses, either by ignoring escalation entirely or by applying a flat escalation rate that does not reflect the actual contractual terms.
Salesforce's price escalation clauses have historically been more aggressive than Microsoft's, with some enterprise agreements containing provisions for price increases at contract renewal that can be significantly higher than the annual escalation during the contract term. The difference between a Salesforce contract that includes price protection for renewal and one that does not can represent millions of pounds over a ten-year platform lifecycle. This is a negotiation item, not a fixed cost — and it requires expert commercial negotiation to manage.
| Licence Factor | Salesforce | Dynamics 365 | TCO Model Note |
|---|---|---|---|
| Enterprise list price (Sales) | ~£150/user/mo | ~£80/user/mo | Use as baseline; expect significant negotiated discounts for both |
| M365 E3/E5 bundle price | N/A | ~£30–50/user/mo (effective) | Applies only to existing M365 E3/E5 customers; requires negotiation |
| Annual price escalation (contract) | 3–7% (varies) | 3–5% (typically lower) | Model contractual rate, not market assumption |
| Renewal price protection | Negotiable — push hard | EA renewal typically smoother | Model Year 6 price explicitly — this is where the risk lives |
| AppExchange / ISV add-on cost | Often material (CPQ, etc.) | Lower AppSource spend typically | Include all ISV licences in the model — this is frequently omitted |
Implementation and Customisation Costs
Implementation cost is the second largest component of CRM TCO and the one with the highest variance — between platforms and between organisations. A Salesforce implementation and a Dynamics implementation for the same functional scope at the same scale will have different cost profiles, different risk profiles, and different delivery timelines.
SI Day Rate Differential
Salesforce implementation day rates in London are typically £900-£1,400 for architects and senior consultants. Dynamics 365 rates from comparable SIs are typically £700-£1,100. The differential is real — reflecting the supply/demand imbalance in the Salesforce specialist market — and it compounds over a large programme. For a 12-month implementation programme with 20 FTE consultants, the day rate differential represents £500,000-£1,000,000 in SI cost.
This does not mean Dynamics is cheaper to implement overall. Dynamics implementations often require more days to deliver the same functional scope, because the Microsoft Power Platform tooling, whilst powerful, has a higher configuration overhead per feature than Salesforce's declarative tooling for standard CRM requirements. The net SI cost position depends on the scope: for standard CRM, Dynamics may be slightly cheaper despite higher day count. For complex customisation, Salesforce's more mature developer tooling and the larger talent pool can offset the day rate disadvantage.
Configuration vs Development Cost
Both platforms allow standard CRM configuration without code — but the threshold at which configuration ends and development begins is different. Salesforce Flow and the declarative toolset are mature and handle complex process automation without Apex code. Dynamics Power Automate handles standard workflows well. For non-standard requirements — complex integrations, custom UI components, advanced data transformations — both platforms require code.
Salesforce Apex development is more expensive than .NET/C# development on Dynamics (reflecting developer supply), but Salesforce has a larger pool of pre-built solutions through the AppExchange that avoid custom development entirely. The build-versus-buy decision — whether to build a custom solution or license an AppExchange package — is one of the most significant cost variables in Salesforce implementations and should be explicitly modelled for each major requirement.
Data Migration Cost
Data migration cost is similar for both platforms at comparable scale and data quality. The primary variable is source system complexity, not target platform. The assumption that migrating to Dynamics is cheaper because of a shared Microsoft ecosystem is generally wrong — Dynamics' Dataverse has its own data model, and migration from a legacy CRM to Dynamics requires the same cleansing, transformation, and validation work as migration to Salesforce.
Operating and Ongoing Development Costs
Operating costs are the component that most organisations underestimate most severely. Over a five-year period, operating costs — platform administration, managed services, and ongoing development — typically exceed implementation costs for both platforms. They are also the component where the difference between the two platforms is least visible at the time of the initial decision.
Platform Administration Cost
A mid-sized Salesforce implementation (500-2,000 users) typically requires 2-4 permanent Salesforce administrators to maintain configuration quality, manage the release cycle, handle user access, and support the business. At a fully loaded cost of £65,000-£85,000 per head, this represents £130,000-£340,000 per year in administration staff cost alone.
Dynamics 365 administration requires similar headcount in a comparable deployment, but the role is typically a Microsoft 365 administrator extended with Dynamics responsibility rather than a dedicated Dynamics specialist. The fully loaded cost is often £50,000-£70,000 per head — lower than a Salesforce administrator — but the platform governance overhead can be comparable or higher depending on Power Platform complexity. At 500-2,000 users, the Dynamics administration cost advantage is typically £30,000-£80,000 per year compared to Salesforce.
Ongoing Development Cost
Every CRM implementation generates an ongoing development backlog. Features that were deferred from the initial implementation, new requirements from the business, regulatory changes that require data model adjustments, and integration changes as adjacent systems evolve — all of these generate work that requires platform expertise. This cost is the most consistently omitted from TCO models and the most consistently underestimated when it is included.
For a 1,000-user Salesforce implementation, a realistic ongoing development cost is £200,000-£400,000 per year. This covers a retained SI team of 2-4 consultants, or an equivalent internal development capability. The equivalent Dynamics cost is £150,000-£300,000 per year, reflecting the lower SI day rate. Over five years, the Dynamics development cost advantage is £250,000-£500,000 at this scale.
Managed Service vs Internal Capability
Organisations have a choice between building internal platform capability (permanent staff) and engaging an SI for a managed service. Both have merits and the right answer varies by organisation. Internal capability is more responsive, builds institutional knowledge, and has a lower incremental cost for small changes. Managed service provides flexibility in capacity, access to a broader skill set, and reduced recruitment risk.
The managed service market for Salesforce is larger and more competitive than for Dynamics 365 in most geographies, which means Salesforce managed service pricing has more competitive pressure on it. Dynamics managed service pricing in some geographies is less competitive because there are fewer qualified providers. This is a market data point to check locally, not a universal rule.
In a five-year TCO model, the licence and implementation costs dominate in years 1-2. From year 3 onward, operating and ongoing development costs become the dominant component. For most 1,000+ user organisations, the cumulative operating cost over years 3-5 exceeds the year 1-2 implementation cost. This is why TCO models using a 3-year horizon consistently underrepresent the true cost difference between platforms. The decision that appears close on a 3-year model often becomes clear on a 5-year model once operating costs are properly included.
Building the Five-Year TCO Model
The five-year TCO model is the analytical output that makes the platform decision defensible at board level. Here is the methodology and the cost categories that must be included for the model to be credible.
The Six Cost Categories
Category 1 — Core licence. User count by year (planned growth, not current state), multiplied by the negotiated per-user per-month price, with contractual price escalation applied year over year. Include all modules in scope — not just Sales Cloud, but also Service Cloud, Marketing Cloud Account Engagement, Field Service, and any Einstein AI licences. Include the M365 bundle offset for Dynamics if applicable.
Category 2 — ISV and AppExchange licences. Every third-party tool that sits on the platform — CPQ, contract management, sales intelligence, document generation, e-signature. For Salesforce, model at least 5-8 AppExchange licences for a complex enterprise deployment. For Dynamics, model AppSource licences and custom integration costs for tools that do not have a native Dynamics equivalent. This category is frequently omitted and frequently material.
Category 3 — Implementation cost. SI delivery cost broken down by phase — discovery, design, build, test, data migration, training, hypercare. Use three SI quotes for each platform, not one. Include a 25-35% contingency for scope changes that are inevitable on a large CRM programme. Include internal project management and business analysis cost — these are real costs, even if they don't appear as external spend.
Category 4 — Operating cost. Permanent platform administration staff — administrator, business analyst, solution architect. Apply fully loaded cost including employment overhead, benefits, and management. Model the headcount ramp-up from go-live to steady state (typically 18-24 months). Include the cost of the initial build team that transitions to a smaller steady-state team.
Category 5 — Ongoing development cost. Annual retainer or equivalent internal cost for the backlog of enhancements, integration changes, and new feature deployments. Model as a percentage of the original implementation cost — typically 15-25% per year for the first three years, reducing to 10-15% in years four and five as the platform matures.
Category 6 — Exit cost. What does it cost to leave this platform in year 7 if the decision needs to be reversed? Data export, decommissioning of integrations, transition to a replacement platform. This is a risk cost rather than a certain cost, but it should be modelled and included in the sensitivity analysis. Platform lock-in has a cost that belongs in the TCO model.
The Sensitivity Analysis
Once the base case model is built, the sensitivity analysis reveals the assumptions the decision is most dependent on. Test three scenarios: pessimistic (costs 30% higher, benefit realisation 30% lower), base case, and optimistic (costs 20% lower, benefit realisation 20% higher). The decision should be robust across all three scenarios. If the decision flips between Salesforce and Dynamics in the pessimistic scenario, the decision factors require more confidence before a recommendation can be made.
The two assumptions that most frequently flip the decision in sensitivity analysis are: (1) M365 bundle pricing — if the Dynamics bundle pricing cannot be achieved, the licence advantage narrows significantly; and (2) SI day rate trajectory — if Dynamics day rates increase as demand grows, the implementation and ongoing development cost advantage reduces.
| TCO Component | Salesforce (1,000 users, 5yr) | Dynamics 365 (1,000 users, 5yr) | Key Variable |
|---|---|---|---|
| Core licence (negotiated) | £5.4M–£7.2M | £1.8M–£3.6M (with M365 bundle) | M365 bundle eligibility and negotiated rate |
| ISV / AppExchange licences | £0.5M–£1.5M | £0.2M–£0.8M | ISV tools required and availability of native equivalents |
| Implementation (including data migration) | £2.5M–£5.0M | £2.0M–£4.0M | Scope complexity and chosen SI |
| Platform administration (staff) | £1.3M–£2.0M | £0.9M–£1.5M | Headcount model and staff cost in your market |
| Ongoing development (retained SI or internal) | £1.0M–£2.0M | £0.75M–£1.5M | Backlog volume and SI/internal split |
| Indicative 5-year total | £10.7M–£17.7M | £5.65M–£11.4M (M365 org) | Gap narrows significantly without M365 bundle |
The figures in the table above are illustrative ranges based on typical enterprise deployments. Your actual costs will vary based on negotiated pricing, specific scope, market talent rates, and your internal capability model. Do not use these ranges as estimates for your own TCO model. They are intended to illustrate the relative magnitude and structure of the cost components, and to show where the significant differences between the two platforms lie. Build your model from your actual quotes, your actual headcount costs, and your actual contract terms.
Presenting the TCO Model
A TCO model that is not presented correctly is not useful. The presentation should show: the base case five-year total for each platform; the key assumptions driving the difference; the sensitivity ranges; and the specific conditions under which the decision would change. The last point — what would need to be true for the losing platform to win — is the most important element for executive-level decision-making because it surfaces the dependencies explicitly.
If the Dynamics 365 five-year TCO is £5M lower than Salesforce under base case assumptions, but the model is sensitive to M365 bundle pricing (which requires negotiation), the executive team needs to know that the decision depends on achieving that bundle price. If they can achieve it with confidence, Dynamics wins. If the commercial negotiation is uncertain, the TCO advantage may not materialise, and the decision may be closer than the base case suggests.
Key Takeaways
- Licensing is the most visible cost component but typically not the largest over five years — operating costs and ongoing development dominate from year three onwards, and TCO models that use a three-year horizon consistently misrepresent the true cost position.
- The Microsoft 365 bundle pricing effect can reduce the effective Dynamics 365 licence cost to £30-50 per user per month for M365 E3/E5 organisations — this is the most decisive single factor in the TCO comparison, and it only applies to organisations that can achieve it through negotiation.
- SI day rate differentials (typically £200-£300 per day in favour of Dynamics) are partially offset by higher day counts on Dynamics for the same functional scope — the net implementation cost difference is lower than the day rate difference suggests, and varies significantly by scope complexity.
- Platform administration staff cost is £30,000-£80,000 per year lower for Dynamics at mid-market scale, reflecting the lower salary level of a Dynamics/M365 administrator versus a dedicated Salesforce administrator.
- A credible TCO model includes six components: core licence, ISV licences, implementation, platform administration, ongoing development, and exit cost — omitting any of these produces a model that will not hold up to independent scrutiny.
- The sensitivity analysis is as important as the base case — if the decision flips between platforms in the pessimistic scenario, the model has dependencies that require resolution before a recommendation can be made at board level.
- Independent TCO analysis (£20,000-£60,000) is essential for decisions above £5M of five-year investment — the cost is trivial relative to the decision value, and a vendor-produced or SI-produced model will not be accepted as objective by a well-governed board.
Checkpoint: Test Your Understanding
1. A five-year TCO model for a 1,000-user CRM deployment shows Dynamics 365 at £7M and Salesforce at £12M under base case assumptions. The primary driver of the difference is M365 bundle pricing. Sensitivity analysis shows that without M365 bundle pricing, the Dynamics TCO rises to £10M. What does this tell the decision-making team?
2. Why do most TCO models for Salesforce vs Dynamics 365 use a three-year horizon rather than five years, and why is this a problem?
3. Which cost category is most consistently omitted from CRM TCO models, and why does its omission materially distort the comparison?
Discussion & Feedback