How to export your data from MuleSoft

Export data from MuleSoft: what you can download and what you cannot

A team facing a renewal, a pricing change or a data residency requirement has to get its API assets out of Anypoint Platform before any migration can start. Anypoint Exchange downloads REST API specifications as zip files in RAML, OAS 2.0 or OAS 3.0, SOAP APIs as WSDL files and AsyncAPI specifications as a zip containing a YAML file, along with connectors as JAR files, templates as JAR or zip files, examples as zip files and policies as a JAR Mule policy or a YAML policy definition. Exchange offers no download for custom assets that have no files attached, and it offers no download for API groups, so those must be recreated from their contents or documented before the platform is switched off. Exchange is only one part of the estate. Runtime projects, the Mule applications behind each API, sit in version control or Anypoint Studio and need their own export path, and deployment settings for CloudHub, hybrid servers or Runtime Fabric are not stored as Exchange downloads at all.

Before exporting, inventory every asset type and mark which ones download cleanly and which need manual rebuilding. Ask your MuleSoft contact and your administrators to confirm the Exchange version of each specification, because a RAML or OAS file exported from an older asset may not match what the gateway currently enforces. Record the owner, the business group and the consumers of each API, since Exchange does not carry the client applications, SLAs or subscriptions that API Manager attaches to them. Keep the exported files in Git with a version tag so they remain usable if the platform account is closed. For runtime code, confirm with your developers that the source projects and their dependency lists are complete, because deployment configuration, property placeholders and secrets are environment-specific and must be captured separately. Plan for the fact that some items cannot be retrieved from the platform, and document them while the platform is still accessible.

Once inventory is complete, the exported specifications become the input for the target catalog. They can feed a WSO2 API Manager or Gravitee developer portal, or a Backstage API catalog, and they can drive gateway configuration on the new platform. Use the MuleSoft documentation on downloading an asset from Exchange as the reference for which formats each asset type returns, and validate every downloaded file with your own linter before reuse.

Which MuleSoft assets export from Exchange, and in which formats

This table lists each asset type that Anypoint Exchange can download, the file format it arrives in, and where it is most likely to live after the move. Use it as a checklist: open every exported file in the target tool before you delete anything from Exchange. Assets that Exchange cannot export need to be rebuilt or recovered from source control.

Asset type	Download format	Likely next home	Check before you move
REST API specifications	Zip containing RAML, OAS 2.0 or OAS 3.0 files	WSO2 API Manager Publisher, or a Git repository holding the spec	Confirm the OAS version and RAML version import cleanly into the target portal and that referenced fragments are included in the zip
SOAP APIs	WSDL files	WSO2 API Manager for the service definition, with the backend kept as a separate integration service	Check that imported schemas and external WSDL imports resolve, since SOAP definitions often depend on other files
AsyncAPI specifications	Zip containing a YAML file	WSO2 API Manager, which supports AsyncAPI, or a Git repository with a catalog	Verify the AsyncAPI version the target tool accepts and that channel and message definitions validate
Connectors	JAR files	Apache Camel project, where Camel components or custom components replace them	Connectors are tied to Mule runtime APIs, so expect to rewrite them rather than load them into Camel
Templates	JAR or zip files	Git repository used as the starting point for new Camel or Spring Boot projects	Review the project structure and build files, and confirm the build still runs with the JDK version you plan to use
Examples	Zip files	Git repository or developer portal documentation pages	Check that sample payloads and configuration references still match the new API definition
Policies (Mule policy JAR)	JAR Mule policy	Gateway policies in the target gateway, such as WSO2 API Manager or Apache APISIX, rebuilt by hand	Mule policy JARs run only on Mule gateways, so treat them as reference for re-implementation, not as deployable artifacts
Policies (YAML definition)	YAML policy definition	Declarative gateway configuration kept in Git and applied through CI/CD	Confirm each policy setting maps to an equivalent in the target gateway before you retire the original

Which assets offer no download, and how to recover them

Anypoint Exchange covers most catalog assets, but two asset types offer no download at all. The cards below cover those gaps and the workarounds that keep your migration from stalling on them.

API groups have no download

An API group is a bundle of related API definitions in Exchange, and Exchange offers no download for it as a group. Before you start, list every group in the business group and record the API definitions inside each one. In the target publisher, such as WSO2 API Manager, recreate each definition as its own API, using the RAML, OAS or WSDL file you downloaded for that definition. Check that version numbers, endpoints and policies carry over per API, because group-level settings do not travel with the bundle.

Custom assets without files

A custom asset in Exchange is a catalog entry that has no uploaded files, so there is nothing to download. Its content usually lives elsewhere, in a project's source repository or a team's shared drive. Search your Git hosts and team storage for the project that published the asset, and confirm the version in the repository matches the version shown in Exchange. Where the source cannot be found, record the asset name, owner and version, then ask MuleSoft in writing what it holds for that asset.

Confirm other platform data

Exchange downloads cover assets, not the rest of the platform. Applications, client contracts, credentials, access rules and analytics history are not listed among the downloadable items. Do not assume any of them has an export path. Ask MuleSoft in writing which of these records it can provide, in what format, and whether the export is included in your subscription. Record each answer in the migration plan so that gaps are known before cutover, not during it.

Rebuild client applications

Client applications and their contract records do not come out of Exchange as files, so the consuming teams must be identified by hand. Build an inventory from API Manager or your own onboarding records, listing each application, its owner, the APIs it calls and the credentials it uses. In the new gateway, issue fresh credentials and plan a window in which consumers switch over. Treat this inventory as the migration's source of truth for who depends on which API.

Preserve specifications in Git

Once you recover a specification from Exchange or a repository, store it under version control in a repository that your team owns. Keep one directory per API, with the RAML, OAS or WSDL file, its version and a short changelog. This gives the new publisher a clean, reviewable source and prevents the same gap from reappearing in the next migration. Confirm that the specification you store is the one currently serving traffic, not a stale draft.

What Exchange does not hold: runtime projects and deployment configuration

Anypoint Exchange catalogs API specifications and reusable assets, but it does not hold the Mule applications that run them. Those live in your team's Anypoint Studio projects and in the deployment settings for each environment. Before a move, treat the runtime estate as a separate inventory from the Exchange export, because a complete asset download still leaves the running integrations behind.

The inventory has to follow the deployment target. MuleSoft documents CloudHub and CloudHub 2.0 (MuleSoft-managed), hybrid deployments to customer-managed Mule servers, Runtime Fabric on customer-managed infrastructure, and Anypoint Platform Private Cloud Edition on premises. Each target stores application archives, property files and environment settings in its own way. For every application, record the deployed archive version, the properties and secure properties used per environment, the runtime version, the worker or replica sizing, the inbound endpoints and the external credentials it depends on. Confirm with your MuleSoft account team and in your own Runtime Manager console which of these values are retrievable and which must be rebuilt from your records.

Do not assume an exported Studio project is a runnable copy. The Anypoint Studio documentation states that the Mule Community runtime does not support all the features of the Enterprise runtime, and that switching from Enterprise to Community may leave some configurations unsupported. If you plan to run flows on Apache Camel or on a self-managed Mule runtime, build each project against the target runtime, then test it with production-like properties and representative messages before any cutover. Flag any flow that depends on an Enterprise-only feature as a separate work item with its own owner.

Export sequence from Exchange, with a check at each step

This sequence moves API specifications, connectors, templates, examples and policies out of Anypoint Exchange into a versioned Git repository, with a verification and a sign-off for each stage. The result is a manifest that shows what left MuleSoft, from which asset and version, and who approved it.

Inventory every Exchange asset per business unit
Each business unit's Exchange organization is listed asset by asset, with the asset type, version, owner and the project or environment that consumes it. Mark API groups and custom assets without files as no-download items now, so they are not expected later. The owner of each business unit confirms the list is complete, and the inventory is saved as a spreadsheet or CSV that becomes the first tab of the manifest. Ask MuleSoft or your administrator to confirm which assets are visible to your account, since access rights can hide assets from an export.
Export REST, SOAP and AsyncAPI specifications first
Specifications come first because they define the contracts that every other asset depends on. Download REST specifications as RAML, OAS 2.0 or OAS 3.0 zip files, SOAP APIs as WSDL files, and AsyncAPI specifications as a zip containing a YAML file, keeping the format MuleSoft provides rather than converting it at this stage. Record each download against its asset name and version in the inventory. Done means every specification in the inventory has a file on disk and a matching row in the manifest.
Validate specifications in their native formats
Open each RAML or OAS file in a validator that matches its format, and confirm that it parses without errors and that its version matches the Exchange listing. For each WSDL, confirm that it imports into a SOAP tool without unresolved schema references. For each AsyncAPI archive, unzip it and confirm that the YAML parses. Any file that fails is logged with the error, returned to the asset owner, and re-exported. The reviewer records the validator name and version used, because those details are needed to reproduce the check later.
Export connectors, templates, examples and policies
Next, download connectors as JAR files, templates as JAR or zip files, examples as zip files, and policies as either a JAR Mule policy or a YAML policy definition. Keep each file with its original name and do not unpack JARs in the export folder. Confirm that each connector JAR opens as a valid archive and that each policy file has the expected type, since a YAML policy and a JAR policy are handled differently in a later migration. Assets that offer no download are listed in the manifest with the reason, so the gap is documented rather than silently skipped.
Store files in a versioned Git repository with checksums
Commit the exported files to a dedicated Git repository, with one folder per business unit and one subfolder per asset. Generate a SHA-256 checksum for every file and store the checksums in a companion file committed alongside the artifacts. Tag the commit that holds the complete export so it can be referenced in later migration work. Confirm the repository has branch protection and that a second person can clone it and recompute the checksums with the same results. The repository becomes the source of record for specifications and assets during the move.
Build the signed export manifest
Produce a manifest that lists every exported file, its source asset name, asset version, Exchange organization, export date, checksum and file format. Mark assets that could not be downloaded, with the reason. Each business unit owner reviews their section, then the platform lead and a security or compliance reviewer sign off, recording names and dates in the manifest itself. Commit the signed manifest to the same repository. Done means no file in the repository is missing from the manifest, and no manifest row lacks a file or a sign-off.

Where the exported files go: WSO2, Apache Camel or a Git-first catalog

WSO2 API Manager is the destination for API specifications. Export RAML or OAS files from Exchange, then import them into the Publisher, which creates the API definitions that the gateway and Developer Portal expose. The product supports REST, GraphQL and AsyncAPI APIs, so AsyncAPI specifications from Exchange have a place to land. Building the 4.7.0 release requires JDK 21, so the build host needs to be ready before import work starts.

Specification formats: RAML and OAS 2.0 or 3.0 files are the main inputs, and each imported definition should be reviewed endpoint by endpoint.
Build environment: Teams that build the product from source need JDK 21 on the build host, as noted in the WSO2 API Manager 4.7.0 release.
Protocol coverage: REST, GraphQL and AsyncAPI definitions map to supported API types, while SOAP APIs arrive as WSDL files that need a separate import decision.
Not transferred: Mule policies, client applications, subscriptions and developer portal content do not move with the specifications, so each must be recreated in WSO2 API Manager.

Confirm the import behavior for your exact WSO2 version in a test environment before the production cutover.

What to plan before the MuleSoft contract ends

These five decisions run in sequence. The deadline sets the schedule, the runtime and access checks decide what can be exported, and the licensing and deletion checks decide what you keep. Settle them before the first download so gaps surface while MuleSoft still holds the data.

Fix the export deadline

Set the date by which the team must hold a complete export from the dates in your MuleSoft contract, not from an internal estimate. Work backward from that date to schedule the Exchange downloads, the review of each asset, and a second pass for anything that failed. Ask your account team in writing for the exact end date and any notice period that applies after renewal decisions. Treat the contract end date as the only fixed point and build the rest of the plan around it.

Confirm your runtime support window

List every Mule runtime version your applications run on, then confirm each version's end-of-support date with MuleSoft in writing. The Mule 4.6 LTS date is not in the sources for this page, so do not rely on a date from memory or a forum post. If a runtime leaves support before your cutover, the work changes from an upgrade to a rebuild. Ask whether support continues through the export period itself.

List Exchange users and organizations

Export needs people who can see every asset, so list each Anypoint organization, business group and user account that owns or consumes specifications, connectors, templates and policies. Include contractors and the service accounts used by automation, since their access may end with the license. Confirm access in each organization separately, and do not assume one view shows everything. Assign one named owner to each organization so that download requests have a single point of contact.

Inventory licensed connectors and policies

Connectors downloaded as JAR files and policies delivered as JAR or YAML definitions can depend on Anypoint features, runtime versions or licensing. List each one with the applications that use it, then check it against the runtime you plan to run. MuleSoft's Studio documentation states that the Community runtime does not support all Enterprise features, and switching may leave some configurations unsupported. Record which assets you can reuse and which need rebuilding.

Get deletion terms in writing

Ask MuleSoft to confirm in writing what it will delete from your organizations, including Exchange assets, logs, runtime metadata and backups, and the date each deletion happens. A verbal assurance from an account contact will not help in a later dispute or audit. Compare the reply with your own retention obligations, and export anything you must keep before the first deletion date. Ask whether deletion waits for a written request from your organization.

How long an export takes and what it needs from your team

How much effort does a full MuleSoft export take?

The effort depends on how much is in Anypoint Exchange and how well it is documented, so no single figure applies to every estate. The main drivers are the number of Exchange organizations you need to cover, the count of REST, SOAP and AsyncAPI specifications, how many assets are custom assets or API groups that offer no download, and whether specifications, examples and policy definitions match what is actually deployed. A small catalog with current specs and a clear owner for each asset is a short exercise. A large catalog with stale specs, duplicated assets across organizations and no inventory takes longer, mostly in reconciliation rather than downloading. Ask any partner to size the work from a count of your organizations, specifications and assets before agreeing a fixed scope.

Can our team export MuleSoft assets without a partner?

Yes. Downloading specifications, connectors, templates, examples and policies from Exchange is a task your own staff can do, and it does not require a partner. What makes it succeed is ownership: name one person who holds Exchange access for each organization, and keep a manifest that lists every asset, its type, its version, the file format downloaded, the owning team and the deployment it supports. Without a manifest, teams often miss assets that exist only in one business unit or only in a deployed application. A partner adds value mainly when the manifest needs to be built against live deployments and when the exported files must be tested against a running gateway.

What would a partner's fixed-scope export cover?

A fixed-scope export is defined in writing before work starts, so the deliverables are known in advance. A typical scope, which you should confirm against your own needs, covers an inventory of Exchange organizations and assets, the download of each supported asset type in the formats MuleSoft provides, a manifest with ownership and version data, a gap list for assets with no download, and a record of which specifications map to which running APIs. Work that changes the scope, such as rebuilding a policy that has no export or validating specifications against live traffic, should be priced as a separate written item. Ask for the deliverables list, the acceptance criteria and the handover format in the scope document.

What must our team supply before an export starts?

Four inputs decide whether an export can start on schedule:

Exchange access for every organization in scope, with a role that allows downloads.
A deployment inventory listing where each API and integration runs, including CloudHub, CloudHub 2.0, hybrid Mule servers, Runtime Fabric and any Private Cloud Edition installs.
Read access to the source repositories where specifications and Mule projects are kept, so the exported files can be compared with what is in Git.
A decision on target platforms, such as WSO2 API Manager for the management layer or Apache Camel for integration flows, because the export format you need depends on that choice.

Missing any one of these usually pushes the work into a second round of discovery.

Can we trust exported specifications without testing them?

No. A downloaded specification is a file, not proof that the API behaves as documented. Validate each RAML, OAS 2.0, OAS 3.0, WSDL or AsyncAPI file with a linter or parser that matches its format, then confirm the file against a running gateway. A practical test loads the specification into the target gateway, routes a set of representative requests through it, and compares responses and headers with the production API. Specifications that were edited in Exchange after the last deployment are the most common source of mismatch. Plan this test as part of the export, not as a later step.

What should we ask for in a written quote for an export?

Ask the provider to state, in writing:

The list of Exchange organizations, asset types and counts used to size the work.
The exact deliverables, file formats and manifest fields.
How assets with no download, such as custom assets and API groups, will be recorded and handled.
The validation method for each specification type and the gateway environment used for testing.
Which items are fixed in the price and which are separate change requests.
Who owns the data and the exported files after handover, and where they are stored.
Whether support or retainer work is optional and how it is billed.

A quote that does not list these items is difficult to compare with another quote.

How DeployOpen scopes and delivers a MuleSoft data export

DeployOpen approaches a MuleSoft export as a fixed-scope piece of work agreed in writing before it starts. We inventory which Anypoint Exchange assets can be downloaded, which cannot, and where each one needs to land in your self-hosted target environment.

How we scope

We list every API group, custom asset and reusable asset in your Exchange organization and note which have a download and which do not.
We confirm which specification formats are needed, such as RAML, OAS 2.0, OAS 3.0, WSDL or AsyncAPI, for each target catalog.
We agree in writing which connectors, templates, examples and policies are moved, rebuilt or retired, and who signs off each decision.

How we build

We retrieve downloadable assets from Exchange and store them in a version-controlled repository inside your own environment.
We recreate assets with no download, such as custom assets without files, from documentation and configuration you provide, and mark them as manual work.
We test that exported specifications validate and load into the target catalog, such as WSO2 API Manager or Backstage, before any cutover.

How we hand over

We deliver an inventory that maps each Exchange asset to its exported file, its new location and its owner.
We document the export steps, the list of assets that could not be downloaded and the decisions behind each one.
We confirm with you that every deliverable is stored in your own infrastructure and that access to exported data is limited to your team.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the export is complete.
Support can cover re-exporting specifications when APIs change during a long migration window.
Ask any provider, including DeployOpen, to confirm in the written scope who maintains the exported assets after handover.