Self-service iPaaS sells build-time productivity. Your team gets a platform, a connector library, and the ability to build integrations faster than it could by hand. That part works. The licence says nothing about who watches those integrations afterwards, who repairs them when an endpoint changes, and who answers to the business when a failed integration stops a process that depends on it.
Moving to a managed service transfers that operating burden to a provider under a service commitment, and the service brings its own integration infrastructure with it. The destination is an estate you no longer license, administer or staff, which is where the reduction in total cost of ownership comes from. Your existing platform keeps running while the flows move across, so the change happens in waves. This article covers why teams make the move, the phases it runs through, who is responsible for what afterwards, and how long it takes.
Key takeaways
- Self-service iPaaS gives your team a better place to do integration work. The work, and the accountability for it, stays with your team.
- The platform vendors' own research shows the gap: enterprises now run 957 applications with 27% of them connected, while IT spends 36% of its time building custom integrations. Capable tooling has not closed it.
- Transition moves accountability integration by integration, in waves. For a period both parties are staffed on the same work, and that overlap belongs in the business case.
- The saving is a total cost of ownership saving and it lands at renewal. Once the flows run on the provider's infrastructure, the platform licence, the administration and the internal operating cost all leave the run rate, so the transition should be scheduled backwards from your renewal date.
For the operating model behind managed integration services, the Integration Ops book covers lifecycle phases, ownership patterns, and playbook examples in depth. Download it free.
Why teams move away from self-service iPaaS
The iPaaS pitch is a build-time pitch, and on its own terms it is accurate. Connectors, a visual mapper, reusable patterns, governance tooling. A team that has been hand-coding point-to-point connections will build faster on a platform than without one.
What the pitch leaves out is everything after the build. Turning a built integration into a working one, over the years it needs to keep working, remains with whoever owns the platform account: the monitoring, the repairs, the changes, and the accountability when a failure disrupts the business.
The evidence sits in the platform vendors' own research
MuleSoft surveys IT leaders annually. Its 2026 Connectivity Benchmark, based on 1,050 IT leaders, reports that the average enterprise manages 957 applications with 27% of them connected, and that IT teams spend 36% of their time designing, building and testing custom integrations. The 2025 edition reported 897 applications, 29% connected, and 39% of time.
The estate grew, the connected share fell, and time spent barely moved. Two decades of increasingly capable platforms have produced an environment where roughly three quarters of applications remain unconnected and integration still consumes more than a third of IT's time. The constraint those numbers describe is operating capacity. The products are good, and the hours available to run what they build are not there.
The failure pattern is consistent
Four things happen after a self-service platform lands, and they happen in roughly this order.
The backlog does not move. The platform arrives, two or three people are trained, and the same team that was already at capacity now owns a new tool as well as the work. Building faster helps only if somebody has time to build.
One engineer becomes the integration department. Platform knowledge concentrates in whoever used it most. That person becomes the escalation path for every flow, and the documentation lives in their head. This is the single most common finding in a transition inventory.
The cost arrives after the licence. Build is the visible number. Operation, incident response and change recur annually for the life of every connection, and they land on payroll, where the platform invoice never shows them. Our breakdown of the true cost of enterprise integrations sets out the full stack, and consumption-priced tiers add a second problem, because the bill grows in proportion to how well the integrations are working.
Nobody is contractually on the hook when an integration fails. A platform service level covers platform availability. An integration failing because a partner changed a field, or because a certificate expired, or because a customer migrated their service desk, is yours to fix. And while your team firefights, the disruption does not stay inside IT: the process the integration carries has stopped, orders or tickets queue, customers feel the delay, and any service level penalty or renewal risk that follows sits with you.
That last point decides most evaluations: who runs it, who fixes it when it breaks, and who is accountable for the outcome, not just for platform uptime.
Self-service describes who operates the platform
This distinction is what makes the move practical. "Self-service" describes who operates the platform, which is a separable question from which platform you own. A managed service takes the operating half and leaves the technology in place. This is sometimes called managed iPaaS, meaning the outcomes the platform promises, delivered as an operated service with a commitment attached. Our explainer on managed iPaaS covers the model, and our answer page on managed integration services against DIY integration platforms makes the comparison directly.
Self-service remains the right answer for some estates, and the conditions are set out at the end of this article. Where it stops working is where the estate is large, the change rate is continuous, external parties are involved, and the internal team is already the constraint.
What moving to a managed service actually involves
It involves transferring responsibility for monitoring, incident response, change, and service level commitment on a defined set of integrations to a provider, while the customer retains ownership of the business logic, the endpoint systems, and the decisions about what the integrations should do. The service includes the integration infrastructure, so the end state is an estate where the customer no longer operates a platform of their own.
That definition rules out the assumption that derails most evaluations, which is that any of this has to happen as a single cutover. Accountability transfers before infrastructure does, integrations move in waves, and the existing platform stays live underneath until the flows that depend on it have gone.
If you are still choosing a delivery model, our comparison of system integrators, iPaaS consultants and managed integration services covers that question, and our analysis of when the project model breaks for integration work covers the case for changing model at all.
Why this is not a replatforming project
Two things get confused at this point, and the confusion is what keeps organisations on a platform they have already outgrown. Replatforming yourself means moving integration logic from one platform your team operates to another platform your team operates. One iPaaS solution which sells migration tooling describes a realistic migration of several hundred workflows as a six to twelve month project, because accumulated field mappings, error handling, retry logic and conditional routing sit in proprietary formats documented across internal wikis and institutional memory. That estimate is credible, and it is the main reason teams stay where they are.
Moving to a managed service is a different exercise, because your team is not the one doing the rebuilding. The provider brings the integration infrastructure and takes the flows across in waves, on a schedule set by criticality and by your licence renewal date, while everything not yet moved keeps running where it is. The work that makes replatforming a multi-quarter project still has to happen. It happens on the provider's side, under a service commitment, priced into a subscription that your engineering capacity no longer has to fund.
That difference also explains the order of the phases below. Accountability moves first, because it produces value within weeks. Infrastructure follows, because that is what takes cost out.
The six phases of an integration operations transition
The model below is compatible with the SIAM roadmap stages of Discovery and Strategy, Plan and Build, Implement, and Run and Improve, and with the knowledge transfer, shadowing and reverse-shadowing ladder that ISG documents for managed services transitions generally. The phase names are deliberately plain verbs, because each one describes a change in who is accountable.
Two features of this model are counter-commercial and both are deliberate. Phase 0 comes first, before any onboarding work. And phase 3 is separated from phase 4, so that accountability transfers on its own timetable and the reader can see exactly which phase delivers reliability and which one delivers the cost reduction.
Who does what after transition
The clearest analogue is the shared responsibility model used in cloud, where the provider is responsible for the infrastructure and the customer is responsible for what they run on it. The equivalent framing for integration is responsibility of the integration layer against responsibility in it.
Using the standard RACI convention, where R is the party doing the work and C is consulted:
The customer keeps the business layer
The provider takes the operating layer:
The contested layer, which is where deals go wrong:
That last row deserves emphasis. Cloud shared-responsibility models carry the same caveat, which is that responsibility shifts back wherever the customer self-provisions. If your developers keep building flows directly on the platform after transition, accountability for those flows sits with you and the service level does not cover them. Any provider who does not say this in advance is setting up a dispute.
What happens to your team
Usually less than people fear, and the legal position depends on how dedicated the staff are. Under UK and EU transfer of undertakings rules, protection applies to employees who can be clearly identified as providing the service being transferred. In most enterprises, integration work is a fraction of several people's jobs and nobody's whole role, so those rules typically do not apply and nobody transfers employer. What changes is what those people work on.
There are two real losses worth naming. The engineer who was the single point of knowledge loses a form of status, and that needs a conversation with them personally. The organisation also loses some optionality, because reversing the decision now takes a termination assistance period.
There is also a gain that runs against the usual expectation. Whitelane Research's European IT sourcing study found that the leading reason organisations bring work back in-house is retaining their own key knowledge, cited by 53% of respondents. A transition done properly produces the opposite. Phase 1 usually generates the first complete, accurate inventory of the integration estate the organisation has ever held, and that documentation should be contractually customer-owned.
What happens to your platform licence
It stays for a while, and coming out of it is the point of the exercise. Integration platform licences are term subscriptions, commonly metered on cores or virtual cores with separate treatment for production and pre-production environments. Changing who operates the platform on day one does not change what you have contracted to pay for it, so the saving does not appear in month one. It appears at renewal, once the flows have moved onto the provider's infrastructure in phase 4 and the consumption behind the licence has genuinely fallen.
That gives the transition its sequencing rule. Plan backwards from the renewal date. Move accountability, absorb the flows, measure actual consumption, then reduce or exit the licence. Cutting capacity before phase 4 completes is a reliable way to create an outage, with a stopped business process attached to it, that then gets attributed to the transition.
The licence is also the smallest part of what leaves. Platform administration, monitoring, incident response and change work go with it, and those sit in payroll where they are harder to see and larger than the subscription. Our breakdown of the true cost of enterprise integrations, linked above, sets out the full stack.
What happens if you want to leave
This should be settled at signature, which is why it sits at phase 0. Termination assistance periods in real outsourcing contracts commonly run from 90 days to one year. Below 90 days is thin for anything operationally significant. The period matters less than the artefact list attached to it. That list should name source flows and configuration, field mappings and transformation logic, the credential inventory, runbooks, monitoring and alerting configuration, and incident history.
It is also worth distinguishing two kinds of dependency. Platform lock-in is technical and expensive to unwind, on the six to twelve month scale described above. Operator lock-in is contractual and unwinds within the termination assistance period. The second is a materially cheaper dependency than the first, and that difference is the actual argument for changing the operator and leaving the platform alone.
How long it takes and what it costs
ISG's analysis of managed services transitions puts a typical transition at five to six months, costing three to four percent of total contract value, with provider staffing coverage rising from over 50% during knowledge transfer to over 75% during shadowing and 100% at reverse-shadowing. ISG also notes that roughly for every managed services deal that goes without issue, another goes poorly.
Two things follow for planning. Integration operations transitions sit at the shorter end of that range because the scope is narrower than a full IT tower. And the staffing ladder is the real cost driver, because for several weeks both parties are funded on the same work. That period belongs in the business case, and it usually surfaces in month two instead.
Treat any claim of a 30 to 60 day enterprise transition with caution. It is common in marketing material for smaller managed IT services and it is several times faster than the only analyst benchmark available.
When this is not the right choice
If your integration estate is small, stable, internal, and already documented, a transition adds governance overhead without removing much work. If integration is genuinely a differentiator for your organisation and you want the capability in-house, keeping it is a defensible strategic decision. And if you are mid-way through a platform migration, finish or stop that first, because running a migration and a transition simultaneously makes attribution of any failure impossible.
The case strengthens with estate size, the number of external parties involved, the rate of change in connected systems, and the degree to which the internal team is already the constraint. Our guide to which IT services should be outsourced covers the wider decision.
Bottom line on moving integration operations to a managed service
The move is a transfer of accountability that happens integration by integration, on a schedule of waves with no single go-live date. Reliability improves as soon as the escalation path stops pointing at your team, and the business feels that before IT does, in processes that stay up and customers who stop noticing. Cost comes out later, when the flows sit on the provider's infrastructure and your own licence, administration and operating effort leave the run rate.
Three things determine whether it works, and all three are decided before onboarding starts. Exit terms written at signature. A phase 1 inventory honest enough to change the scope if it needs to. And a responsibility split that names the contested items explicitly, including who owns flows your own developers build after go-live.
Everything else is scheduling, and the schedule should run backwards from your platform's renewal date.
Not sure where your integration layer stands? The Integration Ops maturity assessment gives you a structured read on ownership, monitoring, and change readiness across your estate.
