When modernizing legacy systems, don’t be afraid to build glue services.
One of the biggest mistakes I see during modernization efforts is letting legacy integrations dictate the design of the new platform.
That usually leads to putting fresh paint on the same old house. Rebuilding the same architecture with a newer tech stack.
😴 The Dream vs. Reality
The dream project is building a brand-new platform with no existing users, integrations, or constraints.
You can design everything “the right way” from day one. But most real-world projects are not like that.
Most projects are modernization efforts. And most modernization efforts are weighed down by existing integrations, legacy protocols, and operational dependencies.
Changing customer behavior and expectations is often harder than rebuilding the platform itself.
🥲 The Common Mistake
Many teams respond to this by centering their new platform on the old integration model.
If customers use XML over Message Brokers, the new platform may speak JSON, but it still inherits the event-driven constraints—even when they no longer make sense.
If the legacy system exchanges files, the new platform is usually heavily batch-based.
The problem is:
Your modernization effort becomes constrained by the past.
🤯 A Better Approach: Glue Services
The formal term for this pattern is an Anti-Corruption Layer.
Personally, I think “glue service” explains it better. It makes the concept easier to understand.
Build the internal platform the way you actually want it designed.
Then build lightweight edge services that translate between legacy integrations and your modern platform.
- XML over Message Brokers? Use
gRPCinternally. - Files? Break them into APIs.
- Long-lived
ISO8583TCP connections? Terminate them at the edge and usegRPC+ microservices behind them.
The glue service has one responsibility: to translate between old and new worlds.
🤔 Why This Matters
These glue services give you two major advantages.
First, your internal architecture stays modern and optimized for current engineering practices. Second, your customers and integrations do not need to migrate immediately.
That dramatically reduces modernization risk. Temporary glue services can be huge modernization enablers.
But sometimes these glue services live forever, which is ok.
The important thing is that legacy integrations no longer constrain your modern platform.
🔁 It Works at Both Ends
This pattern applies both to inbound (clients calling your platform) and outbound (your platform calling legacy systems) integrations.
In many large systems, you’ll find glue services on both sides of the platform.
At the edge entering the system, and again leaving it.
🧐 Final Thoughts
Modernization is rarely just rewriting code. A major challenge is safely bridging old and new systems during transition periods.
I’ve used this pattern many times.
- Breaking files into APIs
- Translating
ISO8583andISO20022messages into Protobuf - Terminating long-lived TCP sessions at the edge of a
gRPC-based microservices platform
Glue services may not be glamorous, but they are one of the safest ways to modernize systems without dragging the past into the future.