Migration is an operating model decision

Apigee Edge to Apigee X migration looks technical on the surface: export proxies, map environments, recreate products, migrate apps, validate OAuth, and cut traffic. The deeper challenge is that Edge estates usually carry years of decisions optimized for urgent delivery. Those decisions become visible during migration as unclear product ownership, inconsistent app approvals, missing developer records, duplicated credentials, stale portal accounts, and policies that no longer match the risk profile of the APIs they protect.

What good looks like

A successful migration starts by defining the target operating intent. Which APIs should remain public, partner-only, or internal? Which products require explicit approval? Which apps should be blocked, revoked, or retired before cutover? Which developers should move to an external identity provider instead of being recreated as platform-local users? The migration plan should answer these questions before scripts are written.

Practical controls

  • Inventory APIs, products, companies, apps, developers, and credentials before build migration.
  • Carry forward source approval and revocation status instead of defaulting to approved.
  • Validate OAuth token behavior before the DNS or routing cutover.
  • Separate platform migration from cleanup decisions so business owners can approve exceptions.

The objective is not simply to run on Apigee X. The objective is to run with less ambiguity after migration than before it.