Migrating a MuleSoft integration platform to Azure and Apache Camel

The context

In a company, applications do not work in isolation: the order management software talks to the invoicing system, which talks to accounting, which receives files from outside partners. An integration platform is the junction that organises all those exchanges — it carries them, converts them and monitors them.

Our client uses a platform published by MuleSoft for this. It works, but its licence weighs heavily on the IT budget, and the planned changes to the information system were going to make it heavier still.

Applications involved

30

Flows to be migrated

90

Load

300 to 400 messages/min

Target hosting

Azure

What is at stake

There is a well-established alternative to that platform: Apache Camel, open-source software, widely adopted and supported by an active community, which can do the same job with no licence to pay.

But open-source software is not a drop-in replacement for a turnkey service: you have to build for it what the vendor used to provide — the infrastructure that hosts it, monitoring, security, release tooling. That is precisely what our engagement is about. It also has to meet two constraints: staying within the Azure environment the client already uses, so as not to add yet another provider to master, and continuing to talk to the servers that remain on their premises.

What we are doing

An architecture study, first. Rather than proposing a single solution, we examined each necessary building block — hosting, message transport, access security, monitoring, releases — and compared the options available on Azure, on cost as well as on the operational burden they imply.

Those options were then combined into three coherent scenarios: one for a constrained budget, one balanced, one sized for performance and strict service commitments. Each was costed and documented, with its advantages and its limits, so the choice would belong to the client. The balanced scenario was the one selected.

Building the platform, next. The infrastructure is described as code, which makes it possible to recreate it identically on each environment and to trace every change. Releases are automated, from build through to deployment, with quality gates and human approvals in the right places.

Validation by proof, finally. Before committing to migrating the 90 flows, a technical prototype checks the points that will decide feasibility: talking to the real systems, running the old and the new platform in parallel during the switchover, and resource consumption under load.

Where the project stands

The analysis workshops and the architecture documentation are complete. The infrastructure and the release pipelines are in place, and the platform is being installed and validated on the test environments: connectivity with the client's servers, monitoring, load balancing, access security and message transport.

The Apache Camel prototype and the deployment of a first component are the next step, before the migration of the flows themselves and the handover to operations.