Enterprises don't fear their platforms failing. They fear them changing – licensing, features, roadmaps – while every rule the business owns is trapped inside. The fix is architectural. And it can be made in stages.
Somewhere in your organisation, a platform is quietly becoming something you did not buy. The licence terms have changed hands. Features you rely on are being retired. The roadmap is moving, and it is not moving in your direction.
Enterprises tell us this in different words, but it is the same message every time: the platform we chose is no longer the platform we run.
That does not make the platform bad. It changes the balance of the relationship. Most organisations only discover how much has changed the first time they ask a simple question: what would it take to change the platform?
How lock-in actually shows up
Lock-in rarely arrives as an invoice. It arrives as friction, and the pattern is remarkably consistent across industries:
FIVE SIGNALS OF EXCESSIVE DEPENDENCY
- Small business changes wait in a queue behind a few scarce platform specialists.
- Routine upgrades disturb processes that should never have been touched.
- Rules the business depends on exist only inside the platform's own configuration.
- Every new channel needs yet another platform-specific integration.
- Nobody can put a credible price on what replacement would cost.
When several of these appear together, the platform is no longer a component of your architecture. It has become the architecture.
Why good stewardship creates dependency
Four obstacles come up every time. Years of customisation that nobody fully documented. Skills held in a few heads, some close to retirement. Users whose whole working day is built around the platform's screens, where any disturbance carries a real operational cost. And above all, caution. The platform runs a mission-critical service, and the same discipline that protects it makes change hard to start.
These obstacles reflect good stewardship, not reluctance. The business did things right, and the platform works. That is exactly why the answer cannot be a rewrite. It has to be separation.
Separate the logic from the machinery
Business logic is how your organisation actually works: the rules that govern eligibility, pricing, validation, approvals, routing, calculations and exceptions. It is enterprise intellectual property. Screens, storage and transport are just the machinery that carries it out.
The rule that approves a transaction belongs to the enterprise. The platform merely executes it.
Separation starts with discovery. Source code, configuration, interfaces and operating procedures are examined to find where decisions are really made. The findings are checked with the people who own those decisions. The result is a documented map of the capabilities that must survive any change of platform.
Each capability is then placed behind an interface the enterprise controls – a stable API, service contract or event definition. Applications talk to that contract, never to the platform's internals. The enterprise owns the contract: its definitions, documentation, security policy, data formats and monitoring. Open standards keep the boundary portable.
The same discipline applies to the people using it. A modern interface can keep the workflow they rely on while drawing everything through the stable services – so users keep what they need, without the old dependency returning in a new skin.
What replacement then looks like
Not a big bang, unless a security or support deadline forces one. Once applications are routed through the contract, a replacement can run in parallel behind the same boundary. Outputs, performance and exception handling are compared until the numbers agree. Cutover then proceeds by process, user group, channel or transaction type – with a way back at every stage.
This is also how an enterprise weans itself off a platform gradually: one capability at a time, each pulled behind its own contract. Where a platform function becomes unavailable or too costly, the organisation can rebuild the business outcome using its own rules, processes and data. Licensing and intellectual property boundaries still apply – you rebuild the outcome, never the vendor's technology. Change management shrinks throughout, because users and applications see continuity while the implementation is swapped beneath them.
Does it work outside a slide deck?
We prove the pattern with reference implementations: established transaction logic in Natural and COBOL exposed through OpenAPI contracts; green-screen workflows presented through modern web interfaces without rewriting the core; current and candidate implementations running in parallel behind one contract until reconciliation, performance and rollback have all been demonstrated. That is repeatable engineering evidence. And it means the first step is deliberately small: pick one contained capability and put a boundary around it.
Choice is an architectural outcome
Standardising on a platform is not the mistake. Letting every rule, interface and user journey become inseparable from it is. Identify the logic the business owns. Place it behind contracts the enterprise controls. Migrate in stages. The goal is not perpetual replacement. It is the ability, when the platform's direction and yours part ways, to respond on your own terms.
Share
Editorial contacts