How to export your data from Boomi before you leave
Process and component definitions can be pulled out of Boomi as XML through the Platform API Component object, but credentials and runtime state cannot. The Component object retrieves the configuration XML for one component ID and version per call, and it supports GET, CREATE and UPDATE operations but not QUERY or DELETE. That means your export is a per-component pull, not a bulk download. Bulk GET requests are limited to 5 components each, so a large account requires a scripted loop over an inventory list. Before you start, confirm with your Boomi administrator that the API user has the required API access privileges, and check that the component types you need are available on your account, since Boomi notes that not every type is offered to every account.
Plan for two things the XML will not carry. First, Boomi masks password-type fields, such as private certificates, with a cryptographic hash in Component object responses, so every credential, certificate and connection secret must be re-entered or re-issued on the new platform. Keep a register of which connectors and certificates depend on which secrets before you cut over. Second, the export captures design-time definitions, not the live state of running processes, schedules or queued messages, so those need separate handling in your cutover plan. Treat the XML as a specification for rebuilding, not as a working migration: each exported process still has to be mapped to Camel routes or NiFi flows, tested against real endpoints, and approved. Ask your Boomi contact to confirm the current retrieval limits and any export or support options in writing, because these details can change between platform releases.
What Boomi documents as exportable through the Component object
This table lists the component types an export can cover, the method and format Boomi documents, and the limits that shape a bulk extraction. Use it to plan the inventory: the component types your account exposes and your API access privileges decide what you can actually pull out.
| Item | What Boomi documents | What to confirm in your account |
|---|---|---|
| Processes | Retrieved as component configuration XML through the Component object, one component ID and version per call | Process count, versions in use and whether each is deployed to a runtime |
| Maps | Retrieved as component XML using the same GET method, one ID and version per call | Map count and which processes reference each map |
| Connectors | Connector and connection components are retrievable if the account exposes that component type | Connector types in use and their endpoint configuration |
| Other component types | Available only where the account has access to that component type | Which types your tenant exposes, such as profiles, certificates or API definitions |
| Export method | GET on the Platform API Component object; CREATE and UPDATE also exist, but QUERY and DELETE are not supported | Confirm that your scripts use GET only and that no bulk tooling assumes QUERY |
| Output format | Component configuration XML for each retrieved component | Store XML under version control with the component ID and version in the file name |
| Bulk limit | Bulk GET requests are capped at 5 components per request | Plan batches of five and track which IDs and versions have been retrieved |
| Access requirements | API access privileges are required to use the Component object | Ask an account administrator to grant the role before scoping the export |
What does not export and how to work around it
The Component object returns component configuration XML, but it does not hand you every secret or every operational record. Plan for these gaps before you count the export as complete, because each one needs an owner, a source outside Boomi, or a manual record.
Masked password-type fields
Boomi replaces password-type fields, including private certificates, with a cryptographic hash in Component object responses. The XML you export is therefore not enough to recreate a working connection. Build an inventory of every connector, certificate and credential referenced by the exported components, then mark each one as must be re-entered on the new platform. Confirm with the secret owners which values still exist in their own vaults, because a hash cannot be reversed into the original value.
Collect credentials from secret owners
The people who hold the original API keys, client certificates and service account passwords are usually outside the integration team. Send each application owner a list of the masked fields tied to their systems, and ask them to confirm the current values and expiry dates. Store the results in your own secrets manager, not in the rebuild specification, so the specification can be shared with reviewers without exposing values. Expect some owners to have rotated credentials since the Boomi process was last changed.
Runtime and environment settings
The component XML describes processes, not the Atom, Molecule or cloud runtime that executes them, nor the JVM options, memory limits, network routes or proxy settings configured on it. Boomi's documentation describes several hosted and customer-hosted runtime types, so record which runtime each process uses today and its settings in a runbook. Ask your Boomi administrator to export those settings from the platform console, since the Component object does not return them.
Platform-level and account configuration
Account-wide settings such as users, roles, environments, notification rules and shared resources are not part of an individual component definition. Confirm with Boomi which platform objects sit outside the Component object for your account, and whether your API access privileges cover each one. Some component types are also not available to every account, so a process may depend on a type you cannot retrieve. Treat any gap you find as an open item in the migration plan.
Execution history and run logs
Execution history, process run records and error logs are operational data, not component definitions, and they do not come back through the Component object. If an auditor or incident review needs proof of past runs, decide the retention period with your compliance lead and export what Boomi still exposes through its own monitoring tools. Then forward new run logs to your own monitoring stack, so the evidence survives the cutover. Ask Boomi what history is retained and for how long on your account.
Why the XML is an inventory, not a working migration
Component XML records how a component was configured, not how it was running. The Component object returns the configuration of one component at one version: shapes, mappings, connector settings and similar definition data. It does not carry the live state around that definition. Schedules, queue contents, in-flight messages, deployment history, and which Atom or Molecule a process ran on all sit outside the component definition. Password-type fields, such as private certificates, come back masked with a hash, so the credentials themselves must be re-entered on the new platform. Before you treat an export as complete, ask your Boomi administrator to list the schedules, listeners, environment extensions and deployed versions that the XML will not show, and record each one in a separate inventory.
The rebuild also requires decisions that the XML cannot make for you. A Boomi process might map to a Camel route using enterprise integration patterns such as a content-based router, a splitter or a request-reply exchange, or it might fit better as a NiFi flow of processors. Connectors in the XML must be matched to Camel components or NiFi processors, and some component types may not be available to every account, so confirm the inventory is complete against what your tenant actually runs. Treat each exported XML file as an input to a design review, with a target pattern, a target component and an owner chosen for every process before any code or flow is written.
The export feeds the later migration pages in a specific order: first the inventory of components and versions, then the mapping of each one to a target pattern, then the rebuild and test against recorded sample messages. The XML is evidence for the first step and a reference during the second, but it is not a runnable specification. Expect to use it alongside Boomi's own run history and your operational runbooks, and confirm with your own environment which of these sources hold the schedule, credential and state details described above before you commit to a migration scope.
The export sequence, step by step, with verification
This sequence turns Boomi's component definitions into a versioned, checked archive that serves as the source of truth for a rebuild. Each step ends with a check, so the team knows the inventory is complete before any process is rebuilt.
Confirm API access and component availability
The integration administrator confirms that the account holds the API access privileges needed to call the Component object, and that the component types in use are available to the account. Boomi notes that not every component type is available to every account, so a missing type should be raised with Boomi before the export starts, not discovered mid-run. Done means a written list of the component types the team expects to export, confirmed against a test call that returns the expected XML for one known component.
Build the inventory of component IDs and versions
Using the platform UI or another documented listing method, the team records every process, map, connector configuration and other component in scope, with its component ID and the version to export. Keep the inventory in a spreadsheet or CSV with one row per component, the component type, the folder or environment it lives in, and the owning team. Done means each row has an ID and a version, and the owning team has reviewed the list.
Retrieve each component with the Component object
Call the Component object GET for each component ID and version. The Component object returns one component per call, and bulk GET requests are limited to 5 components, so the script should batch in groups of five at most and handle each response separately. Log the HTTP status, the component ID and the timestamp for every call, and retry only the failures. Done means every inventory row has either a saved XML response or a logged error with a reason.
Store raw XML under version control with checksums
Write each response byte for byte to a file named by component type, component ID and version, and commit the set to a Git repository that only the migration team can write to. Generate a SHA-256 checksum for each file and store the checksum list alongside the files, so later copies can be verified. Do not edit the XML in this step. Done means the commit contains every file, and the checksum file can be regenerated from the repository and matches.
Validate that each file parses and counts correctly
Run an XML parser over every file to confirm it is well-formed, then compare the number of valid files with the number of inventory rows. Any file that fails to parse, or any component that returned an error, goes back to the retrieval step. Record the results in a validation report with the parse status, the component type and the file size for each entry. Done means the counts match and the report shows no unresolved failures.
Record masked fields and their owners
Search the exported XML for password-type fields, such as private certificates, which Boomi returns as a cryptographic hash rather than the original value. For each masked field, record the component, the field name, the business owner and the system the credential belongs to. Credentials must be re-entered on the new platform, so this register is what the rebuild team works from. Done means each masked field has a named owner and a plan to obtain the original secret from that owner.
Reconcile the inventory against the platform list
Compare the exported inventory with the component list the Boomi platform shows for the same environment and folders, and investigate every difference. Differences can come from components that were created after the inventory was built, components that are hidden from the account, or types that were not exported. The integration lead signs off the reconciliation with the date, the counts on each side, and the names of any excluded components with reasons. Done means the sign-off record exists and is stored with the repository.
Turning the XML into a rebuild specification
Engineers need a per-process specification that a developer can build from without opening Boomi. Parse each exported process component and list its shapes in order, including branches, decision logic, try/catch scopes and subprocess calls. Record every connector shape with its target system, operation and the connection component it references, then list the maps and profiles each message passes through. Capture parameters, process properties and document properties that the process reads or sets, since these become configuration in the new runtime.
- Shape inventory: Ordered list of shapes per process, with branches and subprocess calls marked.
- Connector list: Each connector with its operation, endpoint type and referenced connection component.
- Maps and profiles: Source and target profiles for every map, with field-level mapping notes.
- Parameters and properties: Every value read from or written to parameters, process properties and document properties.
- Error handling: Retry behavior, error branches and notification steps.
A person who owns the process must confirm the intent behind decision logic, the business meaning of each map, and any behavior that happens outside the process, such as a scheduled trigger in another system that the XML does not show.
Security and compliance teams need to know where credentials live, which systems data crosses and where it is stored. Use the XML to build a credential register and a data-flow list. Every connection component that holds a username, token or certificate is a register entry. Because Boomi masks password-type fields with a hash in Component object responses, the register records that the secret exists and where it is used, not its value. Each new platform requires those secrets to be re-entered, so the register also becomes the re-entry checklist.
- Credential register: Each connection, its authentication type, the processes that use it and the owner who must supply a new secret.
- Data-flow list: Source system, target system, data classification and whether personal or payment data is included.
- Transport and endpoints: Protocols, hostnames and any outbound destination outside the organization.
- Certificate inventory: Private certificates and their expiry dates, which must be taken from the source system directly.
- Access scope: Which API credentials and roles the export itself used, so they can be revoked after the work.
A security owner must confirm which secrets remain valid, which data classes are really in scope and whether the target platform's secret store meets the organization's policy before any credential is re-entered.
The project lead needs to know what depends on what and in which order work can switch over. Build the dependency inventory from the process XML: which processes call other processes, which share a connection or map, and which are triggered by another system. Add the runtime each process runs on, since runtimes that are shared or clustered change the order of migration. The result is a list of cutover groups, each with its inbound triggers, outbound targets and a rollback path.
- Process call graph: Parent and child processes, shared maps and shared connections.
- Trigger inventory: Schedules, listeners and webhooks, with the owner of each upstream sender.
- Runtime mapping: Which runtime or cluster executes each process today.
- Cutover groups: Processes that must move together, with a planned order and a rollback step for each group.
- Open items: Processes with no owner, no recent run history or unclear business value.
Business owners must confirm which processes are still in use, which can be retired and when each downstream consumer can accept a changed endpoint. Run history from the source platform should be checked alongside the XML, because an export shows configuration and not whether a process still runs.
What to plan before the Boomi contract renews or ends
A Boomi exit is mostly a sequencing problem. The export depends on API access, the credentials cannot be recovered from the export, and the data you can still reach after termination is a contract question. The cards below cover what to settle first, so the component XML you pull is complete, usable and backed by written answers from Boomi.
Set the export window early
Run the full component export well before the termination or non-renewal date, not in the final weeks. Bulk retrieval through the Platform API is done one component at a time or in small batches, so a large account takes real scripting and checking effort. Build in time to re-run the export when a process changes after the first pass, and to confirm that every component ID and version you need was captured.
Arrange API access privileges in advance
The Component object requires API access privileges on the account, and the user or role you export with must have them before you start. Ask Boomi, or your Boomi administrator, which role grants the access, whether it can be assigned to a separate service account, and whether that account can be removed cleanly after the export. Test a single GET call before scheduling the full run.
Collect credentials and certificates separately
Password-type fields, such as private certificates, come back masked with a cryptographic hash in Component object responses, so the export does not hold the secrets. Inventory every connector that uses a stored credential, certificate or keystore, and collect the originals from the people or vaults that own them. Plan to re-enter each one on the new platform rather than trying to recover it from the XML.
Confirm which component types you can export
Boomi notes that not every component type is available to every account, so an export inventory can be incomplete without anyone noticing. Compare the component types in your account against what your subscription and edition expose, and record any gaps. Ask Boomi in writing whether any component type is restricted by your contract before you treat the export as complete.
Set retention rules for exported artifacts
The exported XML contains process logic, mappings, endpoint URLs and configuration that may be sensitive. Decide where the files are stored, who can read them, how long they are kept, and how they are destroyed once the migration is accepted. Store them under version control or in an access-controlled repository, and record the export date and component versions with each file so the rebuild specification can be traced back to a known state.
Plan the parallel running period
Keep Boomi processes running until the replacement is tested against real traffic, and agree with Boomi when the runtimes can be stopped. Ask how long you can keep your account and runtimes active after the termination date, whether a read-only or export-only period is available, and what happens to execution history and logs. Confirm the answers in writing, since they determine how long you can compare old and new outputs.
Questions buyers ask before exporting from Boomi
How long does a full Boomi export take?
No duration is published in the facts available for this page, so the honest answer depends on your environment. The main drivers are the number of processes, maps, connectors and other components, how many versions you need, and how quickly API access is granted. The Platform API Component object retrieves one component ID and version per call, and bulk GET requests are limited to 5 components, so the request count grows with the component inventory. Ask your team to produce a component count by type first, then estimate effort from that list. Reconciling the exported XML against the live tenant adds time at the end.
Can our team export Boomi components without outside help?
Yes, if the team has the right access and skills, and many teams do the inventory themselves. The work needs an account with API access privileges, someone comfortable calling a SOAP-style API and scripting paginated requests, and at least one person who can read Boomi XML and understand process shapes, maps and connector settings. Not every component type is available to every account, so confirm which types your tenant exposes before you plan. A reviewer with integration knowledge is still valuable for judging which exported processes are live, duplicated or obsolete.
What does the export need from our organization?
It needs named privileges, credential owners and a sign-off path. Your Boomi administrator must grant API access to the account that runs the export, and a security reviewer should approve where the exported XML is stored, since component definitions describe your data flows and endpoints. Each connector or certificate has an owner who can tell you which secrets must be re-entered later. Agree in writing who accepts the inventory as complete, because that acceptance point defines when the migration baseline is frozen.
Can we recover the passwords and certificates from Boomi?
No. Boomi masks password-type fields, including private certificates, with a cryptographic hash in Component object responses, so the exported XML does not contain usable secrets. Plan for credential re-entry on any new platform. Build a credential register during the export that lists each connection, its owner, the target system and the rotation status, and treat re-entry as a tracked work item rather than a final step. Confirm with Boomi documentation how your specific connector types present their fields.
Does the export preserve everything needed to rebuild our integrations?
The XML captures component configuration, but a rebuild also needs context the export does not carry. Record execution history, schedules, notification settings, environment-specific properties, and the Atom or runtime each process runs on. Use the exported XML as a rebuild specification by mapping each shape and connector to its target equivalent, then flag any component type your tenant does not expose. Validate the inventory against what operations staff actually run, since dormant processes often appear in the export without any owner.
What does an outside partner charge to run the export?
DeployOpen does not publish a price list. Cost follows from the written scope, and the main drivers are the component count and types, the number of environments, how much access setup and privilege coordination is needed, the reconciliation effort against the live tenant, and the depth of the inventory report. Ask for a fixed-scope quote that lists deliverables, the component types covered, the handling of credential re-entry and the acceptance criteria. DeployOpen plans and documents the export and prepares the evidence, and the written scope is where to confirm exactly what is included.
Should we export components before choosing Camel or NiFi?
Usually yes, because the inventory tells you which target fits. Export first so you can see how many processes are data movement between files and systems, which suggests NiFi, and how many are API-driven or transformation-heavy, which suggests Apache Camel. Exporting early also avoids deciding the target before you know the workload. Keep the XML under version control with a dated snapshot, so the baseline stays fixed while the rebuild proceeds.
Where the export fits in a Camel or NiFi migration
The export is phase one of a migration to Apache Camel or Apache NiFi, and it produces the inventory that every later phase depends on. Nothing is rebuilt until you know which processes, maps, connection components and profiles exist, which version of each is live, and which ones nobody has run in years. Treat the export as a discovery exercise first and a file-copy exercise second. Its output should be a versioned set of component XML files, a spreadsheet or table listing each component ID, type, version and owning team, and a short list of components that could not be retrieved or that depend on account-level features you cannot confirm. Ask your Boomi administrator to confirm API access privileges for the service account before the work starts, because the Component object requires them.
Rebuild, testing and cutover come after the export, and each has its own checkpoint. In the rebuild phase, your team maps each exported process to Camel routes or NiFi flows and re-enters every credential, since masked password fields such as private certificates cannot be recovered from the XML. In the testing phase, you compare message outputs from the old and new flows using the same sample inputs, and you verify that schedules, error paths and retry behavior match what the exported definitions describe. Cutover then moves traffic in controlled steps while the Boomi runtime stays available for rollback. The export file set becomes the baseline for each comparison, so keep it under version control and retain it for the audit trail after decommissioning.
For the financial and operating questions around this work, read the sibling pages on cost of ownership and runtime control before you commit to a target. The cost page separates the Boomi subscription and its enterprise connectors from the infrastructure, implementation and developer time that a Camel or NiFi team carries, and the export inventory is what lets you estimate the rebuild effort at all. Ask any implementation partner for a written scope that names the processes covered, the test evidence delivered and the handover of the rebuilt code, and confirm the current Boomi contract terms and notice periods with your vendor manager before you set a decommissioning date.
How DeployOpen scopes and delivers a Boomi data export
DeployOpen treats a Boomi export as a fixed-scope piece of work: the component inventory, the extraction method and the rebuild specification are agreed in writing before anyone pulls a single XML file. The output is a documented, reviewable record of your processes, maps and connectors that your team or an implementation partner can work from, whichever target platform you choose.
How we scope
- Confirm which Boomi accounts, environments and component types are in the export, and whether your account has the API access privileges the Component object needs.
- Agree the inventory method, including how many components and versions are in scope and how bulk retrieval will be paced around the five-component GET limit.
- Record in the written scope which credentials, certificates and connection secrets must be re-entered on the new platform and who owns that step.
How we build
- Script the retrieval of component configuration XML through the Platform API, logging each component ID and version so the export can be repeated and checked.
- Parse the XML into a structured inventory of processes, maps, connectors and dependencies, flagging components that are unavailable on your account type.
- Turn the inventory into a rebuild specification that lists each process's purpose, trigger, endpoints, transformations and the password-masked fields that need fresh values.
How we hand over
- Deliver the raw XML archive, the parsed inventory and the rebuild specification as versioned files that your architects can review and store under your own change control.
- Provide a short document describing the extraction steps, known gaps and the list of masked fields, so the export can be audited or reproduced later.
- Walk your engineering and integration owners through the specification and agree sign-off criteria before any rebuild work starts.
How we support
- Support after handover is available as a retainer, covering questions on the export files and revisions when Boomi components change during a migration window.
- Re-run the extraction on request against an agreed component list, with the change recorded in the specification so both versions can be compared.
- Confirm with your Boomi administrator and security team which platform terms, data-handling rules and internal approvals apply before the export begins.
