Why Companies Running WSO2 Are Rethinking How They Get Support

Most people have never heard of WSO2, but there is a good chance their bank, insurer or hospital relies on it. The open source platform sits behind the scenes of many large organizations, managing the APIs that let mobile apps, partner systems and internal tools talk to each other, and controlling who is allowed to sign in to what.

That quiet role is exactly why support has become a pressing question. When the layer that connects everything slows down or fails, customers notice within minutes. A login page stops responding, a partner cannot submit an order, a payment sits in a queue. As more companies run WSO2 in production for years at a time, many are finding that the way they handle support no longer matches how much now depends on the platform.

A platform that became critical without anyone noticing

WSO2’s products cover several jobs that used to need separate vendors. API Manager handles API management: publishing APIs, securing them, setting usage limits and tracking how they are used. Identity Server manages logins for staff, customers and partners, including single sign-on and multi-factor authentication. Micro Integrator connects older systems to newer ones, translating between formats and moving messages where they need to go.

Many organizations started with one of these products for a single project. A team needed an API gateway for a mobile app launch, or a way to give partners secure access to a few services. Then the next project used the same platform, and the one after that. Over time, the platform moved from being one team’s tool to something the whole business runs on.

A payment flow, a patient portal or a claims system may now pass through it thousands of times a day. Yet the support arrangement is often still the one that was set up for that first project, sized for a pilot rather than for a core piece of infrastructure.

Open source, but not unsupported

Part of WSO2’s appeal is that its core products are open source. Organizations can download them, run them on their own servers and inspect the code. That flexibility has made WSO2 popular with teams that want to avoid being locked into a single cloud provider.

But open source does not mean maintenance-free. Security fixes, performance improvements and compatibility updates arrive continuously, and someone has to test and apply them. WSO2 sells subscriptions that provide product updates and access to its own engineers, priced around how the products are used and quoted for each deployment. Some organizations run the open source versions without a subscription and rely on their own staff. Others combine a vendor subscription with outside help.

Each approach can work. The risk comes when nobody has made a deliberate choice, and the organization finds out during an incident that its coverage is thinner than it assumed.

Where the gaps show up

Teams that run WSO2 tend to describe the same few problems.

The first is version drift. Upgrading an API gateway or identity platform touches every application that depends on it, so upgrades get postponed. A few years later, the organization is running an older release, applying fixes slowly and carrying risk it would rather not have. Each skipped upgrade makes the next one larger.

The second is knowledge concentration. In many companies, one or two engineers understand how the platform was configured and why. When one of them leaves, the organization discovers how much of its setup was never written down: custom policies, certificates with unknown expiry dates, integrations that only work because of a setting nobody remembers changing.

The third is the gap between fixing and improving. A traditional support contract is built to resolve incidents. It is not built to design the next set of APIs, add a new partner integration or tidy up years of configuration. Internal teams end up doing both jobs, and the improvement work usually loses to whatever is on fire that week.

Identity and AI raise the stakes

Two trends are adding pressure. The first is identity. More organizations now use WSO2 Identity Server for customer logins, not just internal staff. That makes the platform part of the customer experience, and any outage becomes visible to the public immediately.

The second is artificial intelligence. Companies experimenting with AI agents are discovering that those agents need to call APIs and access data just like any other application. The questions that follow are familiar ones: which systems can the agent reach, under whose authority, and how is that recorded? For many organizations, the API and identity layer they already run is the natural place to enforce those rules. That only works if the layer is current, well understood and properly supported.

The questions buyers are now asking

As a result, the conversation around WSO2 support has changed. Organizations are less interested in a phone number to call when something breaks and more interested in a handful of practical questions.

Does the provider have recent experience with the exact products and versions we run, including older releases we cannot upgrade yet? Do they support self-hosted and open source deployments, or only the newest cloud services? Can the same team that fixes incidents also handle upgrades and planned changes, so that knowledge is not split between two groups? Is coverage matched to how critical each system is, rather than one level for everything? And can they produce the records our auditors and security reviewers will ask for?

For regulated industries such as banking, insurance and healthcare, that last question often decides the matter. A support arrangement that cannot show what was changed, when and why is hard to defend in a review, however good the engineers are.

Different models for different needs

There is no single right answer, and most organizations end up combining approaches.

Some rely on a subscription from WSO2 itself, which provides product updates and access to the vendor’s engineers. Others add a specialist partner that knows their particular deployment and can work alongside their own staff. A growing number go further and use an outsourced team: a small core of engineers who stay with the platform for the long term, with more people added for larger projects and then stepped back down when the work is done.

That last model appeals to organizations that want continuity without building a large in-house integration group. The core team keeps the knowledge, documents the environment and handles day-to-day changes. Extra capacity arrives for a migration or a new initiative, then leaves. The key is that the knowledge stays, even when the headcount changes.

The right mix depends on how critical the platform is, how much expertise already exists in-house and how often the business needs changes, not just fixes.

What good preparation looks like

Whatever model an organization chooses, a few habits make support far more effective. Keep an up-to-date inventory of which WSO2 products and versions are running, where, and what depends on them. Write down the custom configuration and the reasons behind it. Track certificate and license expiry dates. Agree in advance who is called for which kind of problem, and test that process before it is needed.

These steps sound basic, but they are often missing. Organizations that have them in place recover from incidents faster and upgrade with less drama, whoever provides their support.

Why it matters now

WSO2 has been expanding its newer cloud products while many customers continue to run self-hosted versions on their own infrastructure. That leaves organizations deciding which parts to move, which to keep and how to support both at once. Those decisions are easier with people who have seen several real deployments, not just reference architectures.

For teams that depend on WSO2 every day, the lesson is simple. Review the support arrangement with the same care as the platform itself, and do it before an outage forces the question.