WSO2 Support Options: Subscription, Extended Life or Independent

WSO2 support comes from three places: a WSO2 subscription, which includes 24x7 support and the WSO2 Updates service; WSO2's paid Extended Life Support for versions past end of life; and independent providers, who support the open-source release, versions WSO2 no longer covers, and the day-to-day running of the platform. Which you need depends on whether you hold a subscription and how old your version is.

What a WSO2 subscription includes

WSO2 API Manager, Identity Server and the integration products are open source under the Apache 2.0 licence, so the software itself is free. The subscription is what you pay for, and WSO2 is explicit about the difference. Subscribed deployments receive bug and security fixes as they are produced, through the WSO2 Updates service; the open-source release receives them in the next release. Subscribers get WSO2 expert support around the clock; open-source users get community support through Slack, GitHub and Stack Overflow.

That makes the update channel the real product. If you run the open-source distribution without a subscription, you are running a version that is behind on security fixes by design, and no third party can give you WSO2 Updates. Anyone who says otherwise is describing something else.

In practice a subscriber raises an incident in the WSO2 support portal, the support team classifies it by severity, and the response time follows the service level in the subscription. The same subscription covers the WSO2 product range, including WSO2 API Manager, WSO2 Identity Server and Micro Integrator, and WSO2 runs separate support plans for its SaaS products such as Asgardeo. For an enterprise customer that depends on the platform for API management or identity, that is the baseline and it is a good one.

How long WSO2 supports a version

Under the WSO2 Support Services Policy (version 6.0, effective 26 April 2026), WSO2 commits to support each major and minor release for a minimum of three years from its release date. After that it may announce end of life, and it will use reasonable efforts to keep supporting the version for at least a year after the announcement. For release lines introduced from March 2024, the support matrix commits to a minimum of seven years for the line as a whole, with each version inside it still getting at least three.

Past end of life, WSO2 offers an Extended Life Support Plan: limited support, at extra cost, only on request, with updates limited to those released for that version and no back-porting except critical security fixes. It is a bridge to an upgrade, not a way to stay put.

Where independent WSO2 support fits

• You run open-source WSO2 without a subscription. An independent provider gives you production incident response, configuration and performance help, and an upgrade plan. It does not give you the WSO2 Updates channel.
• Your version is past WSO2 end of life. Older API Manager, Enterprise Integrator and Identity Server versions are common in production. Independent support covers them while you plan the move to a supported release line.
• You hold a subscription but lack WSO2 skills in-house. WSO2 support resolves product issues. It does not run your gateways, tune your throttling, fix a custom mediator or untangle a registry database deadlock at 3am. The same is true of the environment around the product: the Kubernetes deployment, the database, the load balancer in front of the gateway.

AceMQ provides 24/7 WSO2 support on that basis, with a 15-minute emergency SLA and named senior engineers, for API Manager, Identity Server and the integration products. Two examples of the work: gateway throttling that did not apply consistently across nodes and an API Manager upgrade with custom mediators.

The WSO2 incidents that actually page people

• Throttling that is not enforced consistently. Rate limits apply on one gateway node and not another because the traffic manager connection, the event hub or the policy deployment is out of step across the cluster.
• Token endpoint latency. Every API call that needs a token waits on the key manager and its database. Slow user store lookups, token table growth and missing cleanup jobs turn authentication into the bottleneck for the whole platform.
• Registry and database contention. Deadlocks and lock timeouts in the registry or the API Manager database appear under load or during deployments, often on a shared database server that was sized for a pilot.
• Gateway out of memory. Large payloads passed through mediation, message building where pass-through would do, and custom mediators that hold references are the common causes. Heap dumps and the right JVM settings find them.
• Artifacts out of sync. In a distributed deployment, an API published on the control plane does not reach every gateway. Requests succeed or fail depending on which node answers.

Upgrading WSO2 between versions

WSO2 upgrades are migrations. The product is installed fresh, configuration is re-applied in the new format, which moved from many XML files to a single deployment.toml in recent release lines, and the databases are migrated with WSO2's migration resources, which are provided to subscribers. Customisations carry the real risk: custom mediators, handlers, authenticators, Velocity templates and themes all need rebuilding and retesting against the new version, and Enterprise Integrator estates face a product change to Micro Integrator. A team several versions behind should plan one migration to a current release line with a long support commitment, rehearse it on a copy of production data, and keep support on the old version until cutover.

WSO2 support services compared

The short version for an enterprise customer: the WSO2 subscription is the only source of the licensed distribution, product fixes and the update channel, so it is the right answer when you need a bug fixed in the product. Independent WSO2 support services are the right answer when you need an engineer to resolve an incident in your own deployment, on premises or in the cloud, to plan a migration to a new major version, or to keep open source software running that WSO2 has stopped covering. Many teams hold both. If you are not sure which gap you have, contact us and we will tell you plainly, including when the answer is WSO2.

Questions to ask a WSO2 support provider

• Which WSO2 products and versions do you support, including ones past end of life?
• Is the response commitment a human engineer or an acknowledgement?
• How do you handle an issue that needs a product fix from WSO2?
• Can you run the upgrade or migration between release lines, not only advise on it?