MM Group is in a growth phase that has reshaped the company. Over fifty percent business growth in two years. Twenty-plus factories acquired in three. Every one of those factories arrives with its own systems, its own data, its own operational reality.

The first major acquired plant Kwidzyn took just under twelve months to integrate into the group's IT estate. That was acceptable for one. With twenty more in the queue, it wasn't acceptable as a pattern.

The pattern was the problem.

Challange

Kwidzyn is not a small acquisition. The plant covers an area comparable to Monaco and Vatican City combined. It has its own power plant which fuels part of the surrounding town and its own train station. The factory floor itself is large enough to run two marathons inside it.

And it ran on webMethods. The competitor MM Group bought it from had been using the same integration platform. That made the technical challenge specific: the work wasn't to introduce webMethods to Kwidzyn. It was to unplug the existing webMethods integration from one corporate ecosystem and plug it into a different one. In twelve months.

Twelve months for a factory of that scale would be a successful integration by most standards. The MM Group integration team chose not to settle for it.

The problem they could see ahead was structural. The next acquisition would land. Then the next. Each would arrive with its own twelve months of work. The integration estate at MM Group was monolithic - large, capable, but not designed for the M&A pace the business was now running at. Two monolithic systems do not merge gracefully. They merge slowly, expensively, and with effort that scales with the size of both monoliths combined.

The arithmetic was unforgiving. Twenty factories at twelve months apiece is a queue the business could not afford to wait on.

Solution

The way out wasn't a faster monolith. It was no monolith at all.

The team used Kwidzyn's twelve-month integration window to do two things in parallel: complete the immediate work, and design what they called Plug & Play integration - a new architecture that would let every future factory come online in roughly half the time, with predictable budget, with a clear handover model.

The principle behind it is counter-intuitive in a single sentence:

If you want to succeed at integration, you have to disintegrate first.

A large, capable, single integration platform is the slow path. Many small, independently deployable integration components is the fast one.

The team decomposed the monolithic webMethods estate in four steps:

1. Define logical blocks. The estate was carved up by business function - procurement, sales, production execution, planning, finance, logistics and overlaid with a second dimension: whether each component was a global capability or specific to a single site. That two-axis design (function × scope) made every component's place in the architecture explicit.

2. Create a container per logical block. Each block became an independently deployable container. Service contracts between containers were defined explicitly, so a change in one didn't require coordinated changes everywhere else.

3. Re-evaluate the Software AG component model. Existing webMethods components - particularly Integration Server and Universal Messaging were repurposed for a containerised topology. The platform itself didn't change. The way the platform was used did.

4. Write the guidelines. This was the part the team called the biggest challenge - not because it was the most technical, but because it required changing how integration was thought about across the wider organisation. New patterns. New ownership boundaries. New muscle memory.

Delivery Approach

The delivery model was as much about discipline as it was about engineering.

Every code change followed the same path: a feature branch, a pull request, automated build and release pipelines on Azure DevOps, deployment to on-prem Kubernetes via Rancher, automated test execution, and a final manual approval. Critically, the developer who wrote the change did not approve their own change - a four-eyes principle sat at the centre of the workflow, where a separate release manager (the application owner) had to sign off before any deployment moved forward.

Every promotion was announced in a Teams channel - a small operational gesture that did more for transparency than any documentation could. Anyone in the business could see what had moved to which environment, when, and by whom.

The zero-downtime claim came with a small honest caveat: Kubernetes's rolling deployment is almost zero-downtime, but reaching genuinely zero downtime in a webMethods integration estate required custom code on top of the platform's defaults. The team built it, tested it, and runs it.

Throughout, IGT held to one principle: no black boxes. Every architectural decision was discussed openly with MM Group's team - not as a vendor presentation but as a working conversation. The result is that the platform is operated and owned by MM Group, not held at arm's length by a service provider.

Result

Future factory integrations are projected to land in roughly half the time. What took twelve months for Kwidzyn is targeted at six for future acquisitions - measurable on the next M&A the business runs.

Fifteen to twenty independent integration containers now run in production. The monolithic webMethods estate is being decomposed continuously, not all at once - every new block is born containerised, every legacy block migrates when it's ready.

The integration team's role has shifted. Less time on incident handling, more on building. Centralised logging in the elastic stack - visible to every application owner, not just the integration team means issues are diagnosed where they actually occur, which is most often not in the integration layer at all.

The decision to acquire is no longer constrained by integration capacity. When the business identifies a target, the integration team is, in Andreas Lehner's words on stage at a Software AG conference, "amongst the first to say: we are ready for the merger - start whenever you want."

And there's a quieter result: the same architecture that lets factories be added more quickly also lets them be removed. If a divestiture comes for whatever business reason the pattern works in reverse. That optionality didn't exist before.