Migrate from Apigee to WSO2 API Manager: what the move involves
Moving from Apigee to WSO2 API Manager is a re-platforming of API products, proxies, policies, developers and quotas, not a file copy. The exported proxy bundles are a starting point, but the publisher objects, subscription tiers, application keys and throttling rules have to be recreated and then tested against live traffic. Most teams start with a renewal, a hosting or data residency requirement, or the end of life for Apigee Edge for Private Cloud. That last date, 4.53.01 reaching end of life on June 30, 2027, is one trigger among several, so confirm your own contract and residency constraints before you set a timeline. A platform team usually owns the work, with an implementation partner covering mediation rebuilds, the developer portal setup and cutover. Effort depends mostly on how many Apigee policies carry business logic, how many developer apps hold live keys, and how many environments must be migrated in sequence. Risk concentrates in quota and throttling behavior, which will not match Apigee's exactly, so plan a parallel run and agree in writing how throttling differences will be handled.
WSO2 API Manager is Apache-2.0 licensed and splits the work across four components: the Publisher, where APIs and products are defined, the Developer Portal, where consumers subscribe and manage keys, the gateway, which handles routing, mediation and security, and the traffic manager, which applies throttling. Map each Apigee product to a WSO2 API with its subscription policies, then decide which Apigee shared flows become custom mediation or extensions. The WSO2 API Manager repository lists the supported API types and extension points, which is the right reference when you scope custom work. Before you commit, confirm three things with WSO2: which deployment model fits your hosting rules (self-hosted, hybrid, or managed), what support and update terms the commercial subscription includes, and whether your team can build and run the JDK 21 based stack. The commercial subscription is optional for the core product, but it is worth pricing against the operational burden of patching and supporting the platform yourself.
Which Apigee capabilities map cleanly to WSO2 API Manager
This table compares the main Apigee capabilities with the WSO2 API Manager components that cover them, marking each row as clean, needs rework or gap. Use it to scope the migration: clean rows move with light effort, rework rows need custom mediation or redesign, and gaps need a decision before cutover. Confirm each policy equivalent against the WSO2 documentation for your exact version, since 4.7.0 (released April 29, 2026) requires JDK 21.
| Apigee capability | WSO2 API Manager equivalent | Status and notes |
|---|---|---|
| API proxies and revisions | Publisher (API definition) and gateway (routing, mediation) | Needs rework. Proxy flows must be rebuilt as WSO2 APIs with mediation sequences; export proxy bundles first to use as a reference. |
| API products and bundling | Publisher API products with subscription tiers | Clean. Product grouping maps well, but confirm how plans and visibility settings translate for your portal audience. |
| Developer apps and API keys | Developer Portal applications and subscriptions with OAuth2 keys | Clean. Keys must be reissued or migrated; plan a credential rollover with each consuming team. |
| Verify API key and OAuth policies | Gateway security with OAuth2 and API key handling | Clean for standard flows. Custom key validation logic needs a custom authenticator, which WSO2 supports as an extension. |
| Quota and spike arrest policies | Traffic manager throttling policies | Needs rework. Throttling concepts align, but limits and counting scopes must be recreated and tested per tier. |
| Developer portal | Developer Portal web interface | Needs rework. Portal content, branding and docs must be rebuilt rather than exported from Apigee's portal. |
| Analytics and reporting | Built-in API analytics with optional external observability | Gap for business reporting. Confirm the analytics your finance and product teams rely on and plan extra reporting work. |
| Environments and promotion | Gateway environments managed from the control plane | Needs rework. Map Apigee environments to WSO2 gateway environments and define a promotion process. |
| Monetization | Monetization module, outside the Apache-2.0 open-source license | Gap. Monetization requires a WSO2 commercial subscription or a custom build; decide this before design. |
What data and integrations to move, and how to export them
Apigee configuration reaches WSO2 API Manager through several distinct artifacts, and each one moves differently. Proxy bundles, product and app definitions, credentials, backend targets, custom code and identity connections all need a decision before cutover. The documented export path for proxy bundles and related entities is covered on the Apigee export page.
Proxy bundle exports
Export each API proxy revision as a bundle before you change anything in Apigee, and keep the bundles in version control. The bundles hold the proxy endpoints, flows, policies and resources, which you will read to rebuild the WSO2 API definitions and mediation sequences. Confirm that you have the revision each live environment actually runs, not only the latest revision in the editor. Use the Apigee export page for the documented path and the IAM permission it needs.
Products and developer app definitions
Export API products, their quota settings, and the list of developer apps subscribed to each product. In WSO2 API Manager these map to API definitions, subscription tiers and applications, so the mapping must be written down before import. Check which products carry scopes, quotas and environment restrictions, because those settings do not map one to one. Confirm with WSO2 how each tier and throttling policy will be configured in your version.
API keys and client credentials
Do not copy Apigee consumer keys and secrets into WSO2 as plain text. Treat every key as compromised for the purpose of migration, issue new credentials in WSO2 for each application, and give developers a dated switchover window. Rotate any backend credentials that the gateway used, and store the new values in your secrets manager. Developer passwords and portal secrets are not re-exported as-is, so developers must set up their accounts again in the new portal.
Target servers and backend endpoints
Inventory every target server and target endpoint that proxies call, including environment-specific URLs, load balancers and TLS settings. Move these into WSO2 endpoint definitions and confirm the trust stores, client certificates and timeouts for each one. Environment variables and property values need the same review, because a missing value can fail silently in a lower environment. Record the owner of each backend so connection tests have a named contact.
Custom Java callouts and JavaScript
List every Java callout, JavaScript step, Python step and custom policy in the proxies, since these carry business logic that no standard mapping will recreate. WSO2 API Manager supports custom authenticators, policies and workflows, so each custom step needs a deliberate target: a WSO2 mediation sequence, a custom handler, or a backend change. Review the code for hard-coded secrets, unsupported libraries and dependencies on Apigee-only objects such as the key value map. Plan tests for each one.
Backend systems and identity providers
Reconnect the identity provider that Apigee validated tokens against, along with OAuth or JWT settings, client certificate checks and any SAML or LDAP sources. Confirm the issuer URL, audience, key sets and token lifetimes with the identity team before the first WSO2 test. Each backend system then needs its connection re-tested from the new gateway, with allowlists and firewall rules updated for the WSO2 gateway addresses. Record the sign-off from each owner.
How Apigee policies and flows are rebuilt in WSO2 mediation
The rebuild is where most of the engineering time goes, so start by inventorying every Apigee flow and policy before anyone writes WSO2 configuration. Apigee proxies execute request and response flows, conditional flows that run on a condition, and shared flows reused across proxies. In WSO2 API Manager, the equivalent logic lives in mediation sequences attached to the gateway and in policies defined for each API, so a shared flow usually becomes one reusable sequence or policy rather than being copied into every API. Record, for each proxy, which flows it calls and in what order, because execution order is where translations most often drift.
Triage each policy into one of three groups. Direct equivalents cover routing, JWT or OAuth validation, quota and spike handling, and header or query manipulation, which WSO2 handles through built-in mediation and the traffic manager. Scripted logic covers JavaScript callouts, custom key checks or data transformations that have no built-in match; these need custom mediators, authenticators or policies, which WSO2 supports as extension points. Items to drop are policies that only existed to work around Apigee-specific behavior or that duplicate a platform feature you will not use. Confirm each group with the WSO2 documentation for the release you deploy, since mediator names and extension APIs change between versions.
Test every rebuilt flow against recorded traffic, not only against hand-written cases. Capture representative Apigee request and response pairs, including error responses, replay them through the WSO2 gateway, and compare status codes, headers, payload transformations and throttling decisions. Pay particular attention to conditional flows that fire only on rare paths and to quota counters, which must be checked for reset behavior. Keep a written sign-off per proxy so the security and platform owners can see which behavior was verified and which was consciously dropped.
The migration sequence from inventory to decommission
This sequence moves Apigee proxies, products, developers and quotas to WSO2 API Manager in controlled stages, so each environment has a tested rollback path before Apigee is switched off. Each step produces a written record that the next step depends on.
Build the inventory register
Export every API proxy revision, shared flow, API product, developer, app, key and quota configuration from each Apigee environment, using the bundle export and apigeecli approach described in the export guide. The platform team and the API owners review the export together and record, for each API, its consumers, traffic pattern, authentication method, policies used and business owner. Done means every proxy and product appears in one register with a named owner and a status of keep, rebuild or retire. Ask Google or your Apigee administrator to confirm which entities your organization can export under its IAM roles before work starts.
Classify policies and mediation logic
Walk through each Apigee policy in the register and map it to a WSO2 API Manager mediation sequence, traffic manager throttling policy, or custom extension. Policies that rely on Java callouts, JavaScript, or Apigee-specific features need a design decision and an estimate agreed with the engineering lead before they are scheduled. The output is a policy mapping sheet that lists each Apigee policy, its WSO2 equivalent or extension, and the owner who will build or verify it. Confirm with WSO2 which mediation and extension points your chosen version supports.
Run a pilot on a low-risk API
Choose one API with modest traffic, few consumers and no critical financial or health data. Deploy WSO2 API Manager in the target model, whether on premises from extracted packages, on Kubernetes through the WSO2 API Platform for Kubernetes, or as a managed cloud service, and publish the pilot API through the Publisher with its Developer Portal listing. Invite a small group of developers to register an application and obtain keys. The pilot report records functional parity, throttling behavior, developer onboarding steps, latency and error rates, and the issues found. Close the step when the report is reviewed and the open gaps have an owner.
Parallel run with mirrored or split traffic
Route a defined share of production calls to WSO2 API Manager while Apigee continues to serve the rest, using traffic mirroring where the backend tolerates duplicate calls or a split at the DNS or load balancer layer where it does not. Compare response codes, payload content, throttling outcomes and latency between the two gateways over the agreed observation window. The parallel-run comparison is a signed-off table of differences, each either fixed or accepted with a documented reason. Do not begin cutover until the team has agreed the acceptance criteria in writing.
Write the staged cutover runbook
Prepare a runbook for each environment, starting with non-production and ending with the most critical production APIs, specifying the order of consumer migration, DNS or gateway changes, credential reissue, quota reconciliation and communication to developers. Each runbook step names an owner, a check and a rollback action that returns traffic to Apigee. Developer migration is the hardest part, so the runbook should state how existing API keys and quotas are re-established or transferred. Confirm the approved runbook with security, operations and the API product owners before the first production switch.
Hold a rollback window and decommission Apigee
After the final environment cuts over, keep Apigee in read-only standby for a rollback window agreed in advance by the business and operations teams, so traffic can return if a defect appears. Review logs, quota usage and developer support tickets during that window. When no rollback is needed and the agreed criteria are met, export final configuration and audit records, retain them according to your records policy, cancel or reduce the Apigee subscription with your Google account team, and remove access for Apigee users and service accounts. The decommission record lists what was exported, where it is stored, who approved the shutdown and the date the subscription ended.
How the move differs by starting point
Edge for Private Cloud is the most time-sensitive starting point because the version line has a published end of life. Apigee documentation states that Apigee Edge for Private Cloud 4.53.01 reaches end of life on June 30, 2027, after which Apigee stops providing bug fixes, security updates, hotfixes or patches for that line, and continuous support requires running a version within its 18-month full support window. Your migration plan therefore has to set a decision date before that deadline, and the export and rebuild work runs alongside whatever you do to keep the current platform supported.
- Export before anything else: Pull proxy revisions, shared flows, products, developers and apps from the management API while the source platform is still fully available.
- Confirm your support position: Check with Apigee which version and support window applies to your installation before you set the cutover date.
- Plan a parallel run: Keep the Edge runtime serving production while WSO2 API Manager gateways take over one API product at a time.
- Map Edge-specific policies early: Mediation that depends on Edge-only extensions or Java callouts needs a rewrite in WSO2 mediation or a custom extension.
- Keep the on-premises constraint in view: Because the old platform runs in your own data center, the WSO2 deployment is also on premises, so capacity and patching ownership move with the workload.
Check the end of life date and your current support entitlement with Apigee first, since they determine how much time you have for each step.
With Google-managed Apigee, Google operates the control plane and the runtime, so your team owns the API definitions, developer relationships and every decision about where traffic should go. Moving away means you take over the runtime as well, which adds hosting, certificate, scaling and upgrade work that was previously invisible to you. The sequence usually starts with inventory and traffic analysis, because you cannot reproduce a managed environment without knowing which proxies receive production calls.
- Start with traffic, not configuration: Identify which proxies and environments are live, and which are idle, before deciding what to rebuild.
- Stand up the gateway estate first: Provision WSO2 gateways and the control plane in your own infrastructure so that traffic can be shifted in stages.
- Replace managed features deliberately: Analytics, monetization and portal features behave differently in WSO2 and need explicit owners.
- Confirm the deployment model with WSO2: Self-hosted, hybrid and managed SaaS options exist, and the choice changes who operates each plane.
- Expect a dual-running period: Keep Google-managed traffic routed through Apigee until WSO2 proves each product in production.
Confirm with your team which Apigee features your applications rely on in production, because that list drives most of the scope.
In Apigee hybrid, Google hosts the management plane while you run the runtime plane on your own Kubernetes clusters. Migration therefore has two halves that change at different speeds: the runtime you already operate can be moved or retired gateway by gateway, while the management plane and its configuration still sit in Google's service. Your cutover plan must account for both, including how API definitions are exported from a management plane you do not run.
- Separate the planes in the plan: Track runtime migration and management data export as distinct workstreams with separate owners.
- Reuse Kubernetes skills: Your platform team already runs gateway pods, so WSO2 gateways on Kubernetes fit an existing operating model, though WSO2 Kubernetes deployments use a separate WSO2 API Platform for Kubernetes product that you should evaluate.
- Move one environment at a time: Start with a non-production environment so that traffic routing and certificates are proven before production.
- Check control plane dependencies: Confirm which functions stop working if the Google-hosted management plane is unavailable during cutover.
- Validate data residency claims: Document where configuration, analytics and logs travel in the hybrid setup before deciding what the target must keep on premises.
Confirm with Google and WSO2 which Apigee management data can be exported and in what format before you commit to a cutover date.
Organizations with many developers, partner apps and quota plans spend most of their migration effort on subscriptions, keys and usage history rather than on routing. Developer accounts, app registrations, API products and rate plans have to map to WSO2 subscriptions and throttling policies so that partners keep their credentials or receive a controlled re-issue. Traffic manager policies also need to match the quota commitments you have already made, so the sequence is driven by business agreements as much as technical ones.
- Inventory products and plans: List every API product, quota tier and partner agreement, then map each to WSO2 throttling and subscription policies.
- Decide on credential continuity: Choose whether existing keys are preserved, reissued or run in parallel, and communicate the decision early.
- Migrate developers in waves: Move the developer portal audience by group so support load stays manageable.
- Rebuild usage reporting: Historical quota consumption often sits in Apigee analytics, so decide what must be exported for billing or audit.
- Involve commercial owners: Partner contracts and rate commitments may require sign-off before any quota changes.
Confirm with WSO2 how its traffic manager handles the specific quota models you run before you model the mapping.
Teams with a small number of internal APIs and few external consumers can usually move in fewer phases. The main work is rebuilding the mediation logic and the security settings for a short list of services, and the developer portal may serve only internal teams. Because the audience is limited, the cutover can happen per service with a short overlap period, and the decision to keep or drop features such as monetization carries little commercial weight.
- Export and rebuild in one pass: Export proxy bundles, review each policy, and rebuild them in WSO2 mediation within a single project.
- Simplify the portal scope: Internal developers may need only API documentation and access approval, not a full self-service catalog.
- Confirm which features you need: If you do not use monetization, the open-source edition may cover your requirements without a subscription.
- Cut over service by service: Move low-risk internal services first and keep a rollback route to Apigee during the overlap.
- Keep operations simple: A single gateway cluster in your infrastructure may be enough, but confirm the sizing with WSO2 for your traffic.
Confirm with your internal consumers which services they call and how often, since that shapes the cutover order more than the platform choice does.
What drives cost and duration in this migration
This table lists the factors that move the cost and calendar of an Apigee to WSO2 API Manager move, with the one-time or recurring nature of each and what to ask for in a quote. Read it as a checklist for scoping: the larger and more customized your proxy estate, the more each row matters. No figures are given here, so use the quote request column to compare proposals on the same basis.
| Driver | Why it changes cost or effort | What to ask for in a quote |
|---|---|---|
| Proxy and policy count | Each proxy, shared flow and policy chain must be exported, mapped to WSO2 APIs and mediation sequences, and tested. Volume and branching logic set most of the build effort. | A per-proxy inventory with policy types, and the mapping approach for each policy family |
| Custom Java or JavaScript extensions | Apigee JavaScript and Java callouts have no direct equivalent. They must be rewritten as WSO2 mediators, custom policies or external services, which usually adds design and test work. | Count of custom code artifacts, the target extension method, and who owns testing of each one |
| Developers, apps and subscriptions | Developer accounts, app registrations, API keys and subscriptions must be recreated or migrated, and approval workflows may need custom configuration in the Developer Portal. | How credentials are migrated or reissued, and whether developers must re-register |
| Quota and throttling design | Apigee quotas and spike arrests must be translated into WSO2 traffic manager policies. Redesigning tiers and per-app limits takes decisions from the business, not only engineering. | Whether throttling policies are mapped one to one or redesigned, and the testing of limit behavior |
| SSO and identity integration | Connecting the publisher, developer portal and gateway to your identity provider, OAuth2 flows and token validation adds configuration and security review. | The identity provider versions supported, token flows covered, and the security test scope |
| Environment count | Each environment (for example development, test, staging and production) needs its own deployment, configuration promotion and validation. | The number of environments, the promotion method, and whether infrastructure is provisioned as code |
| Parallel-run length | Running Apigee and WSO2 side by side keeps two gateways, two sets of traffic routing and duplicate monitoring alive for the overlap period. The longer the overlap, the higher the recurring cost. | The proposed overlap period, cutover criteria, and rollback steps for each API group |
| WSO2 subscription | A commercial subscription adds a recurring fee from WSO2 for expert support, continuous updates, vulnerability monitoring and the licensed distribution for commercial use. Without one, your team carries patching and support. | Whether the quote includes a WSO2 subscription, its scope, and the support response terms in writing |
| Internal skills and ownership | Teams new to Java-based WSO2 deployment, Kubernetes and Apigee policy translation need training or outside help. Ongoing upgrades and on-call response are recurring labor costs. | Named roles on each side, knowledge transfer deliverables, and the post-migration support model |
What usually goes wrong and how to prevent it
Most failed Apigee to WSO2 API Manager migrations break in predictable places: translated logic, throttling, credentials, backend behavior and scope. Each card below names one risk and the check that catches it before traffic moves.
Lost or mis-translated policies
Apigee policies such as JavaScript, Python, Service Callout, Assign Message and conditional flows do not map one to one onto WSO2 mediation sequences. A policy can be dropped silently or reproduced with different ordering, so a request may pass through a step it should not. Export every proxy revision as a bundle and build a policy-by-policy mapping sheet before writing any sequence. Confirm each mapped behavior with a test request.
Quotas that do not reproduce throttling
Apigee quota policies, spike arrests and rate limits are configured per proxy, product or app, and WSO2 applies throttling through its traffic manager with its own policy tiers and levels. Counters, time windows and the scope a limit applies to can differ, so consumers may be throttled earlier or later than before. Write down each Apigee quota as a WSO2 throttling policy with its window and key before cutover. Replay peak traffic against both platforms to compare the 429 responses.
Developers losing keys at cutover
Consumer keys and secrets issued in Apigee do not automatically become WSO2 application credentials, and partners often hardcode them into their clients. A cutover that rotates keys without notice breaks integrations on the first day of traffic. Plan a dual-validity window in which both key sets are accepted, and notify each developer app owner with a dated checklist. Confirm how the Developer Portal handles existing subscriptions before the migration plan is approved.
Backend assumptions in mediation
Apigee proxies often hide backend details such as hostnames, header casing, timeouts, TLS trust stores and payload shapes that the backend quietly depends on. Replaying those calls through a WSO2 gateway can change a forwarded header, a content type or a retry behavior. Capture real request and response samples from Apigee and diff them against WSO2 output for each endpoint. Ask the backend owners to confirm which headers and timeouts their services actually use.
Unmanaged scope creep
Migrations tend to grow when teams add monetization, new analytics, extra APIs or a redesigned portal during the move. Each addition multiplies the mapping work and makes it harder to tell whether a difference comes from the platform or from a new feature. Freeze the migration scope in writing, list each deferred request in a backlog, and approve any change through a single owner. Confirm early which Apigee features the WSO2 subscription covers and which need separate work.
Insufficient parallel-run testing
Running WSO2 only in a lab proves little, because production traffic patterns, certificates, network paths and consumer behavior are absent. Teams that skip a parallel run discover differences only after customers do. Run both gateways side by side on mirrored production traffic for a defined period, and compare status codes, latency and quota decisions per API. Agree the exit criteria with the API owners before the parallel run starts.
Running unsupported versions
Apigee Edge for Private Cloud customers face end of life for version 4.53.01 on June 30, 2027, and an unsupported Apigee estate can leave teams with unpatched components during a long migration. Equally, a WSO2 deployment built on an old release becomes hard to patch. Record the Apigee version in use, set the cutover date ahead of its end of life, and pin WSO2 to a release line your team can patch on schedule. WSO2 API Manager 4.7.0 requires JDK 21 to build, so check that requirement in your build pipeline.
When a WSO2 commercial subscription is worth adding
The WSO2 subscription is an add-on to the Apache-2.0 product, not a different codebase. According to WSO2's repository, a commercial subscription for API Manager provides expert support, continuous product updates, vulnerability monitoring and access to the licensed distribution for commercial use. The open-source release gives you the gateway, Publisher, Developer Portal and traffic manager without a license fee. What you pay for is someone else carrying the operational load: triaging defects, shipping fixes on a predictable cadence and telling you when a component in your deployment has a known vulnerability. Before you migrate, ask WSO2 for a written description of the support terms, response commitments and the exact distribution rights that apply to your organization, because those are the points a quote should be measured against.
Decide internally first whether your team can patch and monitor the stack itself. If you already run a vulnerability feed against your Java runtimes, container images and the Kubernetes or VM hosts, and you can rebuild and redeploy WSO2 API Manager 4.7.0 (which requires JDK 21) on a fixed schedule, the subscription is less urgent. If that capability does not exist yet, plan for it or buy it. Compliance is the second factor. Some assessors and internal policies expect a named vendor responsible for security patches and an escalation path for production incidents. Confirm with your auditor and your control owners which of those expectations apply before treating open source support as sufficient. The third factor is deployment shape. WSO2 supports on-premises installs, a managed cloud service and a hybrid model with a SaaS control plane and on-premises gateways. Choose the shape first, then check which of those options the subscription covers.
Plan the Monetization module separately. WSO2 states that its API Platform components are open source under Apache-2.0 except the Monetization module. If your Apigee use includes monetization or paid API products, you will not get that capability under the open-source license, so price it as a distinct line in any WSO2 quote and confirm its licensing terms in writing. If you do not use monetization, the license boundary does not change your migration plan, but record it in your architecture decision so the next audit does not surprise anyone.
Questions buyers ask before migrating from Apigee to WSO2
How long does a migration from Apigee to WSO2 API Manager take?
The duration depends mainly on how many API proxies, products and environments you run, how much of the Apigee logic is custom JavaScript, Java callouts or complex flow control, and how many developers and applications must be onboarded again. A team with a small, well-documented set of proxies and a single environment will move much faster than one with dozens of shared flows and several production regions. Plan for a parallel run in which Apigee and WSO2 serve the same APIs, because cutover is safer that way. No duration can be given here without an inventory of your own estate, so ask any provider for a timeline built from that inventory and written into a fixed scope.
What does a migration to WSO2 API Manager cost, and who gets paid?
Costs fall into four groups: the infrastructure to run the gateway, traffic manager, control plane and portal; the one-time work of exporting, rebuilding and testing APIs and policies; the ongoing operation of the platform; and any commercial subscription. The software itself is Apache-2.0 licensed, so the license line is zero for the open-source distribution. WSO2 sells subscriptions for expert support, continuous product updates, vulnerability monitoring and a licensed distribution for commercial use, and that is the main recurring license cost to weigh. When you request a quote, ask for each component to be priced separately, including infrastructure sizing, migration effort, testing, documentation and support hours.
Can our own team migrate from Apigee to WSO2 without a partner?
Yes, a capable platform team can do it, provided it has people who understand the Apigee proxies being moved, Kubernetes or Linux operations, Java runtime support (WSO2 API Manager 4.7.0 requires JDK 21 to build), and security review of the gateway configuration. The usual gaps are not in the install but in mapping Apigee policies that have no direct equivalent, rebuilding developer onboarding, and proving that controls behave the same after cutover. A partner is most useful when those gaps are large or when a deadline is fixed. DeployOpen plans, implements, integrates, hardens and documents self-hosted platforms in your own infrastructure under a written scope, so you can choose to hand over a defined part of the work.
Do developers have to register again after moving to WSO2?
In most cases, yes, developers and applications need to be recreated or re-linked in the WSO2 Developer Portal, because the subscription and application records live in the new platform. You can reduce the friction by exporting the list of applications, their owners and the APIs they subscribe to from Apigee before the move, then pre-creating accounts and subscriptions so developers only confirm them. Whether existing client IDs and secrets can be carried over is something to verify against your identity setup and the WSO2 documentation for your version, not assumed. Plan a communication window and a rollback path so consumers are not blocked during the switch.
How are API keys, quotas and throttling handled in the move?
Quotas in Apigee are usually expressed through quota policies and product-level limits, while WSO2 uses its traffic manager for throttling policies at the subscription, application and API levels. These models do not map one to one, so each quota must be rebuilt and tested with real request patterns. Keys are a separate question: whether an existing key can be reused depends on the signing and validation approach you choose, so confirm it early with a proof of concept. Expect to set rate limits in WSO2 deliberately rather than copying Apigee numbers blindly, and keep a record of which consumer received which limit for audit purposes.
Does WSO2 support hybrid or managed deployment as well as self-hosting?
WSO2 documents three deployment models for API Manager: self-hosted on premises from extracted packages, a managed cloud service, and Kubernetes through its separate API Platform for Kubernetes. WSO2's product page also describes a hybrid model with a SaaS control plane and on-premises gateways, and a fully managed SaaS option with a 99.95% SLA. If data residency or control of the control plane matters, confirm which model keeps the components you need inside your boundary. The open-source distribution is the self-hosted path; the managed and hybrid options are commercial, so verify terms directly with WSO2 before assuming what they include.
What happens to Apigee analytics and monetization after the move?
Apigee analytics and monetization do not move as features; you rebuild them. WSO2 API Manager provides a traffic manager for throttling and API usage through its own tooling, but reporting dashboards, business KPIs and billing workflows need to be designed and integrated with your data stack, typically by exporting gateway logs and metrics. Monetization is a separate WSO2 module that is not covered by the Apache-2.0 license for the open-source platform, so check its licensing and scope before planning revenue flows on it. Ask any implementer to list each Apigee analytics report and monetization rule and state whether it is rebuilt, replaced or dropped.
How DeployOpen scopes and runs the move
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure, whether that is their cloud accounts, data center or air-gapped network. For an Apigee to WSO2 API Manager move, that means the work runs in the environments the client already controls, with the Publisher, Developer Portal, gateway and traffic manager deployed where the client's APIs and developer data are allowed to live. Most engagements are fixed-scope, and the scope, deliverables and timelines are agreed in writing before any work starts. That written scope is the document to hold any vendor, including DeployOpen, to.
A quote follows from the written scope, so the scope should name the inputs that drive effort: the number of API products and proxies to move, how many shared flows and custom policies need rewriting, how many developer applications and keys must be carried across, the number of environments, and whether a WSO2 subscription is part of the plan. Ask for the quote to show these items separately, along with the one-time build and cutover work and any recurring items such as support or upgrades. Confirm with the vendor which environments and identity sources are in scope, and who performs the parallel run and rollback test.
Ongoing support, upgrades and continuous testing are available as retainers, which suits a team that needs to keep the WSO2 platform patched after go-live. Confirm before signing what the retainer covers, including how WSO2 product updates and vulnerability notices are applied, who owns the runbooks for backup and restore, and what documentation is handed over for internal teams. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or attestation, so ask for that boundary to be written into the scope too.
