Apigee Edge sunsetting: what API teams need to do now

Apigee X refers to Google's cloud-native API platform built inside the same environment as Vertex AI and Gemini. In other words, your API programme now runs alongside Google's full AI stack without a separate integration layer. For example, natural language search across your API catalogue is helps to reduce time-to-first-call for new developers. In terms of migration, this process is the layer most teams overlook but it is where AI-powered discovery lives.

TLDR

Apigee Edge end of life is confirmed. The Apigee Classic UI shut down in November 2025; the final Private Cloud version reaches EOL in February 2027. Apigee X is cloud-only, replaces Edge RBAC with Google Cloud IAM, and drops the Drupal portal entirely making this a re-platforming exercise, not an upgrade. The developer portal is the dependency most migration plans underestimate. Google's Integrated Portal is documentation-only: no self-serve key provisioning, no custom branding, no AI-powered discovery. Teams with active external developer programmes will hit those limits fast and face a second migration within 12–18 months. The Apigee Edge EOL window is the right moment to replace the portal properly with a purpose-built platform that launches in days and stays stable while the gateway migration is still in progress.

Ready to replace your Apigee developer portal before the deadline? Book a demo with DigitalAPI teams go live in 3 days.

What is the Apigee Edge sunset?

Google acquired Apigee in 2016 and has been systematically replacing Edge with Apigee X its cloud-native successor, fully integrated with Google Cloud Platform. The Apigee Edge end of life process is now in its final stages, with formal end-of-support dates confirmed across all deployment types.

EOL timeline by version:

After each end-of-support date, Edge receives no features, bug fixes, or security patches. Most enterprises treat these dates as hard migration deadlines given the compliance and security exposure of running unsupported infrastructure.

The Apigee Edge deprecation is best understood as a re-platforming effort, not a version upgrade. Two components require deliberate rebuilding regardless of how mature your existing Edge deployment is: identity management and the developer portal.

Note: Check Google Cloud's official deprecation notice for your specific end-of-support date, as timelines have shifted across announcements.

The critical framing here is that this is a re-platforming effort, not merely an upgrade. Apigee X has significant architectural differences that require deliberate planning particularly around identity management and the developer portal.

Apigee Edge vs Apigee X: what changes?

Both platforms share a conceptual model but differ significantly in implementation. Teams familiar with Edge will recognise proxy development and API policy configuration in Apigee X, but several core components require rebuilding from scratch.

Feature comparison

What carries over

Proxy development, API policy configuration, and the core proxy concept transfer between platforms. Teams with existing Edge expertise will find the conceptual model recognisable in Apigee X, though syntax and tooling have evolved.

What requires rebuilding

Identity and access management and the developer portal demand the most significant rethinking. Edge's built-in RBAC and Drupal portal do not transfer to Apigee X both need replacement as part of any migration plan.

The developer portal problem

Most migration guides focus on the gateway layer and overlook a critical dependency: the developer portal must migrate separately from the gateway and on a different timeline.

Apigee Edge included a Drupal-based portal that handled developer registration, API key provisioning, API documentation publishing, and access management. When migrating to Apigee X, that portal does not come with you and support for the Drupal 7 modules ended in January 2023.

The Apigee Integrated Portal limitations

Google offers the Apigee Integrated Portal as a basic replacement. For teams running active external developer programmes, it has meaningful constraints:

• No white-label customisation without additional configuration
• No native self-serve API key management
• No AI-powered API discovery
• Documentation-only experience developers cannot transact from the portal

Teams with serious external developer programmes will quickly exceed the integrated portal's capabilities and face a second migration within 12–18 months. Understanding what makes a strong API developer portal before committing to a replacement prevents that second cycle.

Migration checklist

A reliable migrate-from-Apigee-Edge process runs across four phases. Treating the developer portal as a parallel workstream not an afterthought is the difference between a clean cutover and a drawn-out remediation.

Phase 1: audit current state

• Inventory all proxies, API products, and environments
• Document portal customisations
• Identify all registered external developers
• Map Edge-specific features against Apigee X equivalents
• Identify CI/CD pipelines and scripts targeting Edge APIs
• Note your exact Private Cloud version and its Apigee Edge EOL date

Phase 2: plan parallel workstreams

• Gateway migration assessment
• Identity migration planning (Edge RBAC to Google Cloud IAM)
• Developer portal decision-making
• Developer communication strategy
• Monetisation validation, if applicable

Phase 3: build and test

• Set up Apigee X in Google Cloud
• Run Google's Apigee Migration Assessment Tool to scope proxy complexity
• Rebuild and test proxies lowest-risk first
• Deploy developer portal layer
• Test self-serve onboarding end-to-end
• Validate API key compatibility
• Run parallel traffic testing

Phase 4: cutover and decommission

• Staged, proxy-by-proxy migration
• Communicate cutover timelines to external developers
• Decommission Edge environments after stability period
• Archive Edge configuration for audit purposes

Why this is an upgrade opportunity

The Apigee Edge EOL creates organisational momentum that rarely exists outside a forced migration. Teams that address the developer portal during this window avoid a second re-platforming cycle when integrated portal limitations surface typically 12–18 months post-migration.

There are three realistic portal replacement paths:

Option 1: Apigee Integrated Portal

Lowest-resistance path. Suitable for documentation-only programmes. Not suitable if your developer programme requires self-serve key provisioning, custom branding, or AI-powered discovery. For context on what documentation-only tools can and cannot do, see what is API documentation.

Option 2: custom-built portal

Offers full control but requires a 3–6 month development timeline and ongoing engineering maintenance. Adds significant risk to a migration already under deadline pressure.

Option 3: purpose-built self-serve portal

Launches in days, not months. Handles registration, key provisioning, API cataloguing, and documentation out of the box. Works independently of the gateway layer so it remains stable while the gateway migration is in progress. If you are also evaluating other gateway options alongside this migration, see best developer portal for APISIX gateway and Tyk alternatives for cross-gateway portal considerations.

What to look for in a portal replacement

Evaluating portal options during the Apigee Edge end of life migration window means prioritising capabilities that serve your developer programme beyond the migration itself.

Self-serve API key provisioning

Developers should register, obtain keys, and make authenticated calls without manual team intervention. A documentation-only portal recreates the support burden that the original Edge portal solved. Review the API documentation solution page to understand where self-serve begins and documentation ends.

Gateway independence

During an Apigee Edge-to-X transition, the gateway layer is in flux. A portal that depends tightly on a single gateway creates an additional point of failure. Decoupled portals connecting via standard integrations remain stable throughout the migration.

White-label and custom domain

External developers experience your portal as a product extension. Custom branding and a custom domain should be baseline capabilities, not premium add-ons.

AI-powered discovery

Static documentation navigation does not scale for large API programmes. Natural-language search and MCP agent compatibility allow AI tools to discover and invoke APIs directly future-proofing the portal beyond the migration itself.

Time to launch

Gateway migration has strict deadlines tied to Apigee Edge deprecation timelines. Portal replacement should not extend that deadline. Platforms that launch in days with core features already built in are worth prioritising over bespoke builds.

Frequently asked questions

1. What is the Apigee Edge sunset and when does it take effect?

It is Google's end-of-life announcement for its legacy API management platform. Specific dates vary by deployment type check the official Google Cloud deprecation notice for your environment.

2. What is the difference between Apigee Edge and Apigee X?

Apigee X is Google Cloud-native and cloud-only. It uses Google Cloud IAM instead of Edge RBAC, does not include the Drupal portal, and adds native gRPC and GraphQL support. The core proxy model is similar, but identity management and the portal layer require rebuilding.

3. What happens to my developer portal during migration?

The Drupal portal does not migrate. Google's Integrated Portal offers basic documentation and developer registration only. Teams that need self-serve API keys, custom branding, or AI-powered discovery require a purpose-built replacement.

4. Can I keep using Apigee Edge after sunset?

After end-of-support, Edge receives no features, bug fixes, or security patches. This creates compliance and security risk. Most enterprises treat the end-of-support date as a hard migration deadline.

5. How long does migration take?

Timeline depends on complexity. Small programmes: 6–12 weeks. Complex programmes with hundreds of proxies and external developer bases: 3–6 months minimum. The portal layer frequently represents the longest dependency when teams leave it to last.

6. Is the migration a good time to replace my developer portal?

Yes. The migration creates organisational momentum for a single re-platforming cycle, avoiding a second portal migration later when the integrated portal's limitations become apparent.

7. What is the best portal replacement?

It depends on requirements. Documentation-only teams may find the Apigee Integrated Portal or Redocly sufficient. Teams with self-serve developer programmes should evaluate purpose-built platforms designed for that use case.

‍