Solution Migration Service

The Solution Migration Service lets you move integration objects, configurations, and supporting files from one Adeptia environment to another in a controlled, repeatable way. It supports the full promotion lifecycle: packaging objects for export, importing them into a target environment, and rolling back changes if something goes wrong.

Why solution migration matters

As you build and refine integrations, you typically work across multiple environments, such as development, testing, and production. The Solution Migration Service gives you a structured way to promote your work between those environments without manual re-creation. It also protects the target environment by capturing a rollback snapshot before any changes are applied, so you can recover quickly if an import produces unexpected results.

What you can do

The service supports four main operations:

Operation	What it does
Export	Packages selected integration objects, configurations, and supporting files into a portable archive
Import	Applies a previously exported archive to a target environment, updating the database and shared file locations
Rollback	Reverts a target environment to its state before the most recent import
Restore	Redeploys a known-good archive to bring an environment back to a specific state

Each operation is tracked with a start time, end time, status, and contextual information so you can audit what ran, when, and whether it succeeded.

What gets migrated

A migration package can include:

• Integration activities and their database records
• Application connector definitions, including their actions, triggers, and associated parameters
• Configuration properties that control how the environment behaves
• Supporting files and folders, such as security objects, schema files, WSDL definitions, and EDI schemas
• Value Maps and Multi-Valued Maps used in data transformation

When you import a package, the service deploys database records, copies files to the correct shared locations, and reconciles configuration properties between the source and target environments. Properties that exist in the target are updated; properties that are new to the target are inserted; and properties that have been removed or restructured in the target platform are handled gracefully, with a report generated to highlight any differences.

Value Maps and Multi-Valued Maps during import

When a package includes Value Maps or Multi-Valued Maps, you can control how each one is applied to the target environment. Two apply modes are available:

Mode	Behavior
Overwrite	Replaces the target artifact entirely with the packaged version, creating it if it does not yet exist
Merge	Upserts rows by key, with the packaged version winning on conflicts; rows that exist only in the target are preserved; creates the artifact if it does not yet exist

The apply mode for each artifact is read from the import manifest or supplied via the headless import path. If an artifact is not selected for import, the target is left untouched. Each artifact is applied independently, so a problem with one does not prevent the others from being processed.

Rollback protection

The service supports creating a rollback archive that captures the current state of every database record and file that an import will touch. If you need to undo the import, the rollback operation restores those records and files and removes any objects that were newly created by the import. Rollback covers both database activities and files in shared locations.

Business rule migration

The service also supports migrating business rules and rule sets from an earlier version of the platform to the current version. This operation reads exported rule definitions, maps each rule set to a target JSON schema that you specify, and upserts the rules and their relationships into the target environment. Rule set and rule identifiers are preserved across the migration. You must supply a valid user to be recorded as the owner of the migrated objects, and you must provide the schema mapping that associates each rule set with its target schema.

Migration execution log

Every migration operation, whether export, import, rollback, or restore, is recorded in a migration log. The log entry captures the operation type, the name of the package, the user who initiated it, the start and end times, the final status, and contextual details such as the location of the output archive and whether the package included solution data or supporting files. If the operation fails, the error message and trace are recorded alongside the log entry so you can diagnose the problem.

What you provide

When you run a migration operation, you supply:

• The source archive to import, or the selection of objects to export
• For business rule migration: a mapping from each rule set to its target JSON schema, and a valid user to assign as owner
• Optionally, an override user to record as the creator and modifier of imported objects in the target environment

The service validates the inputs before proceeding and reports errors clearly if required information is missing or invalid.