IBM API Connect v10 end of support: what your renewal decision has to answer
This page answers one question: should your IBM API Connect v10 estate move to V12.1, or should it move to a self-hosted open-source platform such as WSO2 API Manager or Gravitee? The short answer is that the V12.1 upgrade is the lower-change path when your hosting and data rules already fit IBM's deployment options, and migration deserves a priced comparison when they do not. Your renewal is the moment to decide. Version 10.0.5 has been out of fix support since June 2025, and 10.0.8 is the last V10 LTS release. Any estate still on 10.0.5 is already running without vendor fixes, so the first check is the exact fix pack that each gateway, manager and portal subsystem runs.
The decision turns on constraints that are expensive to change later: where API traffic and payloads may be processed, whether the platform must run in an air-gapped network, and whether your security team requires the control plane to sit inside your own boundary. If your residency rules allow IBM's SaaS on AWS or IBM Cloud, or your self-managed estate can stay where it is, the V12.1 upgrade keeps your platform and consumer relationships in place, subject to IBM's upgrade guidance. If a control plane outside your boundary is not acceptable, price the open-source route. WSO2's API Manager page describes on-premises, hybrid and Kubernetes deployments, so test those against your network rules early. Confirm with IBM the V12.1 system requirements, the support dates for 10.0.8, and whether your current license terms carry into V12.1.
Whichever path you choose, turn the decision into a written scope before the renewal date. DeployOpen plans, implements, integrates, hardens and documents self-hosted open-source platforms in your own cloud accounts, data centers or air-gapped networks, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from that scope. To make any quote specific, gather an inventory of APIs, products, plans, consumer organizations and gateway locations, along with the dates and commercial terms in your current agreement. Ask IBM and any other vendor to state in writing what the renewal includes, which costs are one-time and which recur, and how support continues after each version's end date.
What the v10 end of support requires from your estate
The support timeline sets the deadline, but the work is in your estate: the gateways, management subsystems, consumers and records that must keep running through a change. The four cards below cover what an upgrade to V12.1 or a move to a self-hosted platform has to account for, whichever path you choose.
A supported release line
Confirm which API Connect release line your estate runs today and the exact end of support dates for that line with IBM before you plan. The Topic Facts do not give IBM's dates, so treat any date you see secondhand as unverified. Note that 10.0.8 is described as the last V10 LTS, which means every V10 installation has a fixed horizon. Put the confirmed date in the project plan as the hard deadline for both paths.
A tested path for gateways
Upgrading the management subsystems and the DataPower gateways are separate changes with separate rollback points. Inventory every gateway service, its version, its custom policies and its deployment target, then rehearse the change in a non-production copy. If you move to a self-hosted open-source gateway instead, the same inventory becomes your mapping list for policies and routes. Ask IBM and any candidate vendor for documented upgrade or migration steps for your exact topology.
Consumer and credential continuity
Every application that calls an API holds a client identifier, a secret or a token issued by the platform. Before cutover, export the catalog of products, plans, consumer organizations and applications, then decide whether credentials are carried over or re-issued. Re-issuing credentials forces consumer teams to change configuration on their own schedule, so plan a dual-running window with the old and new endpoints both answering. Record which consumers are external partners, since their change windows are outside your control.
A change control evidence trail
Auditors and internal risk teams will ask how each API policy, certificate and access grant changed during the transition. Keep dated configuration exports, test results from each rehearsal, approval records and the rollback plan in one controlled location. This trail is evidence you assemble for an assessor, since DeployOpen prepares controls and records but does not issue audit reports. Agree with your assessor early which records they expect for a platform change of this size.
Upgrade to V12.1 or migrate: how each path changes the work
The upgrade keeps your published APIs, products, consumer organizations and gateway topology in place while the platform underneath changes. Most of the work falls to your platform team and the owners of existing configuration, with IBM supplying the upgrade path and documentation. The effort is driven less by the platform itself and more by how much custom logic sits in your current estate.
- Estate inventory: List every management, gateway, portal and analytics component on your current release, and confirm which ones your V12.1 target covers.
- Test environment rebuild: Stand up a non-production estate that mirrors production topology so policies, consumers and certificates can be tested before cutover.
- Custom logic review: Check custom policies, gateway scripts and certificate chains against the target release, since these are where upgrade issues usually appear.
- Recurring commitments: Subscription or self-managed renewals, the container platform and support continue after the upgrade. The project does not remove them.
- Repeat cycles: Every later release needs another regression pass across the same estate.
Ask IBM in writing which components, add-ons and infrastructure requirements the V12.1 target assumes, and which of those are included in your current agreement and which are billed separately.
Moving to WSO2 API Manager means rebuilding APIs, policies and developer onboarding on a different product with its own control plane, gateway, Publisher and Developer Portal. A migration team usually combines platform engineers, who deploy and operate the stack, with API owners, who remap their APIs, and security staff, who review authentication and throttling. Effort rises with the number of custom assembly policies and with the number of consumers who must re-onboard.
- Deployment model: WSO2 supports on-premises installs from extracted packages, Kubernetes through the separate WSO2 API Platform for Kubernetes, and a managed cloud service. Each option changes who patches and operates the infrastructure.
- Build baseline: The repository notes that building API Manager 4.7.0 requires JDK 21, so build pipelines and base images need to match that requirement.
- Mediation mapping: Assembly policies and gateway scripts become mediation sequences and custom extensions. This is usually the largest variable in the project.
- Support model: An open-source build puts patching, vulnerability tracking and upgrades on your team. A commercial subscription adds expert support, continuous updates, vulnerability monitoring and the licensed distribution for commercial use.
- Staged cutover: WSO2 states that one control plane can manage its gateways and third-party gateways, which may support a staged move. Confirm this against your topology.
Ask WSO2 which subscription components your production environment needs and whether your intended deployment model is covered by that subscription.
Gravitee has a smaller set of components than a full API Connect estate: a gateway, a management API backend, the Console UI for administrators and the Portal UI for the API catalog. The migration work is similar in shape to the WSO2 path but usually involves fewer moving parts to deploy. The main variables are the edition you choose and how many IBM-specific constructs your APIs depend on.
- Deployment method: Gravitee documents a Helm chart for Kubernetes, including AKS, GKE, EKS and OpenShift, and a Docker Compose option with MongoDB for smaller environments. Choose the method that fits your platform standards.
- Edition decision: The Community Edition is self-hosted. The Enterprise Edition requires a license and adds features such as data masking, Redis caching and audit trails of API consumption. Check whether any current behavior depends on Enterprise features before you commit.
- Protocol coverage: Enterprise Edition lists event endpoints such as Kafka, MQTT5, RabbitMQ and Server-Sent Events. If your estate uses event APIs, map them against the edition you choose.
- Operating load: Your team owns the MongoDB store, Kubernetes components, certificates, backups and upgrades unless you buy support or a managed deployment.
- Policy mapping: Plans, subscriptions and policies need a documented mapping, and the effort depends on how many IBM-specific policies you use.
Confirm in writing which edition covers each feature your APIs require, and who supports the data store and Kubernetes layer you plan to run.
Which open-source platform fits which constraint
This table tests WSO2 API Manager and Gravitee API Management against the constraints that usually decide an API Connect exit: licensing, deployment model, control plane and gateway split, developer portal, and features that need a paid license. Read each row as a question to put to the vendor and to your own architects, since the gaps column names what still needs confirmation before a choice is made.
| Constraint | WSO2 API Manager | Gravitee API Management |
|---|---|---|
| Core license | Apache-2.0 for the product repository. Commercial subscriptions add support, continuous updates, vulnerability monitoring and a licensed distribution for commercial use. | Apache-2.0 for the open-source core. Some features require a Gravitee Enterprise License, and the Enterprise Edition requires a license. |
| Self-hosted deployment | Supported on premises from extracted packages. Confirm the supported JDK and patch level for your estate, since 4.7.0 builds require JDK 21. | Self-hosted with Community Edition using Docker Compose with MongoDB, or Helm on Kubernetes. Enterprise adds hybrid and fully self-hosted options. |
| Kubernetes deployment | Available through a separate WSO2 API Platform for Kubernetes. Confirm the chart, operator and OpenShift support you need with WSO2. | Helm chart for Kubernetes that the README lists for AKS, GKE, EKS and OpenShift. Confirm the chart version against your cluster policy. |
| Control plane and gateway split | One control plane can manage WSO2 gateways and third-party gateways such as Kong, AWS, Azure and Envoy. Test this against your DataPower-era routing before relying on it. | Management API backend and gateway are separate components. Confirm how Community Edition handles gateway-only nodes in each zone where APIs are published. |
| Developer portal | Developer Portal and Publisher web interfaces are included. Confirm that the portal covers your existing API Connect product and plan model. | Portal UI with a catalog of APIs and documentation is included. Confirm how subscriptions and consumer onboarding map to your current consumer organizations. |
| Event and async APIs | Supports REST, GraphQL and AsyncAPI APIs. Confirm the event broker connectors you rely on today, since they may need custom work. | Kafka, MQTT5, RabbitMQ, Solace, JMS, SSE and webhook entrypoints are Enterprise Edition features. Community scope for these must be verified. |
| Enterprise-only features | Commercial value is mainly support, updates and vulnerability monitoring. Confirm which extensions you will build yourselves and which you expect from the vendor. | Data masking, GeoIP filtering, Dynamic Client Registration, Redis caching, Alert Engine, audit trails and LLM or MCP proxies need a license. Confirm each one you use today. |
| Customization | Custom authenticators, policies and workflows can be added. Confirm the effort to port existing assembly policies and gateway scripts. | Policies and plugins are configurable, but the enterprise policy pack is licensed. Confirm which policies your team has to rebuild. |
How WSO2 API Manager and Gravitee map to API Connect's parts
Start the mapping with the control plane, because that is where the two open-source candidates differ most from API Connect's layout. WSO2 API Manager separates its work into an API control plane, a gateway for routing, mediation and security, a traffic manager for throttling, and two web interfaces: the Publisher, where API owners define and publish APIs, and the Developer Portal, where consumers discover and subscribe. Those roles line up with the parts of API Connect your team already administers: the management and catalog functions, the gateway that enforces policy, and the consumer-facing portal. Gravitee APIM uses a different split: a gateway, a management API backend, a Console UI for administrators and a Portal UI that holds the API catalog and documentation. Its Console UI covers the lifecycle and access work, while the Portal UI covers discovery. In both products, list each API Connect subsystem and write down which open-source component will own that function, and flag any function with no clear owner for a proof-of-concept.
Deployment shape is the second check. WSO2 supports API Manager on premises from extracted packages, as a managed cloud service, and on Kubernetes through its separate WSO2 API Platform for Kubernetes. Gravitee's README lists Gravitee Cloud SaaS, a Helm chart for Kubernetes distributions including AKS, GKE, EKS and OpenShift, and Docker Compose with MongoDB. Gravitee's Community Edition is self-hosted, but its documentation states that the Enterprise Edition requires a license and that some features are available only in that edition. Before you commit, confirm with each vendor which of your current API Connect capabilities sit in the free build, which need a subscription, and which need a feature you have not yet tested. Do not assume that a policy you use in assembly has a direct equivalent in either product, since neither source supports feature parity with DataPower or API Connect assembly policies.
Treat the mapping as an inventory exercise, not a feature checklist. Export the list of products, plans, consumer organizations and gateway policies that your operations team actually relies on, then test each one against a candidate gateway in a non-production environment. Gravitee's Enterprise-only items, such as data masking, Redis caching and audit trails of API consumption, should appear on that list if your current estate uses equivalents, because those are the items most likely to change your licensing decision. Record the result per component so the cost comparison and the migration plan draw on the same evidence.
How to run the chosen platform under your constraint
This sequence moves API Connect v10 workloads to the chosen platform in controlled stages, so each stage ends with a verified inventory, a tested environment, matched policy behavior and a documented cutover. It keeps v10 running until consumers are confirmed on the target.
Inventory APIs, products, plans and consumer organizations
Your API platform team exports the catalog from API Connect: every API definition, product, plan, rate limit, consumer organization, application and client credential, plus the gateway, portal and analytics settings attached to each. DeployOpen can review the export with you and flag objects that have no direct equivalent on the target. The step is done when every API and consumer is listed in a single register with an owner and a traffic profile, and you can account for each one.
Choose the hosting model for the target
Decide whether the target runs on virtual machines on premises, on Kubernetes, or in a hybrid layout with a control plane in one place and gateways close to backend systems. Confirm the supported options with the vendor or project documentation for your chosen platform, and check the JDK or container runtime versions it requires. Your infrastructure team owns the decision and the capacity plan, and the step closes with a signed architecture record covering network zones, identity integration and where logs and backups are stored.
Stand up a non-production environment
Build a non-production environment that mirrors the target architecture, including gateways, the management plane, the developer portal, identity provider connections and backend test doubles. DeployOpen plans and implements this environment in your infrastructure when it is in scope, and your team supplies the accounts, network access and certificates. The step closes when a sample API deploys, a test consumer authenticates and the portal publishes its documentation.
Map assembly policies to target policies
Translate each API Connect assembly policy, gateway script and security setting into an equivalent on the target, such as authentication, rate limiting, transformation and logging. Mark any policy with no direct match as a gap and decide whether to rebuild it, move it to the backend or drop it with sign-off from the API owner. Keep a mapping table with one row per policy, its target implementation and its test case. The step is done when every policy has a mapped implementation and a passing test.
Run parallel traffic and compare results
Route a controlled share of consumer traffic to the target while v10 continues to serve the rest, and compare status codes, latency, throttling outcomes and log entries between the two paths. Consumers should be moved in groups, with the owners of each API agreeing to the change window. The step closes when error rates and response behavior match the agreed acceptance criteria for every migrated API, and any differences are either fixed or documented as accepted.
Cut over consumers and credentials
Move each consumer organization to the target endpoints and re-issue client credentials through the target's application model, sending new keys through your existing secret-distribution process. Keep v10 available for rollback until every consumer on the register is confirmed working. The step closes when the register shows every consumer cut over, with dates, owners and a rollback path recorded for each group.
Retire v10 and keep evidence
After the final consumer is confirmed, decommission the API Connect gateways and management components according to your data retention rules, and archive exported configurations, logs and test results in a location your auditors can access. Update your asset inventory, backup jobs and access reviews to remove v10. The step is done when v10 no longer serves traffic, its components are removed from monitoring, and the evidence package is filed with the change record.
Questions buyers ask before choosing an upgrade or migration
What drives the cost of a V12.1 upgrade compared with a move to open source?
The upgrade cost is driven by the size of the existing estate, while a move cost is driven by how much must be rebuilt on a different platform. A V12.1 upgrade keeps your product model, gateway configuration and consumer organizations on the same vendor stack, so the main costs are the new platform infrastructure, testing of every API flow, and the licensing or subscription terms that apply to the target release. A move to an open-source platform such as WSO2 API Manager or Gravitee adds the cost of re-expressing assembly policies, gateway scripts and portal content, plus re-issuing credentials to consumers. Ask for the cost split into one-time work (design, migration, testing, cutover) and recurring items (subscriptions, infrastructure, support, upgrades), and ask which of those items each option removes.
Can our own team do the API Connect upgrade or migration without outside help?
Many teams can handle parts of the work internally, but the decision depends on how many APIs, policies and custom gateway scripts you run and whether your staff have hands-on experience with each platform. An in-house team usually owns the inventory of APIs, the consumer communication and the sign-off on test results, which are the parts that depend most on your business knowledge. Specialist help is most useful for the platform build, policy mapping, load and security testing, and cutover runbooks, where a mistake is costly and staff time is scarce. A useful first step is to inventory your estate and ask whether your engineers have run the target platform in production. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with scope and timelines agreed in writing before work starts.
How long does each path take, and what makes the timeline longer?
The timeline depends on the number of APIs and environments, the complexity of custom policies and the window your consumers can accept for changes. Time is also governed by the support dates that apply to your current release. Apigee's documentation for its own product, for example, ties continuous support to running a version inside its 18-month full support window, which is a useful reminder to check the support dates for your exact API Connect release with IBM before you set a deadline. Factors that lengthen either path include unmapped gateway scripts, many consumer organizations to re-onboard, certificate and identity changes, and regulatory approvals for production changes. Ask any provider for a timeline built from a written list of APIs, environments and test cases rather than from a single overall estimate.
What does the work need from IBM and from our own staff?
IBM's role is to confirm your entitlement, supported release path and any support or upgrade terms for your deployment, whether SaaS or self-managed with DataPower gateways. Your staff provide the knowledge of which APIs are business-critical, who consumes them, which security controls apply, and which environments must stay available during cutover. Engineers will need access to exported API definitions, gateway configuration, certificate stores and the infrastructure where the new platform will run. Confirm with IBM in writing which export formats and support commitments apply to your release, because those answers set how much manual rework remains. Ask your provider to name the internal roles they expect from your side, such as an owner for each API domain and a security approver.
Do we need a Gravitee Enterprise license or WSO2 subscription to run the target platform?
You do not need a paid license to start with the open-source builds, but you should confirm which features you require and whether they fall under a commercial edition. Gravitee's documentation states that the APIM Enterprise Edition requires a license, and lists features such as data masking, GeoIP filtering, Dynamic Client Registration, the Alert Engine, Redis caching and several enterprise protocol endpoints. WSO2 API Manager is Apache-2.0 licensed, while WSO2 sells commercial subscriptions that provide expert support, continuous product updates, vulnerability monitoring and access to the licensed distribution for commercial use. Map each API Connect capability you use today to the edition that provides it, then ask the vendor to confirm the license terms for your production use. Subscription costs should appear as a separate line in your cost comparison.
How do we get a quote based on a written scope?
A reliable quote starts with a written scope that lists the APIs, products, consumer organizations, gateways, environments, integrations and compliance evidence in the work. DeployOpen does not publish a price list; a quote follows from the agreed written scope, deliverables and timelines. To make comparisons fair, ask each provider to quote the same scope for the V12.1 upgrade and for the open-source migration, and to separate one-time project work from recurring support, upgrades and infrastructure. Include an inventory export, a list of integrations and security requirements in the request, and ask what is excluded. Retainers for ongoing support, upgrades and continuous testing can be priced as a separate line so that the recurring cost is visible.
Evidence an auditor will ask for during the change
Moving API Connect off v10 changes the configuration, the credentials and the gateway path that auditors and internal control owners rely on. The cards below list the records to assemble before, during and after cutover, so the upgrade or migration can be shown to have been planned, tested and approved.
Change records and approvals
Keep a written change record for each wave: scope, owners, the rollback point, approvals and the go or no-go decision. For an upgrade to V12.1, record the target version and the fix status of the V10 release you start from, since 10.0.5 has been out of fix support since June 2025 and 10.0.8 is the last V10 LTS. Auditors will ask who approved moving production traffic and what evidence that approval relied on.
Configuration exports and version baselines
Export API definitions, products, plans, assemblies, gateway scripts and TLS and policy settings from the source environment, and store them with a hash and a timestamp. Compare the exported baseline against the target configuration after each build. Where the target is WSO2 API Manager or Gravitee, show how each API Connect policy maps to its equivalent, and flag any policy with no direct match as an accepted gap.
Cutover test results
Retain functional, security and performance test results for each migrated API, run against the new gateway with production-like data and consumer applications. Include negative tests for authentication failures, rate limits and malformed requests. A test result is only useful to an auditor when it names the build it ran against and the person who accepted the outcome.
Credential reissue and access logs
Record every client credential, certificate and API key that is revoked, reissued or re-bound during the change, with the owner who received it and the date it took effect. Keep administrator access logs for the Developer Portal, the Manager console and the gateway, showing who changed what during the window. Confirm that old credentials stop working on the agreed date.
Vendor support and license evidence
Keep the support status of the current API Connect release, the contract or entitlement that covers it, and any extended support terms in effect during the transition. For an open-source target, keep the license texts and the version or tag deployed, and record whether any enterprise features in use require a commercial license, as Gravitee documents for its Enterprise Edition. Ask the vendor to confirm dates in writing.
How DeployOpen approaches an API Connect exit
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure, whether that is a cloud account, a data center or an air-gapped network. For an API Connect estate, that means the work starts with an inventory rather than a platform choice: the API Connect organizations, catalogs, products, plans, consumer organizations, applications, and the DataPower or other gateways that enforce them. That inventory determines whether the V12.1 upgrade or a move to WSO2 API Manager or Gravitee is the right project, and it gives you the scope document any engagement needs.
Work is delivered under a fixed-scope written agreement. Scope, deliverables and timelines are agreed in writing before work begins, and a quote follows from that scope, so the first decision you own is how much of the estate is in it. Typical scope items for this topic include exporting OpenAPI definitions, mapping assembly policies and gateway scripts, setting up the gateway and control plane on your Kubernetes or virtual machine platform, hardening it, configuring backups, and writing the runbooks your operations team will use. Ask for each item to be listed with an acceptance check, such as a consumer calling a migrated API through the new gateway with the same credentials policy.
Ongoing support, upgrades and continuous testing are available as retainers. For a platform you will run after the project, a retainer is the practical place to cover security patching, version upgrades and periodic security testing of the APIs. DeployOpen also prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications; independent auditors and certification bodies do that. Before you sign, confirm with your own assessor which evidence they will need from the new gateway, and confirm who on your side owns each runbook after handover.
