Edge to Apigee X: What Happens to Your Developer Portal Accounts

When teams plan an Apigee Edge to X migration, the proxy inventory gets all the attention. Policies, networking, and cutover plans fill the runbook. The developer portal, and specifically the developer accounts inside it, is usually an afterthought. That is a mistake, because the accounts are the one thing that does not come along for free.

What does not migrate

Here is the blunt version. Developer accounts and their passwords registered in the Edge integrated portal do not migrate to the X integrated portal. There is no button that brings them across. Unless your developers authenticate through an external identity provider, every account has to be recreated, and every developer has to set a new password or re-register.

For a portal with a handful of internal developers, this is a minor annoyance. For a public portal with hundreds or thousands of registered partners, it is a project with a communications plan, a support load, and a real risk of partner churn if it is handled badly.

Why it works this way

The integrated portal has no management API for its content or its accounts. The portal state is not scriptable, which is the same root cause behind several other integrated-portal limits we have documented separately. Without an API to read accounts out of Edge and write them into X, there is no clean automated path. The data simply is not portable through a supported interface.

The clean path: externalize identity first

If your Edge portal already uses SAML or SSO with an external identity provider, you are in good shape. Point the X portal at the same identity provider and your developers keep their existing credentials. They log in to the new portal with the same account they always used, because the account never lived in Apigee in the first place. It lived in your IdP.

If you are not on SSO yet, the highest-leverage move before migrating is to externalize identity. Stand up SAML or SSO against your IdP on the Edge portal, move developers onto it, and then migrate. You convert a painful re-registration into a non-event.

Rule of thumb: if identity lives in Apigee, it does not migrate. If identity lives in your IdP, it does. Get your accounts out of Apigee before you move.

If you cannot externalize in time

Sometimes the timeline does not allow an IdP project before the gateway migration. If you have to re-register developers, plan it like a product launch. Export your developer and app inventory from Edge first, so you know exactly who needs to come across and which API keys are in play. Send advance notice with a clear deadline and a simple re-registration flow. Expect a support spike and staff for it. Watch for app credentials that need to be reissued, because a developer logging in again is not the same as their applications keeping their keys.

A short playbook

1.Inventory developers and apps. Pull the full list from Edge before you touch anything, including app credentials.
2.Decide SSO or re-register. SSO is almost always the better answer if you can fit it in.
3.Externalize identity. Move accounts into your IdP and point both portals at it.
4.Recreate content. Portal pages and styling are manual, so budget the rebuild time.
5.Validate before cutover. Confirm logins, app keys, and documentation all work for a pilot group first.

Where a managed portal helps

A managed portal that connects to your Apigee organization externalizes identity from day one and removes the manual content rebuild. Centauri Launchpad does both. It reads your Apigee X organization, handles SSO and RBAC, and gives you a branded portal without the account-migration scramble. It is the approach we landed on after running these migrations the hard way.

For the broader migration picture beyond the portal, see our Apigee X migration guide, and for the full set of integrated-portal ceilings, see the complete 2026 list of limitations.