Insights

Before You Scale AI Agents, Govern the Ones You Can't See

Amber — Tue, 04 Aug 2026 08:20:32 GMT

Every AI agent is a non-human identity acting on your behalf. Give it the keys before you've decided what it's allowed to touch, and you've built your next incident.

AI is the push right now — from the boardroom, from your platform vendors, from us. And the promise is real: agents that reach into your systems, act on your behalf and get work done without a human in every loop. 🤖

But there's a quiet truth underneath the excitement. An AI agent is only as useful as the systems it can safely reach — and every agent you deploy is a non-human identity acting on someone's authority. If you're scaling agents faster than you're governing the identities behind them, you're not scaling capability. You're scaling exposure. Let's unpack it. 👇

🔑 The thing nobody's putting on the slide

For years, "identity" meant people — usernames, passwords, access reviews. That model quietly stopped being the whole picture. Every integration, every service account, and now every AI agent is an identity that can read, write and act across your estate. They already outnumber your human users, often many times over.

Most organisations govern the human identities carefully and the non-human ones barely at all. Agents make that gap urgent, because an agent doesn't just hold access — it decides how to use it, at machine speed, in situations you didn't script.

📡 Sound familiar?

You don't need a security review to know the gap is there. You can hear it:

What you're saying	What it's really telling you
"Let's give the agent broad access so it can be useful."	Convenience is about to become your blast radius.
"We're not totally sure what that service account can reach."	You have ungoverned non-human identity already — before any AI.
"The agent worked in the demo."	Demos don't have adversaries, edge cases or a Monday.
"Security will look at it before we go live."	Governance is being discovered late, under deadline — the expensive way.
"We'll tighten permissions once it's proven."	Permissions granted broadly are almost never walked back.

🔒 What good looks like

You don't govern AI agents with a policy document. You govern them by building the foundation before you scale — the same foundation good integration needs anyway.

Give every agent a scoped identity. Not a shared, all-powerful account. Each agent gets its own identity with the narrowest access that lets it do its job — and nothing beyond it.

Decide what it's allowed to reach, in advance. Before an agent goes near production, decide which systems, data and actions are in bounds. Design it in; don't discover it under incident pressure.

Route agents through a governed layer, not straight into systems. When agents reach the business through a governed integration platform rather than bespoke point-to-point access, you get one place to see, control and revoke what they do. Governance becomes a property of the architecture, not a promise.

Log and monitor non-human activity like it matters — because it does. You want to answer "what did this agent do, and was it allowed to?" instantly, not during a post-mortem.

Do this and something useful happens: it's one migration, not two. The governed platform that makes your integration reusable is the same platform that makes your AI agents safe to scale. Build it once.

Give an agent broad access because it's convenient, and you haven't deployed a capability. You've pre-authorised your next incident.

🤔 "But what about…" — two honest answers

"This sounds like it'll slow the AI push down." It's the opposite. The thing that actually stalls AI programmes is the security review that lands late and sends everyone back to the drawing board. Govern identity up front and you go faster, because there's no rework and nothing to defend after the fact.

"We just want to experiment — isn't this overkill for a pilot?" Experiment freely in a sandbox with no real access. The discipline only has to be there before an agent touches production data or takes real actions. That line is the one worth holding.

✅ Where to start

You don't need an enterprise AI governance programme to begin. You need to see what's already ungoverned and put one agent on rails:

🎯 Inventory the non-human identities you already have — service accounts and integrations included. Most teams are surprised.
🔐 Pick the first agent use case and decide, up front, exactly what it's allowed to reach.
🚀 Route it through a governed layer and prove the model before you scale to the next.

This piece reflects integration and security delivery experience; specific controls should be mapped to your own risk, regulatory and platform context.

🤝 The ask is a short, bounded look at your non-human identities and your first agent use case — what's already exposed, and what it takes to scale AI without scaling risk alongside it.

SAP Without the Spaghetti

Amber — Tue, 04 Aug 2026 08:18:59 GMT

When to reach for Workato, when to reach for SAP BTP, and how to stop your SAP core becoming an island — or a knot.

SAP tends to sit at the centre of everything and connect to it badly. Finance, HR, CRM, the warehouse, your partners — all of it needs to talk to the core, and most of the time it does so through a tangle of brittle, hand-built links that break whenever anything changes. 🍝

The instinct is to reach for whatever integration tool is nearest and start wiring. The better question is: which tool, for which job? Because the answer isn't "always Workato" or "always SAP BTP." It's both, used deliberately. Let's unpack it. 👇

🧭 The one rule: the platform follows the estate

Here's the principle that keeps you out of trouble. You don't pick the platform and bend the estate to fit it. You look at what the integration actually is, and let that decide the target. Get that backwards and you'll force SAP-to-SAP work through a general-purpose tool, or push your whole enterprise estate through an SAP-shaped lens — and both hurt.

So here's the split we use.

🔗 When to reach for Workato

Workato earns its place when the integration crosses the boundary of the SAP world — which is most enterprise integration.

SAP to non-SAP. Orders flowing to a CRM, HR data syncing to a benefits provider, finance talking to a warehouse. Anywhere SAP meets the rest of your estate, you want a governed orchestration layer that speaks both languages.
Automation and process, not just data movement. When the job involves logic, approvals, human steps or AI, not just moving a record from A to B.
Reusability across the estate. When you want the pattern you build for SAP to be reusable everywhere else, on one governed platform your team owns.

🏢 When to reach for SAP BTP Integration Suite

BTP earns its place when the work is genuinely inside the SAP family.

SAP-to-SAP. S/4HANA to SuccessFactors, Ariba, Concur — where the integration lives entirely within SAP's own world and benefits from native content and support.
Deep SAP semantics. When you need SAP's own APIs, events and data models handled with first-class fidelity rather than translated.
SAP-managed roadmap alignment. When staying inside SAP's supported patterns matters for support, upgrades and compliance.

🗺️ The quick decision guide

The integration is…	Reach for	Because
SAP to CRM, HR, finance, warehouse, partners	Workato	It's enterprise orchestration — you want one governed, reusable layer.
SAP to SAP (S/4, SuccessFactors, Ariba, Concur)	SAP BTP	Native content and semantics; stay inside the SAP family.
Automation, approvals, AI on top of SAP data	Workato	It's process and logic, not just data movement.
Deep SAP events and data models, high fidelity	SAP BTP	First-class SAP handling beats translation.
Not sure / mixed landscape	Talk it through	The estate decides — map it before you wire it.

🤔 "But what about…" — two honest answers

"Can't we just standardise on one and be done?" You can, and plenty do — then spend years fighting the mismatch. A single tool for everything means either forcing SAP-native work through a general layer or dragging your whole estate into an SAP-shaped one. Using both deliberately is less work, not more.

"Aren't you just going to sell us Workato?" We're a Workato partner and an SAP integration partner — which is exactly why we'll tell you when BTP is the right home for a piece of work. Where it's genuinely SAP-to-SAP, it goes to BTP. The target follows the estate, not our licence.

✅ Where to start

You don't need to re-platform your whole SAP landscape. You need to see the shape of it and pick the first knot to untie:

🎯 Pick the SAP integration that breaks most often, or blocks the most.
🗺️ Decide, honestly, whether it's SAP-family work or enterprise work — that names the platform.
🚀 Build a clean, governed single source of truth around the core, and retire the fragile link it replaces.

Guidance reflects integration-platform and SAP delivery experience; the right split depends on your specific landscape and roadmap.

🤝 The ask is a short look at your SAP landscape: what's connected, how brittle it is, and which work belongs on Workato versus BTP. It's the cheapest way to stop the spaghetti before it sets.

The Four Decisions That Decide Your ESB Migration

Amber — Tue, 04 Aug 2026 08:17:10 GMT

A migration isn't a checklist of things to rebuild. It's four decisions — and if you take them well, everything you build afterwards gets cheaper.

We've said it before: an ESB migration isn't a moving job, it's a design job. But "design job" can sound abstract when you've got four hundred integrations and a renewal date bearing down. So here's the concrete version. A good migration comes down to four decisions, taken deliberately and up front — not four hundred tasks, taken by whoever picks up the ticket. 🧭

Get these four right and the migration pays you back. Skip them and you've paid the whole budget to arrive exactly where you started. Let's take them one at a time. 👇

🧹 Decision one — what should exist at all

Most old estates carry integrations that are dead, duplicated or redundant — roughly a fifth to a third of the typical estate — because nobody ever had the authority to switch anything off. So they just kept running, and kept getting migrated, decade after decade.

The first decision is the cheapest and the most ignored: decide what to retire before you rebuild anything. Every flow you retire is a flow you don't design, don't test, don't run and don't pay for. This is money released before a single new integration is built — and it shrinks the scope of everything that follows.

Rebuilding four hundred old processes as four hundred new recipes isn't modernisation. It's the same estate with a new logo.

🗺️ Decision two — what shape it should be

The old estate encodes years of compromises: things done as overnight batch because that's all the platform allowed, boundaries drawn where a team happened to sit rather than where the business actually splits.

A like-for-like rebuild copies those compromises faithfully — and with more confidence, because the platform is shiny and new. The second decision is to decide the shape deliberately: which flows are genuinely event-driven, which are batch, where the boundaries belong, what your single source of truth is for each core entity. Decide it once, while you're touching everything anyway, and you get an estate you can change quickly later instead of one you've inherited.

🔐 Decision three — who is allowed to do what

Here's the one that gets discovered under incident pressure if it isn't decided up front. Every integration is a non-human identity acting on someone's behalf, and the security model that worked on-premises doesn't survive the move to cloud.

The third decision is to design the security posture in advance: what each integration is allowed to reach, how identity and secrets are handled, what's logged and monitored. Do it ahead of the cut and it's a posture your security director can defend. Do it afterwards and you're doing architecture in the middle of an incident — the worst possible time.

🏗️ Decision four — how you build from now on

Modern platforms make building easy. That's the trap. An ungoverned estate on a modern platform sprawls faster than the mess it replaced, because there's nothing slowing the sprawl down.

The fourth decision is to put the patterns in the cupboard and the rules inside the patterns — before the team starts building at speed. Decide the reusable patterns, bake the standards into them, and the new platform accretes value instead of mess. This is the decision that makes every future build cheaper than the last, which is the entire point of migrating.

📋 The four decisions, at a glance

The decision	Why it changes the outcome
🧹 What should exist at all	Retire the dead and duplicated first — money released before anyone builds a thing.
🗺️ What shape it should be	Decide event-driven vs batch and where boundaries sit, so you don't faithfully copy old mistakes.
🔐 Who is allowed to do what	Design security in advance, or discover it afterwards under incident pressure.
🏗️ How you build from now on	Patterns in the cupboard, rules in the patterns — so the new platform doesn't accrete the same mess.

✅ Where to start

You don't have to take all four across the whole estate on day one. You take them once, on one thing, and prove the model:

🎯 Pick the single integration or renewal that hurts most right now.
🧾 Run the four decisions against just that one — what to retire, what shape, what security, what pattern.
🚀 Prove it works before you scale the model across everything else.

Figures cited draw on published industry research and integration-platform experience; they're directional rather than guarantees, and results vary by organisation.

🤝 The ask isn't a demo or a proposal. It's a short, bounded look at your estate and the four decisions in front of you — cheap, easy to say yes to, and the first real piece of the work whichever way you go next.

You Bought the Platform. Why Isn't It Delivering?

Amber — Tue, 04 Aug 2026 08:15:37 GMT

Most stalled Workato programmes didn't pick the wrong tool. They're just working in the wrong shape — here's how to unstick one.

Here's a pattern we see again and again. An organisation does everything right: builds the business case, runs a proper evaluation, buys Workato, stands up a small team. Twelve months later the platform is live, a handful of recipes are running — and the value the board was promised is nowhere to be seen. 🤔

If that's you, the first thing worth saying is this: it's almost never the technology. Workato is doing exactly what it was built to do. The programme has been challenged by something quieter and more fixable — the shape the work is happening in.

Let's unpack it. 👇

🧭 The platform was never the hard part

Buying an iPaaS solves the easy problem. The hard problems are the ones no licence includes: how demand gets captured, how you decide what's worth building, who's allowed to build it, and how you show the value once it's live. Skip those and you don't get a capability — you get a very capable tool that nobody has taught the organisation how to use.

A stalled programme usually isn't short of technology. It's short of a way of working.

📡 Sound familiar?

You don't need a diagnostic to know a programme has stalled. You can hear it in the language:

What you're saying	What it's really telling you
"We've built some things, but I can't point to the value."	No value-first intake — work got built before anyone qualified whether it was worth it.
"Requests come at us from everywhere and we can't prioritise."	No triage. Demand is arriving unqualified and the team is drowning in it.
"The team isn't confident building without help."	An enablement gap, not a talent gap — the patterns and guardrails were never set.
"Every request feels like it's starting from scratch."	Nothing reusable in the cupboard. Each build costs what the last one cost.
"Leadership is starting to ask what we're getting for it."	The clock is running. This is the moment to fix the shape, before confidence goes.

🔧 What actually unsticks it

The fix isn't more recipes. It's putting a repeatable rhythm around the platform you already own. Four moves do most of the work:

Put value at the front door. Every request gets a quick value check before anyone builds — a light one for simple, repeatable asks, a fuller discovery for anything significant. You stop spending scarce capacity automating broken processes or work a strategic fix would soon replace.

Make triage and estimation boring and consistent. A structured path from raw request to a defensible, day-based estimate with clear resourcing, ranked on a simple value-versus-effort matrix. Prioritisation stops being a negotiation and starts being a decision the business trusts.

Give the team the cupboard, not just the tool. Reusable patterns with the rules built in, so builders stop reinventing plumbing and start shipping safely and fast. This is how confidence returns — it's a shape problem, not a skills problem.

Run it on a rhythm. Intake, Design, Build, Run — tied into your existing governance rather than bolted beside it, with a demand SLA, peer review and a backlog that feeds planning. An operating cadence, not a pile of tickets.

We frame all of this on the GEARS lens — Govern, Enable, Adopt, Run, Scale — so the capability compounds instead of plateauing.

"A stalled programme is rarely a broken tool. It's a good tool waiting for a way of working."

🤔 "But what about…" — three honest answers

"We already have a team — doesn't this just replace them?" The opposite. This makes them the owners, not the bottleneck. We set the direction and stock the patterns so they build faster and safer. We grow your capability, never a dependency on us.

"We can't afford to stop and re-plan." You're not stopping — you're changing the shape while the work continues. The first value check pays for itself the moment it kills one low-value build you were about to fund.

"Isn't it too late? We're a year in." It's a better time to talk, not a worse one. Ask one question: is the next integration going to be cheaper to build than the last one? If the answer isn't a confident yes, the shape is the problem — and the shape is fixable.

✅ Where to start

You don't need to re-launch the programme. You need one honest look and one first win:

🎯 Pick the request queue that's causing the most friction right now.
🧾 Put a value check and a simple triage in front of it.
🚀 Prove the rhythm on that one flow before you roll it across everything.

Figures and frameworks referenced draw on integration-platform delivery experience and published industry research; they're directional rather than guarantees, and results vary by organisation.

🤝 The ask isn't a rebuild or a big proposal. It's a short, bounded look at where your programme has stalled and what it would take to get it moving — the first genuine piece of the work whichever way you go next.

Stop Paying to Keep the Lights On

Amber — Tue, 04 Aug 2026 08:13:12 GMT

Why a fractional Enterprise Architect is the smartest hire you'll never make full-time.

Here's an uncomfortable number to start with. Most organisations spend 60–80% of their IT budget just keeping old systems running — not building anything new, not delighting a single customer, just holding the past together with tape and goodwill. 🔦

If that stings a little, good. Because it means the biggest opportunity in your business probably isn't a new product or a new market. It's the money you're already spending, trapped in the plumbing between your systems, quietly leaking value every single day.

The good news: you don't need a small army of architects on the payroll to fix it. You need the right thinking, at the right moments, sized to what you need. That's what a fractional Enterprise Architect does. Let's unpack it. 👇

🧾 The hidden tax on every ambition

Every organisation is trying to change — a new ERP, a merger, a modernisation push, a growth spurt. And nearly everyone hits the same invisible wall: their systems don't talk to each other cleanly.

It rarely shows up as a line item. Instead, it hides in plain sight as a hundred small frustrations:

The same customer or job number lives in five systems — and no two agree. 🤷
Every new integration is hand-built, brittle, and takes months. ⏳
A legacy system nobody fully understands has quietly become mission critical. 😬
Your best people spend their week firefighting instead of building. 🔥

This is the tax you pay for fragmentation. And because it's spread across dozens of budget lines, most organisations underestimate it by 40–60% — which is exactly why leaders feel the pain long before they can name it.

🧭 What a fractional Enterprise Architect does

Think of it as senior architecture leadership on demand — the strategic brain of a big-tech transformation team, without the big-tech headcount. The work follows five simple moves:

The move	What it means for you
🧭 Set the North Star	One shared strategy for integration and automation that IT, data and the business all rally behind — no more one-off, point-to-point fixes.
🔍 Choose on evidence	A transparent, rigorous platform evaluation — not a vendor's sales pitch — so leadership trusts both the process and the result.
🏗️ Design once, reuse forever	A secure, event-driven blueprint with a single source of truth and reusable patterns, so future work takes weeks, not months.
🚀 Prove it in production	A real, working integration live in your environment early — value the board can see, not a slide-deck promise.
🔑 Hand over the keys	A lean Centre of Excellence and an upskilled team, so you own the capability and aren't hooked on consultants forever.

The shorthand? A North Star, a governed platform, first value in production, and an in-house capability that keeps compounding — without the cost and lock-in of a big permanent team.

📈 The payoff, in plain terms

Strategy decks are easy to nod along to and easy to forget. So here's what changes when the plumbing gets fixed properly:

⚡ Speed: delivery moves from months to weeks, turning a backlog into throughput.

🔒 Safety: one governed, secure platform replaces fragile hand-built connections — closing audit and pen-test findings.

🎯 Trust: a single source of truth ends duplication and reconciliation, so everyone works from the same number.

💰 Value: enterprise-grade expertise at a fraction of the cost of a permanent team — no idle payroll.

🌱 Ownership: an in-house capability you control, delivering value that compounds long after the engagement ends.

🔢 Don't take our word for it

The evidence for getting integration and architecture right is well established across industry research:

The number	What it tells you
60–80%	Share of IT budgets spent maintaining legacy systems (McKinsey) — money that buys no new value.
20% / 30%	Up to a 20% cut in IT operating cost and a 30% lift in productivity from a mature enterprise-architecture practice (Gartner).
~70%	Reduction in integration build time when moving from hand-coding to a governed platform — the engine behind 'months to weeks'.
380–445%	Three-year ROI reported in independent studies of enterprise integration platforms, driven by faster delivery and redeployed staff.

🏭 The same fix, tailored to your world

Fragmentation looks a little different in every sector — but the cure is remarkably consistent. Wherever you sit, there's a door in:

Sector	The pain they feel	The fix that lands
🏗️ Construction & Energy	Project, cost and vendor data scattered across finance, field service and CRM; ERP rollouts stalling.	A single source of truth and a governed hub around the new core — fast, without a big team.
🛠️ Manufacturing & Retail	Fragile, batch-based links between order, design and installer systems; sign-offs that miss scheduling.	Real-time, event-driven order flows and a safe path to retire fragile legacy.
⚖️ Legal & Professional	Point-to-point integration and per-request data access slowing every matter; strict confidentiality.	A governed, reusable platform with compliance and privilege designed in — no new headcount.
🎓 Higher Education	Automation demand from every department, unqualified and ad-hoc; peaks at Clearing and Enrolment.	A Centre of Excellence with value-first intake, plus surge support for peak periods.
🏦 Banking & Finance	Legacy cores eating the IT budget; integration as the top blocker to launching anything new.	Secure connectivity to legacy without new exposure, and phased modernisation that de-risks change.
📡 Telecommunications	Sprawling estates from years of growth and acquisition; overlapping, duplicated systems.	A reusable, event-driven platform for rapid service change and system consolidation.
🏛️ Government & Public Sector	Most of the budget locked in legacy upkeep; strict security, transparency and probity demands.	Evidence-based, defensible platform choices and governed integration the department owns.

🤔 "But what about…" — three honest answers

"We already have an integration team." Perfect — this makes them faster and safer, not redundant. We set the direction and the reusable patterns so they stop rebuilding plumbing and start shipping. We build their skills, not a dependency.

"We can't take on a big consulting bill." That's the whole point of fractional. You get senior leadership sized to what you need — and it typically pays for itself by shrinking the 60–80% you're already spending on maintenance.

"Why not just rip out the old system?" Big-bang replacements are where budgets and reputations go to die. We phase it — prove value on one real flow, then retire the legacy risk safely, on a clear timeline.

✅ Where to start

You don't need to boil the ocean. You need one honest conversation and one first win. If any of this sounds like your organisation, the next step is simple:

🎯 Pick the single integration or process that hurts most right now.
🧾 Get a clear read on what it's really costing you — the tax is bigger than it looks.
🚀 Prove the model on that one thing, in production, before scaling.

Figures cited are drawn from published industry research (Gartner, McKinsey and independent integration-platform ROI studies) and are directional rather than guarantees; actual results vary by organisation.

💡 The reframe: You don't have a technology problem. You have a connection problem — and connection is the cheapest, fastest lever you have to unlock value you've already paid for.

📌 The line worth remembering: the goal is to move money from maintenance to momentum — and prove it with a real result in production, fast.

🤝 Ready to move money from maintenance to momentum? Let's find your first win — a real result in production — and build a capability your team owns long after we're done.

It's Not a Moving Job. It's a Design Job.

Amber — Tue, 04 Aug 2026 08:10:59 GMT

Your ESB migration is the one chance you'll get this decade to build something better — here's how not to spend the whole budget standing still.

Almost every large enterprise runs on the same invisible thing: integration middleware — the plumbing that moves data between finance, CRM, the warehouse, the bank and your partners. For the last fifteen to twenty years, a great deal of it has run on a generation of platforms called enterprise service buses. MuleSoft and TIBCO are the names you'll hear most; IBM, Oracle, BizTalk and webMethods fill in the rest. 🔌

They were the right choice when they were bought. Holding them in place is what's become the problem: bills that keep climbing, a shrinking pool of specialists who cost roughly double a modern integration engineer, and a central team through whose queue every change has to pass — so a business unit waits eight to twelve weeks, or gives up and builds a workaround.

So you're moving off. And here's the part almost nobody tells you: how you move matters far more than that you move. Get it right and this becomes the best money you'll spend all decade. Get it wrong and you'll pay the whole budget to arrive exactly where you started. Let's unpack it. 👇

🚚 Everyone is selling you a moving job

The whole market is pitching the same thing: take the integrations you have, rebuild each one on the new platform, switch the old one off. Priced per integration and scheduled like a house move. Tidy, familiar, easy to say yes to.

The trouble is that a move doesn't change anything. Every integration you carry across is really a decision — about how that thing should work now, on this platform, in this business, rather than how someone built it in 2011 against a platform that no longer exists. Skip the decision and nothing has been modernised. The old estate has simply been carried over on your back, at enormous cost, and it will need doing all over again.

If that stings a little, good — it's the exact outcome you're paying to avoid.

🗄️ You get one chance to touch everything

Here's the reframe worth holding onto. A migration is the only time an organisation touches every integration it owns. That happens perhaps once a decade. It is the single biggest opportunity you'll ever get to build something reusable — and almost everyone wastes it.

Do it as a translation and you spend the whole budget arriving where you began: on a cheaper runtime, with hundreds of one-off builds and nothing anyone can reuse. Do it as a design job and you come out with a stocked cupboard — the patterns decided, the connections built once, the standards already in place. Everything you build afterwards is cheaper, and you get faster every year instead of slower.

"Re-implementing four hundred old processes as four hundred new recipes isn't modernisation. It's the same estate with a new logo."

🧭 Four decisions that decide it — not four tasks

A good migration isn't a checklist of things to rebuild. It's four decisions, taken deliberately and up front:

The decision	Why it changes the outcome
🧹 What should exist at all	Most old estates carry integrations that are dead, duplicated or redundant — roughly a fifth to a third of the typical estate — because nobody ever had the authority to switch anything off. Deciding what to retire releases money before anyone builds a thing.
🗺️ What shape it should be	Which flows are genuinely event-driven, which are batch, where the boundaries sit. A like-for-like rebuild copies the old estate's mistakes faithfully — and with more confidence, because the platform is new.
🔐 Who is allowed to do what	Every integration is a non-human identity acting on someone's behalf, and the old security model doesn't survive the move to cloud. Design it in advance, or discover it afterwards under incident pressure.
🏗️ How you build from now on	Put the patterns in the cupboard and the rules inside the patterns, so the new platform doesn't accrete the same mess. Modern platforms make building easy — which means an ungoverned estate sprawls faster than the one it replaced.

📈 What changes when you do it right

Strategy is easy to nod along to and easy to forget. So here's what actually changes when the migration is run as a design job:

💰 The estate shrinks before it moves. Retire what's dead or duplicated first, and the migration is scoped against what the business actually uses — money released before anyone builds anything.

🗄️ A cupboard, not a copy. Design the patterns once while you're touching everything anyway, and every build afterwards is cheaper and faster instead of costing what the last one cost.

🧱 An estate that's shaped, not inherited. Decide what's event-driven and where the boundaries sit before anything is rebuilt — so you can change it quickly later.

🔒 Security designed in, not discovered. Decide what every integration is allowed to reach ahead of the cut — a posture your security director can defend, with no architecture done under incident pressure.

🤖 One migration instead of two. Build something your AI agents can actually reach the business through, with every non-human identity governed from the start — ready for the question your board is about to ask.

"You get one chance to touch everything. Spend it building a cupboard, not a copy."

📡 Sound familiar?

You don't need to understand the plumbing to know it's time. If you're saying any of these, the decision is already being taken — the only question is whether it's taken well:

What you're saying	What it's really telling you
"Our renewal's up, and the number has climbed again."	The clearest signal there is. Get the date — almost everything else follows from it.
"Integration is eating our IT budget."	The run cost has reached the board. Rationalisation is the answer that pays back before anything new gets built.
"The people who understood it have left."	An estate nobody can fully explain. Mapping what's actually running is where the work — and the value — starts.
"It takes months to get anything built."	The central queue. A new platform on its own won't fix this, and that's an expensive lesson to learn the hard way.
"We've been quoted — and it's priced per integration."	Someone is selling you a moving job. Ask them what happens to the integrations that should simply be switched off.
"We tried this before and it went badly."	Usually it didn't fail because the technology was bad. It failed because of how it was run — which is fixable.

🤔 "But what about…" — three honest answers

"We already have an integration team." Good — this makes them the owners, not the bottleneck. If their week is a queue of requests, the problem is the shape they're working in, not the people. Set the direction and stock the patterns, and they build safely and fast. The goal is to grow your capability, not a dependency on anyone.

"Isn't there a tool that just converts the flows across?" There is, and some firms sell exactly that. It produces the old estate on new technology — the very thing you're paying to escape. If a converter is genuinely what you want, better to know that early; it's a different job.

"We're already halfway through." Then this is a better time to talk, not a worse one. Ask one question: when this finishes, will the next integration be cheaper to build than the last one was? If the answer isn't a confident yes, you're building a copy — and there's usually a lot of estate still to go.

🧩 "Aren't you just going to sell us Workato?"

Straight answer: we're a Workato partner, and for enterprise integration coming off an old ESB, the target is usually Workato. What we won't do is arrive with the platform already chosen and bend your estate to fit it. The target follows from the estate and from what you decide to keep. Where the work is genuinely SAP-to-SAP it goes to SAP BTP Integration Suite instead, and where you already run something worth keeping, we'll say so. The platform swap is the easy part to sell — the design is the part that pays you back.

✅ Where to start

You don't need to boil the ocean. You need one honest conversation and one first win. If any of this sounds like your organisation, the next step is small:

🎯 Pick the single integration or renewal that hurts most right now.
🧾 Get a clear read on what your estate really costs — what's running, and how much of it could simply be switched off.
🚀 Prove the model on that one thing before you scale it across everything.

Figures cited are drawn from published industry research and integration-platform experience; they are directional rather than guarantees, and actual results vary by organisation.

🤝 The ask isn't a demo or a proposal. It's a short, bounded look at your estate: what's actually running, what can be retired, and what the migration really involves. It's cheap, it's easy to say yes to, and it's the first genuine piece of the work whichever way you go next.

Onshore, Offshore, Hybrid — Choosing Without Trading Away Security

Amber — Tue, 04 Aug 2026 08:08:17 GMT

The delivery model is usually framed as a cost decision. It's really a control decision — and you don't have to pick one and live with it everywhere.

Sooner or later every integration programme runs into the same question: where does the work actually get done? And it usually arrives dressed up as a cost conversation — offshore is cheaper, onshore is dearer, pick your budget. 💰

That framing quietly costs people money and sleep, because it treats the decision as a single lever pulled once for everything. It isn't. The real question isn't "cheap or safe?" It's "which work needs control, and which work needs scale?" — and you can answer that differently for different parts of the same programme. Let's unpack it. 👇

🧭 It's a control decision wearing a cost costume

Cost and control aren't opposites you trade off along one line. They're two different questions:

Some work carries sensitivity — regulated data, privileged information, security-critical design, probity that has to be demonstrable. Here you're buying control, and proximity, accountability and data residency are worth paying for.
Some work carries volume — high-throughput build and run where the sensitivity is genuinely low. Here you're buying scale and efficiency, and paying onshore rates for it is money left on the table.

The mistake is answering both questions with one word. Put everything onshore and you overpay for work that never needed it. Push everything offshore and you'll eventually route sensitive design through the wrong place and find out the hard way.

🗺️ The three models, honestly

Model	Choose it for	What runs here
🛡️ Onshore	Security, probity, data residency	Senior architecture, governance, regulated and sensitive work
🌍 Offshore	Cost efficiency and scale	High-volume build and run where sensitivity is lower
🔀 Hybrid	The best of both	Onshore leadership and governance, offshore delivery — blended by workstream

Onshore buys you proximity and defensibility. When your security director, your regulator or your board needs to know exactly where sensitive work happened and who's accountable, onshore answers cleanly.

Offshore buys you scale. For the high-volume build-and-run that makes up much of an integration estate — where the data isn't sensitive and the work is well-patterned — offshore delivers more capacity per pound, without touching anything that needs protecting.

Hybrid is where most mature programmes land, because it stops treating the choice as all-or-nothing. Senior architecture and governance sit onshore, close to the sensitive decisions. High-volume delivery sits offshore, where it's efficient. And the split is drawn by workstream, so each piece of work runs where it belongs.

The delivery model isn't one lever you pull for the whole programme. It's a line you draw through it — and you get to decide where.

🔒 How to draw the line without trading away security

The trick to a hybrid model that doesn't leak is that the split follows sensitivity, not convenience. A few principles keep it honest:

Keep the sensitive decisions and the sensitive data onshore. Architecture that touches regulated systems, anything involving privileged or personal data at rest, and the governance that has to be defensible — these stay close.

Send the well-patterned, low-sensitivity volume offshore. Once the patterns are set and the guardrails are in place, high-throughput build against non-sensitive data scales safely offshore.

Govern both halves the same way. The point of a governed platform is that it doesn't care where the builder sits — the same standards, reviews and controls apply onshore and offshore alike. That's what makes hybrid safe rather than just cheaper.

Revisit the line as the work changes. A workstream that starts sensitive may not stay that way, and vice versa. The split should flex with the work, not calcify.

🤔 "But what about…" — two honest answers

"Isn't offshore just a security risk full stop?" Only if you draw the line by cost instead of by sensitivity. Offshore delivery against non-sensitive data, on a governed platform with the same controls as onshore, isn't a risk — it's efficiency. The risk comes from routing the wrong work there, which is a design choice you control.

"Won't a hybrid model be harder to manage?" It's harder to manage badly and easier to manage well. A governed platform means one set of standards regardless of where the hands are. What's genuinely hard to manage is a single-location model that's overpaying for half its work or exposing the other half.

✅ Where to start

You don't need to restructure your whole delivery model to benefit from thinking this way. You need to draw one honest line:

🎯 Split your current work into "needs control" and "needs scale" — most programmes have never done this explicitly.
🛡️ Keep the sensitive design and data onshore; move the well-patterned volume offshore.
🚀 Govern both halves identically, and prove the blend on one workstream before you apply it across the programme.

Guidance reflects delivery experience across onshore, offshore and hybrid models; the right split depends on your regulatory, security and commercial context.

🤝 The ask is a short look at your programme and where the line should sit — so you get the cost of offshore where it's safe, and the control of onshore where it counts.