Back to blog
Jul 05, 2026
4 min read

When Salesforce Isn't Enough: Bringing Azure Into a Salesforce-Centric Consultancy

Why a Salesforce-focused consultancy should consider Microsoft Azure — the platform limits that force the decision, how to make the business case, and what changes once you can combine both.

I work in a consultancy that grew up around Salesforce — Marketing Cloud and B2C Commerce especially. That focus is a strength: deep platform expertise, certified people, a delivery model that clients trust. But every platform has an edge, and part of an architect’s job is to notice when a project keeps bumping into it.

Part of my work now is helping the practice diversify toward Microsoft Azure — not to move away from Salesforce, but to make the Salesforce work better. What follows is the reasoning, because the why matters more than the what.

The edges we kept hitting

Salesforce is exceptional at what it’s for: customer data, journeys, commerce, the engagement layer. The friction showed up at the seams, in patterns like these:

  • Custom compute that doesn’t belong in a marketing platform. Heavy data transformation, scheduled jobs, image or document processing — doable with contortions inside SFMC, but you’re fighting the tool.
  • Integrations with systems that aren’t Salesforce. ERPs, PIMs, logistics, custom back-offices. You need a place to host middleware, queues, and APIs that isn’t tied to a single SaaS.
  • Cost and governance at scale. Some workloads are simply cheaper and more controllable on general-purpose cloud than as add-ons to a SaaS licensed per feature.
  • Data and AI. When a client wants to combine Salesforce data with everything else and run models on top, you want a real data platform underneath.

None of these say “Salesforce is bad.” They say “Salesforce is one layer, and a mature solution usually needs more than one.”

Making the case (to a business, not just to engineers)

Introducing a second cloud into a focused consultancy isn’t a technical decision — it’s a commercial one. The argument that landed wasn’t “Azure is cool.” It was:

  1. We were already losing scope. Whenever a deal needed custom cloud, integration middleware, or a data platform, that part went to someone else. Owning it means bigger, stickier engagements.
  2. It de-risks the client relationship. Being able to say “we’ll handle the Salesforce side and the surrounding architecture” turns us from a specialist vendor into a trusted advisor.
  3. It’s a natural fit with our world. [Retail and e-commerce clients / the segment we serve] often already live in the Microsoft ecosystem. Meeting them there lowers friction.

The message to leadership was framed in pipeline and margin, not in services and functions. That’s the translation an architect has to be able to do.

What I actually took ownership of

Strategy on paper isn’t enough. In practice this has meant taking ownership of [our Azure environment / the company’s cloud footprint], along with [the corporate Git, domain, and website] — the connective tissue a services company needs to operate credibly. That foundation lets the team:

  • Host integration middleware and APIs (Functions, Service Bus, App Service) that sit between Salesforce and everything else.
  • Run scheduled and event-driven workloads outside the marketing platform.
  • Stand up data and, increasingly, AI capabilities next to the Salesforce data instead of trapped inside it.

Reference pattern: Salesforce as the engagement layer, Azure as the backbone

The architecture I keep coming back to looks like this:

  • Salesforce owns the customer-facing layer — Marketing Cloud journeys, B2C Commerce storefronts, the engagement and commerce logic.
  • Azure owns the backbone — integration, custom compute, orchestration, data, and AI.
  • A clean integration contract between them (events + APIs), so neither side leaks its complexity into the other.

Get that separation right and you get the best of both: Salesforce stays clean and upgradable, Azure absorbs the custom work that would otherwise pollute it.

What changed

The real shift is in the conversations. We stopped scoping projects down to “the part we do” and started designing the whole solution. For a consultancy, that’s the difference between being a line item and being the architect of record — and for me personally, it’s the difference between delivering someone else’s plan and shaping it.

Diversifying isn’t disloyalty to Salesforce. It’s what lets us take Salesforce further.

If you’re weighing how to combine Salesforce with a broader cloud architecture, I’m always happy to compare notes.