Boomi has two primary ways to migrate your runtime and integrations to a new server: 1) Migration of the data to new hardware, and 2) Migration through the Boomi API. This article will cover the strategies and use cases for both methods and provide references to the Boomi Community articles and documentation.

Runtime Migration Through Hardware

The first method for migrating runtimes is through hardware migration and is the simplest to perform. This method involves moving the data for the Boomi application from one server to another and is only applicable when the runtime is self-hosted and the runtime type is not changing (i.e. Molecule to Molecule). This method is similar, if not the same, to Active-Passive failover strategies.

Hardware Migration Steps

When migrating an Atom, a snapshot of the VM or at minimum to install directory can be migrated to a new server. It is recommended to maintain the same directory paths on the new server. However, if different directory paths are used, then the Boomi Community: How to Migrate Your Atom to Another Server article reviews configurations that should be reviewed.

When migrating a Molecule, it depends on the parts that need to be replaced.

If only the VMs are being replaced and the file share is maintained, then the VMs should contain the same directory structure and have the file share mounted in the same place. The old VMs and new VMs can both be running the Boomi application at the same time with no issues.

If only the file share is being replaced, then replicate the file share and mount the new file share in the same location. Since the file share is being replicated, the old VMs should not be running Boomi at the same time as the new VMs.

If both the VMs and the file share are being replaced, then the new VMs should be created with the same directory structures, Boomi should be stopped on the old VMs, the file share should be replicated, the new VMs mounted to the file share, and finally, Boomi should be started on new VMs. Any local directories such as the local work directory, java directory, Windows service (Windows), and systemd configuration (Linux) should be updated to match the old VMs. The old VMs should not be running Boomi at the same time as the new VMs.

Hardware Migration References

• Boomi Community: How to Migrate Your Atom to Another Server
• Boomi Community: Molecule / Cloud Troubleshooting Guide - Migration Strategies

Runtime Migration Through Boomi API

The second method for migrating runtimes is through the Boomi Atomsphere API. This method can be beneficial in several scenarios: when server-level access is not provided, which is common for Cloud Atom Attachments; when both runtimes need to be up and running for some time; or when migrating from one type of runtime to another (i.e. Atom to Molecule). The method involves syncing the Boomi processes and configurations from the old runtime to the new runtime. Please be aware that not all configurations can be migrated through the API. Some configurations need to be re-entered manually or can not be migrated.

API Migration Steps

The following are the high-level steps to migrate runtimes through the Boomi API and considerations. Consider each step and if it is needed for your migration.

1. Create a new Runtime or Cloud Atom Attachment and add it to a new or existing environment. This can be done manually or some steps can be done through the Atomsphere API.
2. Migrate the Environment Roles. Boomi Doc: EnvironmentRole Object This step is not needed if using the same environment.
3. Migrate the Deployed Packages. Boomi Doc: DeployedPackage Object. This step is not needed if using the same environment.
4. Get the Process Schedule Status Id on the destination runtime. Boomi Doc: ProcessScheduleStatus Object. This will return a conceptual id for the process schedule on the destination runtime and is needed to migrate the process schedules.
5. Migrate the Process Schedule Status. Boomi Doc: ProcessScheduleStatus Object. When required, turn off the status on the old runtime and migrate the schedule status to the new runtime.
6. Migrate the Process Schedules. Boomi Doc: ProcessSchedule Object.
7. Migrate the Listener Status. Boomi Doc: Change Listener Status operation. When required, turn off listeners on the old runtime and turn on listeners on the new runtime.
8. Migrate the Environment Extensions. Boomi Doc: EnvironmentExtensions Object. This step is not needed if using the same environment. All non-encrypted extensions will need to be re-entered because they can not be migrated or re-applied to newly added runtimes to an environment.
9. Migrate Shared Server settings. Boomi Doc: SharedServerInformation Object. This step will migrate the shared web server settings to the new runtime. It will not migrate User Management configuration or CORS configurations. Those will need to be re-entered and new user tokens created.
10. Migrate the Persisted Process Properties. Boomi Doc: PersistedProcessProperty Object. This step will migrate last successful run time and other persisted properties.
11. Migrate Atom Counters. Boomi Doc: AtomCounter Object. This step will migrate the atom counters to the new runtime.

API Migration References

• Boomi Community: Cloud Atom Migration
• Boomi Community: Local Atom Migration
• Boomi Community: How To Migrate Processes to a New Atom

The article was originally posted at Boomi Community.