What you can export from Apigee and what you cannot
You can export Apigee API proxy revisions as bundle zip files, and the apigeecli tool can also export proxies, shared flows and products. If a renewal, a data residency rule or an exit decision is driving the move, start with these artifacts, then plan separately for everything a bundle does not hold. The bundle route uses the organizations.apis.revisions.get method of the Apigee API with the format query parameter set to bundle. The caller needs the apigee.proxyrevisions.get IAM permission, so confirm that the account running the script holds it in every organization and environment before you start. Each bundle captures a single revision, so list the revisions you still serve and export each one.
apigeecli is an Apache-2.0 tool in Google's Apigee GitHub organization that manages Apigee hybrid and managed entities. Its README states that it is not an officially supported Google product, so agree on who owns its maintenance and pin the version your team tests with. Use it for proxies, shared flows and products, then check its documentation for any other configuration types you need, such as target servers, key value maps or environment settings. Treat the output as a record of current configuration and a working set for rewriting. XML policies in a bundle must be translated into the new gateway's plugins or equivalent configuration, and the output will not load unchanged on another gateway.
Several items sit outside a proxy bundle and need their own export plan. Analytics history is stored in Apigee's reporting layer, so decide which traffic and error data you must keep for audits or contracts, then confirm with Google how long that data remains available and which export methods apply. Developer accounts, app registrations, API keys and secrets should be reissued or migrated through a process your security team approves, never copied into a Git repository. Developer portal content usually lives in a separate system, so inventory its pages, documents and approval flows. If your estate runs Apigee Edge for Private Cloud, note that version 4.53.01 reaches end of life on June 30, 2027, which sets the deadline for this work.
Which Apigee entities export, by method, format and limits
This table compares each Apigee entity you may need to export, the method that retrieves it, the file format it arrives in, and what the documentation confirms about limits. Read it as a checklist: anything without a documented limit should be confirmed with Google or tested in your own environment before you plan a cutover.
| Entity | Export method | Format and permission | Documented limits and notes |
|---|---|---|---|
| API proxy revision | organizations.apis.revisions.get through the Apigee API | Zip bundle when the format query parameter is set to bundle; requires apigee.proxyrevisions.get | Exports one revision at a time, so export every revision you need to keep, not only the deployed one |
| API proxy (latest revisions) | apigeecli apis get or export commands in the apigeecli tool | Zip bundle written to local disk | apigeecli is not an officially supported Google product; check its README for the commands your version supports |
| Shared flows | apigeecli shared flow export commands | Zip bundle, analogous to proxy bundles | Confirm that referenced shared flows are exported with each proxy that calls them |
| API products | apigeecli products export or the Apigee API product endpoints | JSON definition of product settings, quotas and attached proxies | Products define access, not credentials; developer app keys must be exported or reissued separately |
| Developers and apps | Apigee API developer and app endpoints, or apigeecli | JSON records; API key secrets may not be returned in clear text | Confirm with Google how secrets are returned before planning key migration; plan for consumers to rotate keys |
| Environment and target server configuration | apigeecli or Apigee API environment and target endpoints | JSON configuration | Environment-specific values such as hostnames and TLS settings often need manual rewriting for the new gateway |
| Key-value maps and resources | Apigee API environment and organization resource endpoints | JSON or resource files depending on the entity | Check size and count limits for your organization in Google documentation or with your Apigee contact |
| Analytics and logs | Not covered by the proxy bundle export | Stored in Apigee; retrieved through separate reporting interfaces | Export history separately if you need traffic records; no export limits are stated here, so confirm with Google |
Choosing between the Apigee API and apigeecli
The Apigee API is the better fit for a platform engineer who needs precise control over each request, wants to embed export steps in an existing pipeline, or must record exactly which revision was pulled and when. The core call is the revision download method, organizations.apis.revisions.get, which returns a proxy revision as a zip file when the format query parameter is set to bundle. The caller needs the apigee.proxyrevisions.get IAM permission on the organization, so access is granted at the organization level rather than per environment.
- Request-level control: Each revision is fetched by its own API path, so the script decides which proxies, revisions and output folders to use.
- Auditable calls: HTTP responses and logs show exactly what was downloaded, which helps when an auditor asks for export evidence.
- Pipeline fit: The call can run in CI jobs or scheduled tasks alongside other tooling already in place.
- Permission scope: Grant only the proxy revision read permission to the service account, and confirm the role that carries it in the Google Cloud IAM documentation for your organization.
- Extra effort: Pagination, token handling, error retries and file naming must be written and tested by your team.
Before you rely on this path, confirm the exact method name and permission against the current Apigee reference for your release, and test it in a non-production organization first.
The apigeecli tool suits an operator who needs a batch export of many entities with less custom code. Its README states that it manages Apigee hybrid and managed entities, including exporting proxies, shared flows and products. It is an Apache-2.0 project in the Apigee GitHub organization, but its README says it is not an officially supported Google product, so teams should plan their own support and testing for it.
- Batch coverage: One tool covers proxies, shared flows and products, which suits a full inventory export before a migration.
- Less scripting: Operators work from command-line options rather than writing HTTP clients and parsers.
- Same permissions: The identity running the tool still needs read access to the relevant proxies, so IAM design is the same as the REST path.
- Version pinning: Record the tool version used for each export so later runs can be compared and reproduced.
- Unsupported status: Escalations go to your own team or implementation partner, not to Google support, so document the procedure in your runbook.
Before a production export, check the command syntax and output format against the current apigeecli README and confirm which entity types your Apigee deployment model supports.
The choice also depends on whether you are exporting one proxy or the whole organization, and on which environments you must cover. Organization-scoped permissions give access across environments, so decide early whether test and production exports run under separate identities. Environment scope matters when a proxy has different revisions deployed in development, test and production, because each environment can hold a different active revision that must be captured.
- Single proxy or small set: The REST path is usually enough, and the script can be a few lines.
- Full organization inventory: apigeecli reduces the number of custom steps needed to list and save many entities.
- Multiple environments: Export from each environment you run and record which revision is deployed where.
- Separate identities: Use one service account per environment when the audit trail must show who exported what.
- Mixed approach: Many teams use apigeecli for the inventory and the REST API for specific revisions that need exact evidence.
Ask your Google Cloud administrator to confirm which role, project and environments the export identity will hold before any export starts.
What does not come out as a portable bundle
The proxy revision bundle carries API proxy code and policies, but much of what makes an Apigee estate work lives elsewhere. The cards below cover the entities that sit outside that bundle, what each one holds, and how teams usually rebuild or re-export it. Confirm the exact export path for each entity with Google before you plan the cutover.
Analytics history
Traffic, latency and error history collected by Apigee analytics is held in the Apigee platform, not in the proxy bundle. Re-importing a proxy gives you the logic back but none of the historical trend lines your capacity planning and SLA reviews depend on. Plan to export whatever reports you need to keep as CSV or into your own data store before the subscription ends, and start the new gateway's metrics pipeline in parallel so there is a comparison window. Confirm the export path for analytics data with Google.
Developer and app records
Developer accounts, apps, API products and their credential pairs are management records, not proxy code. A proxy bundle will not re-create the consumer keys or secrets that partners have embedded in their clients. Export the list of developers, apps and product assignments through the management API, then decide whether to re-issue credentials on the new gateway or carry existing secrets over through a controlled import. Re-issuing usually needs a partner communication plan and a rotation window.
Developer portal content
Pages, API documentation, specs and branding for the Apigee developer portal are stored with the portal rather than in proxy revisions. Export the content from its source, which may be the portal's own content files or the Drupal-based site, and keep the OpenAPI specs in version control so they can seed the new portal. Check that any custom theme or templates are captured, since they will not appear in a proxy bundle.
Custom Java callouts
Java callouts and their compiled JAR files are packaged with the proxy only in some cases, and the source code often lives in a separate repository. Locate the original source and build artifacts for every callout before migration, because the bundle may reference a JAR you cannot inspect. Each callout needs a replacement decision: a custom plugin for APISIX written in Lua or through a plugin runner, a built-in plugin, or a call to an external service.
Key-value maps and secrets
Environment and organization-level key-value map entries, target server definitions and TLS keystores and truststores are environment resources, not proxy code. Some values are encrypted or masked on export, so the entries may come out incomplete. Inventory each map and certificate, record which proxies reference it, and source the values from your own secrets store. Rotate any TLS material you cannot confirm was transferred intact.
Shared flows and environment config
Shared flows, product definitions and environment-scoped settings can be exported with apigeecli, but they must be re-linked to the proxies that call them. Record the environment, target endpoints and quota settings per proxy in a spreadsheet, because the new gateway will expect these as routes, upstreams and plugin configuration. Treat this inventory as the reconciliation checklist for the cutover.
The export sequence and how to verify each step
This sequence turns an Apigee estate into a complete, checksummed inventory of proxy bundles, shared flows, products and per-environment configuration that the team can review before any migration work starts. Each step ends with a check so that nothing is exported on assumption alone.
Inventory organizations, environments and proxies
Start by listing every Apigee organization your team can reach, then the environments in each one, then the API proxies in each environment. Platform owners or the Apigee administrator usually hold this list, and the Apigee management console or the Apigee API can produce it. Save the output as a dated inventory file with one row per organization, environment and proxy name. This inventory is the baseline for every later check, so it is done when a second person can read it and confirm that no environment is missing.
Grant the proxy revision read permission
Ask the Google Cloud project administrator to give the exporting identity the apigee.proxyrevisions.get IAM permission on the organization. Use a dedicated service account or a named user with read-only access, so the export does not depend on someone with broad deploy rights. Confirm the grant by making one test call against a single proxy revision in a non-production environment. The step is done when that test returns a zip file rather than an authorization error. Confirm the exact role that carries this permission with Google's current Apigee documentation before you request it.
Export each proxy revision as a bundle
For every proxy in the inventory, call the Apigee API method organizations.apis.revisions.get with the format query parameter set to bundle, once for each revision you need to keep. Name each file with the organization, environment, proxy name and revision number, for example as illustrative naming, so that files can be matched back to the inventory later. Record the HTTP status for each call. Deployed revisions matter most, but older revisions can be needed for rollback, so decide the revision policy before you start. The step closes when every call has returned a zip file and the status log has no failed rows.
Export shared flows and products with apigeecli
Use apigeecli, the open-source command line tool in the Apigee GitHub organization, to export shared flows and API products that are not covered by the proxy bundles. Its README states that it is not an officially supported Google product, so test the command against a non-production organization first and pin the tool version you used. Store each export next to the matching proxy bundles. The step is done when the shared flow and product files appear in the inventory with the same organization and environment labels as the proxies. Your team should check the apigeecli documentation for the exact export command syntax for your version.
Record configuration for each environment
Capture the configuration that lives outside proxy bundles for each environment, such as target server definitions, key value map entries, developer apps, API keys metadata, and environment-level settings. Export what your tooling supports and write the rest into a manual record with the owner's name. Keep secrets out of this record by noting where they are held and not copying their values. The step is done when each environment has a configuration record that a reviewer has signed off on. Confirm with your Apigee administrator which of these items apigeecli or the Apigee API returns in your edition, since coverage differs between managed, hybrid and private cloud deployments.
Verify completeness against the Apigee API listing
Run the Apigee API listing calls again for each organization and environment, and compare the proxy names and revision numbers returned against your inventory file. Every proxy and every revision you intended to keep should match exactly one exported zip. Investigate any name in the listing that has no file, and any file that has no listing entry, before you move on. This comparison is what catches proxies that were created after the inventory was taken. The step is done when the two lists match line by line and any differences are written up with a disposition.
Checksum each file and sign off the inventory
Generate a SHA-256 checksum for every zip file and every apigeecli output, and write the checksums into the inventory with the file size and export timestamp. Store the inventory and checksums in a location with restricted write access, and keep a copy outside the source organization. Before you consider the export final, open a sample of bundles to confirm each contains the expected proxy XML and policy files. The step is done when a second reviewer has recomputed at least the checksums for a sample and the inventory is marked complete, which becomes the reference set for the rewrite work on the new gateway.
What has to be rewritten for the new gateway
The export is only the first step, because an Apigee proxy bundle describes behavior in Apigee's own model: a proxy endpoint that receives client requests, a target endpoint that calls the backend, and a sequence of policies attached to request and response flows. Apache APISIX uses a different model. Its documented building blocks are routes, which match incoming requests, upstreams, which hold the backend nodes and load-balancing settings, and plugins, which run on routes or services. Each proxy in the bundle has to be decomposed into those pieces, and the flow logic in the proxy and target XML has to be restated as plugin configuration. Confirm the exact route matching and plugin attribute names against the current APISIX documentation before you write any configuration.
Not every Apigee policy has a direct plugin equivalent in APISIX. Policies that handle common concerns such as key validation, rate limiting, header manipulation or OAuth-style token checks usually map to built-in plugins, and APISIX's documented plugin catalog is broad. Policies that run JavaScript, Java callouts, custom message transformation or specialized logic will need custom plugins, which APISIX supports in Lua and, through plugin runners, in Java, Go and Python. Build an inventory from the bundle that lists every policy type, its configuration and the shared flows it calls, then mark each entry as direct, partial or custom. This inventory is the basis for estimating the work.
Most of the effort sits in this mapping, not in the export or the deployment. Reviewers should test each route against recorded Apigee traffic, verify that policy ordering and error responses match what consuming applications expect, and check that secrets referenced in the bundle are re-created in the new environment rather than copied. Decide early who owns the mapping, how it is versioned and how it is reviewed, because a bundle export captures one moment in time and the team will keep changing the proxy during the migration.
What to plan before the Apigee contract renewal or termination
Export is only one step in leaving Apigee. The decisions below set the order of work, the deadlines you must meet and the evidence you need before you cancel or let a contract lapse. Confirm each point with your Google account team and your own agreement before you rely on it.
Confirm your deployment type
Establish whether you run Google-managed Apigee, Apigee hybrid with a customer-run runtime, or Apigee Edge for Private Cloud. Each one changes where proxy bundles, environment configuration and keys live, and which exports you can take yourself. Write down the organization name, environments, runtime locations and the admin accounts that hold them. This inventory becomes the scope for every later card.
Set timing against the Edge end of life
If you run Edge for Private Cloud, plan around the documented end of life for version 4.53.01 on June 30, 2027, after which Apigee stops bug fixes, security updates and patches for that line. Continuous support requires a version inside its 18-month full support window. Decide early whether you upgrade, move to hybrid or leave, because each path has a different export and cutover sequence.
Get export and data return confirmed in writing
Ask the vendor to confirm in writing which artifacts you may export, in what format, how long you have to retrieve them and whether any data is held after termination. Request a list of entities covered, including proxies, shared flows, products, developers, apps and keys. Verbal assurances from a sales or support contact do not establish what happens at contract end.
Confirm notice periods and deletion terms
Read your agreement for the notice period, the renewal date, the termination effective date and the deletion terms for customer data. Note whether deletion happens automatically, on request, or after a retention window, and who must ask. Missing a notice date can renew the contract for another term, so put the dates in your change calendar with a named owner.
Run a parallel window before cutover
Keep Apigee and the new gateway live side by side for long enough to compare routing, authentication results, rate limits and error responses on the same traffic. Route a small share of non-critical APIs first, and keep Apigee able to serve traffic until every consumer has moved. Check that your contract still allows this overlap, since some agreements bill for both environments during the window.
Plan access revocation and artifact retention
Before you terminate, list the service accounts, IAM roles and API keys that can read or change proxies, then revoke them in an order that does not break live traffic. Store exported bundles, configuration files and the export log in your own controlled repository with an owner, a retention period set by your records policy, and access limited to the team. Confirm that copies you keep do not breach any restriction in your agreement.
How much effort does an Apigee export take, and can our team do it alone?
What drives the effort of an Apigee export the most?
The main drivers are the number of API proxies, how many of them depend on shared flows, how much custom code sits behind policies such as JavaScript, Java callouts or Python, and how many environments and organizations you run. Each proxy has revisions, and each revision has to be downloaded and checked. Shared flows, products, developers and apps add more entities to inventory. A small organization with a handful of proxies and no custom code is a much smaller job than a multi-environment estate with dozens of proxies and bespoke logic. Ask for a written inventory of these counts before agreeing on scope.
What access does the client need to give for the export?
The export needs someone with IAM rights in the Apigee organization. Downloading a proxy revision through the Apigee API requires the apigee.proxyrevisions.get permission, so a service account or user with that permission is the minimum for the bundle download. Your team also needs a named owner who can approve the exported scope, confirm which environments are in use, and sign off on what is retired. Read-only access to the organization is usually enough for the export itself, but confirm the exact role set with your Google Cloud or Apigee administrator before work starts.
Can our own engineers run apigeecli without outside help?
Yes, a team with Apigee and command-line experience can run apigeecli in-house. The tool is Apache-2.0 licensed, lives in the Apigee GitHub organization, and can export proxies, shared flows and products. Its README states it is not an officially supported Google product, so your team owns any problems with it. Expect to script the exports, store the output in version control, and check each bundle against the source. The harder part is not the download but deciding what the new gateway needs to rebuild, which usually requires architects who understand your policies and traffic.
Which parts of an export usually need outside expertise?
Exporting bundles is mechanical. The work that tends to need experienced hands is mapping policies to the target gateway, reviewing custom code, and checking that environment-specific values such as target endpoints, keys and quotas are captured correctly. Apigee policies do not translate one to one into every gateway, so some will need custom plugins or a different design. Teams that have never mapped Apigee flows often underestimate this review. Ask any provider to show how they will handle custom code and environment configuration, not only how they will run the download.
How long does an Apigee export take?
No general duration is established here, and any figure you hear should be tested against your own inventory. The time depends on the number of proxies and revisions, the amount of custom code, how many environments must be reconciled, and how many people can review results. Ask for a timeline tied to a written list of proxies, shared flows, products and environments. A small, well-documented estate can move quickly, while a large one with undocumented logic takes longer to verify. Treat any single number without a scope definition as a placeholder.
What does a fixed-scope DeployOpen engagement cover for an Apigee export?
Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. For an export, the written scope would normally list which organizations, environments, proxies, shared flows and products are included, what format the exported artifacts take, how they are stored and verified, and what documentation is handed over. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask what is excluded, such as rewriting policies for a new gateway, which may be a separate phase.
What should we ask for in a quote before hiring help for an export?
Ask for a written scope that names each environment, the count of proxies, shared flows and products, and any custom code in scope. Request a list of deliverables, such as exported bundles, an inventory, a verification record and a handover document. Check who runs the work, what access they need, how credentials are handled, and where exported files are stored. Clarify what recurs after the export, such as ongoing support, and what is one-time. Ask how changes to scope are priced and approved, because undocumented policy logic is the most common reason estimates grow.
Does exporting from Apigee also export developer portal content and analytics?
The export described here covers API proxies, shared flows, products and related configuration, which is what apigeecli and the bundle download address. Developer portal content, analytics history and monetization data may sit outside that path and need separate extraction. Confirm with your Apigee administrator where portal content is managed and whether analytics data must be retained for audit or billing reasons. Listing these items before the export starts prevents surprises at cutover.
How DeployOpen scopes an Apigee exit
An Apigee exit usually starts with a written scope, not with a download. DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks, so the first deliverable is an inventory of what sits in the Apigee organization: API proxies and their revisions, shared flows, API products, developer apps and keys, environments, target servers, and the portal content that consumers rely on. Each of these needs an owner, a decision on whether it moves, and a note on where its configuration lives. Ask your DeployOpen contact to confirm in the written scope which of these entity types are in and which are explicitly out, because a portal rebuild and a gateway migration are separate pieces of work.
The scope should then name the export method for each entity type, the identity that will run it, and the evidence that the export is complete. For proxies, that means confirming which Google Cloud identity holds the IAM permission needed to download revisions, recording the revision numbers exported, and keeping the resulting bundle files under version control with checksums. Products, shared flows and related configuration may be exported with the tooling your team chooses, and the scope should say who validates the output against the live environment. Mapping to the new gateway, rewriting policies as plugins or routes, and verification against recorded traffic are normally separate deliverables with their own acceptance criteria. Engagements are fixed-scope, so each deliverable, its acceptance test and the schedule are agreed in writing before work starts. Ongoing support after cutover is available as a retainer, which you can scope separately from the exit itself.
How we work on Apigee exits
DeployOpen plans and carries out the export of Apigee proxies, shared flows, products and related configuration as a fixed-scope engagement inside your own environment. The written scope sets which entities are exported, where the bundles are stored and how the results are checked before any traffic moves.
How we scope
- Inventory the Apigee organization, environments and proxies in scope, including which revisions must be kept as evidence.
- Confirm the IAM permission the export account needs, such as apigee.proxyrevisions.get, and who approves access.
- Agree in writing which entities are exported with the API and which with apigeecli, and what the deliverables are.
How we build
- Script bundle downloads for each proxy revision using the Apigee API, with logs that record every file retrieved.
- Export products, shared flows and related configuration with apigeecli, then compare counts against the Apigee console.
- Map exported policies to the target gateway and flag the ones that will need custom plugins or rewrites.
How we hand over
- Deliver the bundle archive, export logs and a policy-to-target mapping document stored in your own repository.
- Document each step so your team can rerun the export in a later window or for another environment.
- Walk your engineers through the rewrite backlog and record open questions that depend on your business rules.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the export is complete.
- Review changes Google may make to the Apigee tooling or API surface before the next export cycle, as agreed in scope.
- Confirm with your vendor and internal owners any Apigee support obligations that still apply during the transition.
