WSO2 is gently nudging everyone toward Ballerina.
The new product is called WSO2 Integrator (BI). The marketing is enthusiastic. The roadmap signals where the company is going. If you're reading any official documentation right now, the message is clear:
This is the future. Get on board.
I work with WSO2 every day. I write synapse XML. I debug mediator sequences. I also have a local Ballerina BI instance running, where I've been building small APIs to learn the new world.
And my honest take, in 2026, is this:
Start new integrations on BI. Don't migrate your existing ones yet.
This isn't a no. It's not a yes either. Let me walk you through how I got here.
The two products, in plain terms
If you've been on WSO2 EI for years, the mental model is familiar:
- You write XML (synapse).
- You compose flows from mediators (Log, Property, Filter, Switch, Call).
- You bundle artifacts into CAR files.
- You deploy to a runtime.
- It works. It scales. It has been doing this for a decade.
Ballerina BI is a different thing entirely:
- You write actual code in a typed language called Ballerina.
- You compose flows with regular programming constructs (functions, types, error handling).
- You build artifacts using a real toolchain (Bal Build, Bal Test).
- You deploy to a runtime.
- It's newer, fresher, and noticeably cleaner.
Same integration patterns. Different way of expressing them.
What I actually love about Ballerina BI
Let me get this out of the way. BI is a better developer experience by a significant margin.
Real types. In synapse, you set a property as a string, then read it five mediators later, and if you typed the scope wrong you get an empty string with no error. In Ballerina, that's a compile-time error. The number of silent failures you can ship is way smaller.
Real testing. Want to test a mediator sequence in EI? Spin up the runtime, send curl requests, inspect logs, repeat. Want to test a Ballerina service? Write a unit test. Run it. Move on. The feedback loop is 10x faster.
Real refactoring. Rename a sequence in EI and you cross your fingers it didn't break a <sequence key="..."> reference somewhere. Rename a function in Ballerina and your IDE updates every reference. This sounds small. It's not.
Better debugging. You can step through a Ballerina service in a debugger. In EI, debugging is <log level="full"> and hope.
Better observability primitives. Tracing, metrics, structured logs are first-class concerns in BI. In EI, you bolt these on.
If I were starting an integration project today, on a clean slate, with no existing artifacts to preserve, I would pick BI without hesitation.
So why am I not migrating my existing work?
Three reasons. Each one is enough on its own.
1. The migration path is rewriting, not converting
WSO2 hasn't shipped a "convert your synapse XML to Ballerina" tool. There's no automatic path. You have to rewrite each integration by hand.
If you have 5 sequences, fine. If you have 200, that's a multi-year project with no business value. Every hour spent rewriting is an hour not spent on new features. Tell your product manager that the team is going to spend Q3 rewriting the gateway "for better developer experience." Watch them cry.
The work isn't impossible. It's just expensive. And the expense is borne by a team trying to keep the lights on, not by WSO2's marketing department.
2. The ecosystem is still young
Ballerina the language has been around for a while. Ballerina BI as the integration product is much newer.
What that means in practice:
- Fewer Stack Overflow answers when you hit a weird edge case. (now thats a place I haven't been to in a while)
- Fewer blog posts. The community is smaller.
- Fewer battle-tested patterns. You'll be the one figuring some things out.
- The official docs are good but still maturing.
- Some connectors that exist on EI don't exist (yet) on BI.
I love being early to good technology. I don't love being the person who has to figure out a bug in a niche connector at 2am for a production system. Risk-reward matters.
3. The "in-between" tooling problem
If you run both EI and BI in production, you now have two runtimes, two deployment pipelines, two monitoring setups, two skill sets to maintain. Some of your team knows synapse. Some are learning Ballerina. The cognitive cost is real.
This will improve. Companies that adopt BI early are paying this cost up front. Companies that adopt later will benefit from the trail those teams blaze. That's how it works with every major tooling shift.
I'm not against being the company paying that cost. I just think you should know you're paying it.
My current rules of thumb
Here's how I actually decide, project by project:
Greenfield integration, no existing constraints? → Ballerina BI. The DX wins outweigh the ecosystem gaps for new work, because you don't have legacy to maintain anyway.
Brownfield system with hundreds of synapse artifacts? → Stay on EI/MI. The cost of rewriting is huge, and EI is genuinely stable. WSO2 isn't going to abandon it overnight.
Small team, no Ballerina experience yet? → Stay on EI for now, learn BI on the side. Don't make your first BI project a critical production system.
You're a freelance or contract engineer evaluating which to learn? → Learn BI. The industry is shifting that way, and your future job market will reward it.
You're building something where types matter a lot (financial systems, healthcare, regulated work)? → Lean BI. The compile-time safety reduces a whole class of production bugs.
You need to ship to production next week? → Use what you already know. Don't learn new tools under deadline pressure.
What WSO2 isn't telling you
To be fair, WSO2 doesn't lie about any of this. They're just optimistic.
Read between the lines:
When the marketing says "Ballerina is the future of integration," that's true. They're investing the most engineering effort there. Long-term, BI will be the better product.
What they leave out:
- "Future" doesn't mean "ready for your specific case today."
- They have no incentive to highlight where EI is currently the safer bet.
- "Long-term" is doing a lot of work in that sentence.
Companies pushing new platforms always undersell the cost of migration. WSO2 isn't unusually bad at this. They're just doing what companies do.
You're the one who has to pay the migration tax. So you're the one who should decide when to pay it.
What I'm doing personally
For full transparency:
- My production work at a telecom continues on EI/MI. No plans to migrate. The systems work, they scale, the team knows them.
- I run Ballerina BI locally and have built four small APIs in it. The development experience is genuinely better. I write more, faster, with fewer bugs.
- Any new project that I have full control over, I'd reach for BI.
- I'm not pushing my team toward migration. The business case isn't there for us yet.
This isn't a permanent position. By 2027, the calculation probably tips further toward BI. By 2028, maybe further still. I'll re-evaluate as the ecosystem matures.
But today, in 2026:
Start new on BI. Keep existing on EI. Plan for migration eventually, not now.
If you're in a meeting where someone is pushing for a full migration as a strategic priority, ask them what business value the migration produces. The honest answer is "better developer experience." That might be worth the cost. It might not. Make sure you've actually had that conversation before committing the next 18 months of your team's time to it.
I wrote a more practical reference for working with WSO2 EI/MI in production. Mediator patterns, gotchas, deployment notes from telecom work. It's here on GitHub if you find it useful.
If you're at a similar decision point with your own team, I'd genuinely like to hear how you're thinking about it. Comments open.
Top comments (0)