Microsoft names six products. Which one a problem needs follows from the failure you cannot tolerate, not from the list - and that choice is expensive to reverse.
One message, left to right, with each component in the stage where it earns its place. Then the six on their own, and what each is genuinely good at.
It arrives
It is admitted
It is moved
It is acted on
It lands
Workflow orchestration with connectors to most things. Fast to build, and the connector catalogue is why most teams start here. On the Consumption plan the bill follows executions and counts every retry; Standard is priced on its own hosting plan instead.
The front door: keys, quotas, versioning and a developer portal. The tier decision is the one worth taking slowly, because the tiers differ in isolation, SLA and network integration rather than in throughput alone.
Durable enterprise messaging: queues, topics, dead-lettering, and sessions where messages have to be processed in order. Slower to stand up than a Logic App, and much harder to get wrong later.
Event routing, priced per operation, built for one event reaching many listeners. On push delivery it retries on a schedule and then stops. It is not a durable queue, and using it as one is a common and expensive mistake.
Bulk and scheduled data movement. It overlaps with Logic Apps enough to cause arguments, and the split is about volume and shape rather than capability.
Code, triggered by an event, on the hosting plan you choose. This is where transformation, branching and anything the connector catalogue does not cover belong. Durable Functions extend it to orchestrations that are code and still have to survive a restart.
Start from what must not be allowed to happen, and the component usually picks itself.
| The problem | The component | Why |
|---|---|---|
| Two SaaS products must stay in step | LALogic Apps | The connector already exists |
| An order must never be lost | SBService Bus | Durable, with dead-lettering and sessions for order |
| One event, many listeners | EGEvent Grid | Built for fan-out, and priced for it |
| Partners need controlled access to an API | APIMAPI Management | Keys, quotas and versioning without building them |
| A nightly load of a large dataset | ADFData Factory | Built for volume, not for per-message logic |
| Real transformation, branching or a calculation | FNAzure Functions | Logic belongs in code that can be tested |
| A workflow that must survive a restart | FNDurable Functions | Orchestration in code, with state |
A production estate usually ends up running several of these together, and that is the healthy outcome rather than a sign of sprawl. The failure is rarely picking the wrong one. It is picking one and then bending it to a second job it was never shaped for - a Logic App carrying complex branching through nested conditions, or a function quietly becoming the orchestrator for everything.
Four choices that look like configuration at the start and read as architecture a year in.
On the Consumption plan, a Logic App that retries a failing call every thirty seconds bills every attempt. Set the retry policy deliberately, and alert on execution count rather than on failure count alone.
The tiers differ in isolation, SLA and network integration, not just in throughput, so moving between them is closer to a re-platforming than to a slider. A tier chosen for a pilot rarely survives the first compliance conversation.
On push delivery it retries on a schedule, then dead-letters if a storage destination is configured and drops the event if one is not. Dead-lettering is off until you turn it on, so the default loses data quietly.
A workflow built on twenty connectors is portable in theory and not in practice. That can be an acceptable trade. It should be a stated one.
Azure integration taken through to production: CRMs, finance stacks, databases, SaaS estates and legacy applications that were never designed to talk to each other - along with the Azure migration and data engineering that usually arrive with it. Bounded, scoped and quoted before anything starts.
Two engagements from the delivery record, both as a contract consultant inside the client's own programme:
Integration and data-migration consultant for a global energy-trading firm connecting its trading systems and moving off legacy platforms.
Azure and integration consultant for an infrastructure services group weighed down by manual finance reporting and disconnected legacy systems.
Where the shape of the integration is already clear, that is a delivery engagement. Where it is not - where the component choice, the volumes or the failure behaviour are genuinely open - a bounded investigation answers those questions first, and it is bought only where that uncertainty prevents a reliable quote. See the production delivery route
If the estate already exists and the question is whether it will hold, a separate review answers that one: one workload judged against all five Well-Architected pillars, read-only, with a dated readiness recommendation. You keep the launch decision, and remediation is quoted separately. The Azure Well-Architected Review in full
An independent view of Microsoft's Azure Integration Services. DBHQ is not affiliated with, endorsed by, or certified by Microsoft. Product names, tiers and billing models are Microsoft's and they change - check the current documentation before committing to a design.
Describe what has to connect to what, the volumes involved and the failure you cannot tolerate. You will get a straight answer on which component fits and whether the work is ready to quote.
I reply within 24 hours