Alright folks, I'm coming at this from a slightly different angle. We just wrapped an 18-month migration for a client from a legacy on-prem CRM to a cloud solution, and the final contenders were Dynamics 365 (Customer Engagement + F&O) and Salesforce (Sales Cloud + Manufacturing Cloud). ~1000 users, complex supply chain, make-to-order and configure-to-order scenarios.
My role was less on the sales module selection and more on the platform engineering, integration, and ongoing operational cost side. Here's what I saw break, what worked, and what keeps me up at night.
**The "Gotchas" Nobody Talks About Enough**
1. **Integration Tax:** Both platforms promised "easy" connectivity to our ERP and PLM. The reality? Every external API call, every middleware hop, adds latency and cost. With Salesforce, we leaned heavily on MuleSoft (expensive, but capable). With D365, it was Azure Logic Apps and API Management. The bill for data egress and integration runtime hours became a significant line item.
```yaml
# Example of a cost-optimization we had to implement later for Logic Apps:
# Original: Polling every 5 mins for order updates
trigger:
type: Recurrence
interval: 5
frequency: Minute
# Optimized: Changed to Event Grid from ERP, saving ~8640 executions/month
trigger:
type: EventGrid
endpoint: https://prod-endpoint.azure.net/eventgrid
```
2. **Customization Sprawl:** Manufacturing has unique processes. Both platforms let you bend them to your will. Salesforce with Apex/Flow, D365 with plugins and Power Automate. We ended up with over 200 custom objects and 500+ flows in the POC stage for Salesforce. D365's model-driven approach felt more constrained initially, but that constraint prevented some "unmaintainable magic" later. Version controlling these customizations (using solutions in D365, SFDX for Salesforce) became critical for our GitOps pipelines.
3. **The 1000-User Scaling Hit:** License costs are obvious. The hidden cost is performance tuning. Page load times for complex BOM (Bill of Materials) views in the web UI became a problem. We had to implement:
* Aggressive API response caching at the Azure Front Door / CDN level.
* Database indexing strategies that the SaaS vendors initially resisted ("our platform handles it").
* Asynchronous reporting jobs to avoid report timeouts during peak hours.
**What I Wish We'd Known Before Signing**
* **Test Data Migration at Scale EARLY.** Don't just test 100 records. Test 100,000. We found D365's data import API throttled more aggressively under load, which changed our migration window strategy.
* **Define "Platform Responsibility" in the Contract.** Where does their black box end and your responsibility begin? Get clear on monitoring access, log retention, and their SLA on API latency. We had a nasty issue where degraded performance in their multi-tenant database took a week to diagnose because we couldn't see the right metrics.
* **Build the "Decommission" Plan at the Start.** How do you get your data *out* if you need to? For audit and compliance, we had to build a regular export pipeline to our own data lake (on Azure) anyway. Doing that design upfront saved pain later.
In the end, they went with D365, primarily due to deeper ties to their existing Microsoft ecosystem (Azure AD, Teams, Office) and the unified data model with Finance & Operations. The licensing was... complex, but predictable.
The biggest win for us on the platform side was treating the CRM not as a silo, but as just another workload in our Kubernetes cluster (for the custom microservices we built around it) and using GitOps for all the surrounding config. ArgoCD manages our Helm charts for the custom APIs that sit between the CRM and the shop floor systems.
Would love to hear from others who've been through this fire. How did you handle CI/CD for your CRM customizations? Any clever cost-optimizations on the integration side?
-jk