MIGRATION METHOD
“Without disruption” is a method, not a promise.
Every integration flow is migrated in the same four phases, on production traffic, with the old system still running underneath. Nothing is switched off until the new implementation has been proven identical on your own messages — and until then, rollback is one configuration change.
We migrate flows, not systems.
A platform migration presented as a single programme is a single point of failure, and every experienced CTO knows it. So we do not run one. Each integration flow is discovered, rebuilt, proven and cut over on its own timeline, against a production system that keeps running throughout. A programme of two hundred flows is two hundred small, reversible changes — not one large irreversible one.
The consequence is that there is no cutover weekend, no code freeze, and no date on which the business is asked to hold its breath. There is also no point at which stopping is expensive: if you halt the programme after forty flows, you keep the forty and the licence reduction they earned.
THE FOUR PHASES
Applied per flow, not per system.
01
Discover
2 TO 4 WEEKS
We scan your existing artefacts — BusinessWorks processes, ACE message flows and ESQL, Mule XML and DataWeave, SAP PI iFlows — and produce a costed inventory: every flow, its cyclomatic complexity, its measured volume at peak and average, its upstream and downstream dependencies, its interface contracts.
The output is a heat map and a number. You get both before you commit to a migration, and the number is built from your artefacts rather than from an industry average.
02
Bridge
4 TO 8 WEEKS
The target platform goes into production alongside the existing one, and a Camel messaging bridge connects the two estates. Messages continue to flow through your current system exactly as they do today. Nothing is switched off, and nothing is at risk.
This is the phase where perceived risk drops fastest, because the new platform is running in production before a single flow has moved onto it. It is also the phase that makes everything after it reversible: as long as the bridge is in place, any flow can be moved back.
03
Strangle
ITERATIVE, IN WAVES OF 6 TO 10 WEEKS
Each flow is reimplemented, run in shadow against the original on real traffic, and compared message by message. When outputs match, traffic shifts by percentage — 1%, 10%, 50%, 100% — with rollback available at every step as a configuration change, not a deployment.
We start with flows that consume the most licensed cores and carry the least risk, because that is the ordering that returns money soonest for the least exposure.
04
Decommission
ON YOUR RENEWAL DATES
When a proprietary product has no active flows left, it comes out at the next renewal. We plan backwards from your contract dates from phase 1 onwards, because a licence that is technically unused but contractually paid for has saved you nothing.
That is also why the renewal date is the first question we ask. It is the only date on which the saving actually reaches your P&L.
PROVING EQUIVALENCE
How we prove the new flow behaves exactly like the old one.
This is the part of a migration that decides whether it succeeds, and it is the part most proposals leave as an adjective. “Thoroughly tested” is not a method. Here is ours.
PRODUCTION TRAFFIC
Live messages
LANE A · LIVE
Existing proprietary flow
Delivers the real business outcome, unchanged.
LANE B · SHADOW
New Apache Camel route
Outputs captured, never delivered. Writes intercepted, downstream calls stubbed.
COMPARATOR
Signed difference report
Real traffic, duplicated, with no side effects
Production traffic is duplicated at the entry point of the flow. One copy continues through your existing system and produces the real business outcome, exactly as it does today. The other copy runs through the new Camel route, whose outputs are captured and compared but never delivered — writes are intercepted, downstream calls are stubbed or directed at test endpoints, and no message leaves the shadow lane.
The consequence is that shadow testing costs the business nothing and risks nothing. It runs for as long as it needs to, under real conditions, including the conditions nobody thought to write a test case for.
Compared message by message, not sampled
Every shadow message produces a comparison record: the input, both outputs, and the verdict. Differences are classified rather than counted — a difference in a generated correlation identifier is not the same as a difference in an amount field, and a report that lumps them together is useless.
Fields that cannot match by construction — timestamps, sequence numbers, generated IDs — are normalised by an explicit rule agreed with your team before the run starts, and every such rule is listed in the report. A comparison that quietly ignores fields is not a comparison.
Long enough to catch the month-end
A flow is not proven by a clean afternoon. It has to run through the traffic patterns that actually break integrations: month-end close, batch windows, the retry storm after an upstream outage, the malformed message that a partner sends four times a year.
[[FILL — NOT PUBLISHED, DO NOT INVENT]]: la duración mínima de shadow que Independio se compromete a ejecutar antes de un cutover, y bajo qué criterio se extiende — por ejemplo, "un mínimo de dos ciclos de cierre mensual" o "N días con cero diferencias no explicadas". Es un compromiso operativo real y debe decirlo quien lo va a cumplir. No usar la cifra que aparece en el caso de estudio de ejemplo del deck de banca: ese caso es ilustrativo, no real, y el índice del proyecto marca explícitamente que no se use con un cliente.
The report is a deliverable, not a reassurance
Each wave produces a signed shadow comparison report: flows covered, messages compared, differences found, differences explained, and the residual set — if any — with a recommendation for each. It is the document your risk committee reads, and it is an output of the project rather than a promise made about it.
Below the shadow run: the test suite
Shadow testing proves equivalence on the traffic that happened. Automated tests hold that equivalence in place for the traffic that has not happened yet.
✓
Citrus Framework — Integration test cases that exercise the route end to end, including the messaging middleware, rather than mocking it away.
✓
Contract tests — On every interface the flow exposes, so a downstream consumer breaks the build rather than the business.
✓
Testcontainers — Real brokers, databases and gateways in CI — the same components as production, started per test run.
✓
Recorded production messages — Promoted into the regression suite whenever the shadow run finds a difference. Every defect found becomes a permanent test.
Because the routes are text in Git, all of this is reviewable in a pull request. In a regulated environment that is a materially stronger change-control record than a vendor console can produce: every change to a business rule is a signed, peer-reviewed commit with an author, a reviewer and a date.
The rollback plan, stated before you need it.
Every flow that moves runs behind a traffic split held in configuration. Reverting a flow to the proprietary implementation is a configuration change applied in seconds, not a redeployment and not a restore. The old flow is not deleted, disabled or modified while its replacement is being proven — it stays in place, running, until the product it lives on is decommissioned in phase 4.
Three consequences worth being explicit about:
A failed cutover is a non-event.
Traffic returns to the original flow and the difference is investigated offline, against captured messages, with no clock running.
A wave can be stopped without losing the previous ones.
Each wave is independently complete. Stopping after wave three leaves three waves migrated and running, not a half-built platform.
There is no big-bang date.
Because there is no date on which everything moves, there is no date on which everything can fail.
WHAT WE BRING
The difference is not that we know Apache Camel. It is the tooling that removes the guesswork.
Any competent consultancy can write a Camel route. What decides whether a two-hundred-flow migration lands on schedule is what happens before and after the route is written — how the estate is measured, how the rebuild is accelerated, and how equivalence is proven. These are the assets we bring to the first day of every engagement.
Discovery Scanner
Parses proprietary artefacts — TIBCO .bwp / .process, ACE .msgflow / .esql, Mule XML, SAP PI .iflw — and produces an automatic inventory: flow count, components used, dependencies, cyclomatic complexity, and an effort estimate per flow
CIO — it puts a number on the programme
EIP Mapping Catalogue
The documented equivalence between all 65 enterprise integration patterns, their proprietary implementation, and the exact Camel construct that replaces each one
Architect
Assisted transpiler
Generates Camel route skeletons from the scanned artefacts; the engineer completes the business logic rather than transcribing structure by hand
CTO — it is where the schedule comes from
Shadow-testing harness
Runs real traffic in parallel against old and new, compares outputs, and produces the comparison report that becomes the cutover criterion
CIO and risk
Strangler runbook
The four-phase progressive cutover method, with the rollback procedure documented at every step
CTO and operations
Platform blueprint
Helm charts, Argo CD and Terraform for the reference architecture — deployable in days rather than months
Architect
[[FILL — NOT PUBLISHED, DO NOT INVENT]]: confirmar qué activos de esta tabla existen hoy en forma utilizable, con qué nombre se van a publicar, y si alguno está registrado como marca. Publicar como producto algo que todavía es un script interno es recuperable; que un arquitecto pida una demo del Discovery Scanner en la segunda reunión y no exista, no lo es. Si alguno no está listo, retirarlo de la tabla — cinco activos reales convencen más que seis con uno hueco.
Your team owns the result, or the migration has not finished.
Knowledge transfer is a deliverable of every wave, with a name and an acceptance criterion — not a workshop at the end of the programme. Each wave hands over the migrated routes, the runbooks, the test suites and the deployment pipeline, and your engineers work inside the wave rather than being briefed after it.
The code is yours from day one, in your repositories, under your licence. There is no runtime we own, no console you need a seat for, and no component that only we can maintain. That is the point of the exercise: you are leaving a platform you cannot walk away from, and replacing it with one you can — including walking away from us.
Hiring is part of this argument and worth stating plainly. Recruiting an Apache Camel engineer is materially easier than recruiting a BusinessWorks engineer, and the gap widens every year. Proprietary integration talent is scarce, expensive and shrinking.
THE LIMITS
Some flows should stay where they are. We will tell you which.
A consultancy that says everything can be migrated is telling you what you want to hear. Every assessment we deliver contains a section on what we recommend leaving in place, and these are the cases where that recommendation is usually the honest one.
Sub-millisecond trading on TIBCO FTL or Rendezvous, where the cost of added latency exceeds the licence saving. The conversation there is about the rest of the estate, not about that flow.
z/OS mainframe with deeply coupled IBM MQ, where there is no mainframe modernisation programme. We migrate what surrounds it and keep MQ as the boundary.
Contracts with more than 24 months to run and no exit clause.The saving does not materialise in time to justify the programme. The right move is to start with discovery and arrive at the renewal prepared, rather than to migrate into a licence you are still paying for.
Organisations with no capacity to operate Kubernetes and no intention of acquiring it.For them the correct answer is our managed platform, not a turnkey migration handed over to a team that did not want it.
SAP PI where S/4HANA and Integration Suite are already committed and budgeted.We cover the non-SAP flows in the estate rather than argue with a decision that has already been taken.
One more, because it is asked in every assessment and the honest answer is not “all of it”: SAP JCo, IDoc and RFC connectivity depends on proprietary SAP libraries. There is no fully open-source substitute. We integrate with them, and we say so before you find out.
Start by measuring, not by migrating.
A ninety-minute estate health check walks your integration estate with your architecture team and maps it component by component, live. You leave with a substitution map for your own systems and a banded saving estimate. No charge, no commitment, and no platform change required to run it.