If you're deciding how to connect your business systems, you've probably already read a few guides on the topic — and noticed they tend to reach the same conclusion: buy the platform the author happens to sell. That's the quiet problem with iPaaS vs custom integration as a topic. Nearly every article ranking for it is written by an iPaaS vendor or an agency pitching its own product, so the "balanced comparison" leans, gently, toward whatever pays the author.
We at Craftware don't sell an iPaaS license. As a Microsoft Solutions Partner with 20+ years building B2B integrations, we get paid for the integration outcome — not for locking you into a platform — so we can give you the straight version. This guide lays out an honest framework across cost, control, maintenance, scale, and lock-in, and it names a third option the vendor-written guides almost never mention: the Azure "managed middle."
iPaaS vs. Custom Integration: The Honest Answer
Short version: iPaaS — an integration platform you subscribe to — is the fastest, cheapest way to start when you're connecting common SaaS apps with a small team. Custom integration — code built to your exact spec — costs more upfront but wins when your logic is unusual, your volume is high, or you need to own the result. And there's a third path most guides skip: a vendor-managed platform that still runs your own custom logic, which for Microsoft-centric companies is often the best fit of all.
Here's what the search results won't tell you: of the top guides on this subject, the large majority are published by companies that sell one side of the debate. That doesn't make them wrong, but it does mean the conclusion was written before the comparison. Because our business is the integration itself, we can walk the trade-offs without a thumb on the scale — then tell you which one actually fits your situation.
What Each Approach Actually Is
Two plain-English definitions before the comparison — plus a one-line preview of the third option.
What Is iPaaS?
iPaaS stands for integration platform as a service: a cloud subscription platform — Boomi, Workato, MuleSoft, Celigo, and others — that gives you prebuilt connectors, a visual workflow builder, and hosting, all managed by the vendor. You configure integrations instead of coding them from scratch, and the vendor keeps the platform running and patched. In Microsoft terms, lighter tools like Power Automate sit in this same "buy a platform" family for simpler workflows. This is the "buy" in a build vs buy integration decision.
What Is Custom Integration?
Custom integration means writing bespoke code — APIs, middleware, and services built specifically around your data model and your systems, rather than fitting your process into a platform's templates. You (or a partner) build it, you host it where you choose, and you own the result outright. This is the "build" side, and some teams frame the same decision as iPaaS vs custom development or iPaaS vs custom code.
And the Third Path: The Azure "Managed Middle"
Between "rent a whole platform" and "build and run everything yourself" sits a category almost no comparison names: vendor-managed infrastructure that still runs fully custom logic. On the Microsoft stack, that's Azure Integration Services — and because it reshapes the whole decision, it gets its own section below.
iPaaS vs. Custom Integration: The Real Comparison
At heart, comparing an integration platform vs custom integration is a build vs buy integration decision, and it turns on six or seven dimensions. Here's the honest head-to-head, with no thumb on the scale.
Table: iPaaS vs custom integration across cost, speed, control, maintenance, scale, and lock-in.
| Dimension | iPaaS (buy a platform) | Custom Integration (build it) |
|---|---|---|
| Cost model | Recurring subscription; scales with connectors, task/data volume, and premium features | One-time build cost, then ongoing maintenance (often budgeted as a percentage of build cost per year) |
| Time-to-value | Fast — days to weeks for standard connectors | Slower — weeks to a few months, depending on complexity |
| Control & flexibility | Bounded by the platform's connectors and logic model | Unlimited — built to your exact spec |
| Maintenance | Vendor patches the platform and updates its connectors | Your team or partner updates it when APIs or systems change |
| Scalability & volume | Strong for typical volumes; premium tiers and costs kick in at high throughput | Engineered to your volume ceiling; you own the scaling decisions |
| Security & governance | Inherits the vendor's certifications; your data flows through their platform | You design the security model; data can stay inside your environment |
| Vendor lock-in | Higher — connectors, mappings, and workflows live in the vendor's platform | Lower platform lock-in; you own the code (but carry the upkeep) |
| Best fit | Many standard SaaS apps, small team, speed over deep control | Unusual logic, high volume, systems with no good connector, need to own it |
A few honest caveats the table can't hold. "Fast" iPaaS setup assumes a solid prebuilt connector exists for your systems — when it doesn't, the "quick" option quietly becomes a custom project inside the platform. "Higher upfront" custom cost is real, but it's mostly a one-time number, whereas the subscription recurs every year and tends to climb as you add connectors and volume. And neither column is "better" in the abstract — the right answer depends on where your specific integration lands on these rows today, and where it's headed.
The Third Option Nobody Mentions: The Azure "Managed Middle"
Ask most "iPaaS vs custom" guides about a middle path and they'll wave at "hybrid" — use some of each. That's fine advice, but it misses a genuine third category: a platform where the vendor runs the infrastructure and you still write your own integration logic. On the Microsoft stack, that's Azure Integration Services.
Per Microsoft's own documentation, Azure Integration Services is a family of services that work together:
- Azure Logic Apps — visual workflow orchestration across cloud and on-premises systems
- Azure API Management — publish, secure, throttle, version, and govern your APIs
- Azure Service Bus — enterprise-grade messaging to decouple systems reliably
- Azure Event Grid — event routing for reactive, event-driven designs
- Azure Functions — serverless custom code for the logic no connector covers
- Azure Data Factory — managed data movement and transformation at scale
Microsoft hosts, patches, and scales all of it — like an iPaaS. But you're not boxed into prebuilt connectors: you can drop in custom code with Functions, expose custom APIs through API Management, and take message-level control with Service Bus whenever the standard building blocks fall short. That's why we call it the managed middle — the operational relief of a managed platform and the flexibility of custom code, built on open, well-documented Azure services rather than one vendor's proprietary black box.
Azure Integration Services vs iPaaS: The Key Difference
Put plainly: a proprietary iPaaS is easier to start and harder to leave; the Azure managed middle asks a bit more engineering up front and locks you in far less. It's an especially strong fit if you already run Dynamics 365, Business Central, or Microsoft 365 — the connective tissue then lives in the same cloud as your systems of record, using the same identity and security model. One clarification, since the terms overlap: Power Automate and Logic Apps both appear here, and comparing those two specifically is a narrower question than the category decision we're answering. Here, Logic Apps is one building block of the broader managed-middle approach.
Total Cost Over Time (and the Break-Even)
Sticker price is the wrong number to anchor on. Three cost models are really in play:
- iPaaS: a recurring subscription that scales with connectors, data/task volume, and premium features. Low to start, but it never stops — and it grows as you do.
- Custom build: a larger one-time cost, then ongoing maintenance. A common planning rule of thumb budgets annual maintenance as a percentage of the original build cost — plan for it rather than pretending "done" means "free forever."
- Azure managed middle: a consumption or hosting model. Azure Logic Apps, for example, bills its multitenant Consumption plan per execution and its single-tenant Standard plan as reserved capacity — you pay Azure for what runs, without a proprietary per-connector license markup on top. Confirm current rates on the Azure Logic Apps pricing page before you budget.
There's a reason ongoing cost deserves more weight than the upfront figure. Industry analysts have long found that most of an IT budget goes to running what you already have rather than building something new — Gartner's widely cited work on IT spend typically puts the "run-the-business" share well above half, often around two-thirds, though it varies by organization. Integrations are part of that run cost: whichever model you choose, someone pays to keep it working every year.
An illustrative example (hypothetical numbers, for shape only — not a quote): Say a mid-market company needs to connect Business Central, a CRM, and a shipping system. An iPaaS subscription for that scope might land in the low five figures per year once you add the connectors and volume you actually need. A custom or managed-middle build for the same integrations might be a larger one-time cost plus a smaller yearly maintenance budget. In year one, the subscription looks cheaper. But it recurs — and climbs — every year, while the build's cost is mostly behind you. Somewhere across a multi-year horizon, the cumulative lines cross. Where they cross depends entirely on how many integrations you run, how much data moves, and how long you'll keep the system — which is exactly why the "iPaaS pays back in X months" figures repeated across the web are close to meaningless without your numbers. Model your own.
Lock-In, Honestly
Competitors like to flatten this into a slogan: "iPaaS means lock-in, custom means freedom." Reality is a spectrum, and the managed middle sits right in the useful part of it.
| Proprietary iPaaS | Azure Managed Middle | Fully Custom | |
|---|---|---|---|
| Who runs the infrastructure | The iPaaS vendor | Microsoft (Azure) | You / your host |
| Where your logic lives | The vendor's proprietary platform | Open Azure services, as your own config and code | Your own codebase |
| If you leave | Rebuild connectors and workflows elsewhere | Port code and config; open standards ease the move | You already own it — just re-host |
| Maintenance burden | Lowest — the vendor handles it | Shared — Microsoft runs the platform, you own the logic | Highest — all yours |
| Lock-in level | Highest | Moderate | Lowest platform lock-in |
The trade-off underneath the spectrum is simple: the less lock-in you accept, the more maintenance you take on. A proprietary iPaaS hands you the least upkeep and the most lock-in. Fully custom hands you the most freedom and the most upkeep. The Azure managed middle is the deliberate compromise — meaningfully less lock-in than a proprietary platform, meaningfully less maintenance than rolling everything yourself. For a lot of mid-market companies, that middle is the honest sweet spot.
Which Should You Choose? A Straight Framework
No single answer fits every company. Here's how we actually make the call.
Choose iPaaS When
- You're connecting many standard SaaS apps that have solid prebuilt connectors
- Speed matters more than deep control, and the logic is fairly standard
- You have a small team and want the vendor to own uptime and connector updates
- Your volumes are predictable and moderate
Choose Custom Integration When
- Your workflow has unusual logic no connector models well
- You move high volumes or need tight control over performance
- You must connect a system no iPaaS supports well — a legacy ERP, a niche line-of-business app
- Owning the code and data path is a hard requirement (compliance, IP, or competitive differentiation)
Choose the Azure Managed Middle When
- You're Microsoft-centric — Dynamics 365, Business Central, Azure, Microsoft 365
- You want managed infrastructure and custom logic, without a proprietary platform in between
- Lock-in is a real concern and you'd rather build on open Azure services
- You have — or can bring in — the engineering to set it up; the payoff is lower long-run cost and lower lock-in
A note for the mid-market. Most guides on this topic are written for enterprise architecture teams or startup engineers. If you're a controller, ops leader, or IT director at a company that has outgrown Zapier but can't staff a five-person integration team, you're the buyer these comparisons forget. The honest read for that middle ground: reach for iPaaS when you need something live next month and the apps are standard; reach for the Azure managed middle when the integration is core to how you run and you want to keep long-run cost and lock-in down. When you're genuinely unsure, that's the call worth a second opinion — from someone who doesn't sell the platform.
Frequently Asked Questions
Is custom integration cheaper than iPaaS? It depends on time and volume. iPaaS almost always wins year one — low upfront cost, fast setup. But the subscription recurs and grows with connectors and volume, while a custom build's cost is mostly one-time plus maintenance. Over a multi-year horizon the cumulative lines cross; where they cross depends on your integration count, data volume, and how long you'll run the system. Model your own numbers rather than trusting a generic payback figure.
When should you build a custom integration instead of using iPaaS? Build custom when your logic is unusual, your volumes are high, you need to connect a system no iPaaS handles well, or owning the code and data path is a hard requirement. If you're mainly wiring together common SaaS apps, iPaaS — or the Azure managed middle — usually gets you there faster and cheaper.
What is Azure Integration Services, and how is it different from iPaaS? Azure Integration Services is Microsoft's family of integration services — Logic Apps, API Management, Service Bus, Event Grid, Functions, and Data Factory. Like an iPaaS, Microsoft manages the infrastructure. Unlike a proprietary iPaaS, you can run your own custom code and APIs on open Azure services, which means more flexibility and less lock-in. We call it the "managed middle."
What's the difference between iPaaS and API management? They solve different problems. iPaaS connects apps and moves data between them — integration and workflow. API management publishes, secures, throttles, versions, and governs APIs; it's the front door to your services, not the plumbing between them. Azure API Management is one component within Azure Integration Services, and many architectures use both together.
What happens to a custom integration if a vendor changes their API? Someone has to update the integration to match — that's the maintenance trade-off of owning it. With iPaaS, the vendor typically updates its managed connector for you. With custom code or the Azure managed middle, your team or partner makes the change. It's very manageable with a maintenance plan in place; the real risk is having no one watching for the change in the first place.
Is a custom integration overkill for a small or mid-sized company? Often, yes — if you're connecting standard apps, iPaaS or the Azure managed middle is usually the smarter start. Custom earns its place when the integration is central to how you operate, the logic is genuinely unusual, or you're hitting the limits of what a platform will do. The point isn't "custom is better" — it's matching the approach to the job.
Get an Honest Recommendation
Most "iPaaS vs custom integration" guides end by recommending the author's own product. We'll end differently. Tell us what systems you're connecting, your volumes, and your team, and we'll tell you whether iPaaS, custom, or the Azure managed middle actually fits — with a plain-English cost picture and a straight read on lock-in. Because we at Craftware don't sell an iPaaS license, the recommendation is the product. Book a free consultation and get an honest answer before you commit budget in any direction.
