Decisioning Migration API decisioning-migration-api

The Decisioning Migration Service API enables you to migrate Decision management objects from one sandbox to another. The migration process runs as asynchronous workflows that include dependency analysis, execution, and optional rollback capabilities.

This API allows you to seamlessly transition your decisioning content between environments (e.g., from development to staging, or staging to production) while maintaining data integrity and relationships.

To learn about the benefits and capabilities of Decisioning compared to Decision management, refer to this page.

Capabilities capabilities

The Decisioning Migration Service API provides the following capabilities:

Prerequisites prerequisites

Required permissions permissions

To use the Migration API, you need appropriate permissions in both the source and target sandboxes:

Source sandbox - Read access to Decision management objects

Target sandbox - Create and edit access to Decisioning objects

Typical permissions include:

Prepare your target sandbox target-sandbox-preparation

Before running a migration, ensure your target sandbox is properly configured:

For more information about sandbox management, refer to Use and assign sandboxes.

API basics api-basics

Base URLs base-urls

Use the following base URLs depending on your environment:

Authentication authentication

All API requests require the following headers:

For detailed instructions on setting up authentication, refer to the Journey Optimizer authentication guide.

Workflow model workflow-model

Each API call creates or retrieves a workflow resource. Workflows are asynchronous operations that track the progress and results of migration tasks.

A workflow has the following properties:

Migration workflow migration-workflow

The migration process consists of two main steps: analyzing dependencies and executing the migration. Follow these steps to ensure a successful migration.

Step 1: Analyze dependencies analyze-dependencies

Before migrating, use the dependency workflow to identify what needs to be mapped from Decision management to Decisioning in your target sandbox. This analysis helps you understand the relationships between objects and prepare the necessary mappings.

Create a dependency workflow create-dependency-workflow

Use the following API call to create a dependency analysis workflow.

API format

POST /migration/service/dependency

Sandbox-level dependency (recommended first)

Start with a sandbox-level analysis to get a complete view of all dependencies:

curl --request POST \
  --url "https://platform.adobe.io/migration/service/dependency" \
  --header "Authorization: Bearer <IMS_ACCESS_TOKEN>" \
  --header "x-gw-ims-org-id: <IMS_ORG_ID>" \
  --header "x-api-key: <CLIENT_API_KEY>" \
  --header "Content-Type: application/json" \
  --data '{
    "imsOrgId": "<IMS_ORG_ID>",
    "sourceSandboxDetails": { "sandboxName": "<SOURCE_SANDBOX_NAME>" },
    "targetSandboxDetails": { "sandboxName": "<TARGET_SANDBOX_NAME>" },
    "requestLevel": "sandbox"
  }'

Offer-level dependency

To analyze dependencies for specific offers only, set requestLevel: "offer" and provide an offersList array with the offer IDs you want to analyze.

Decision-level dependency

To analyze dependencies for specific decisions only, set requestLevel: "decision" and provide a decisionsList array with the decision IDs you want to analyze.

Check dependency workflow status poll-dependency-status

Poll the dependency workflow to check when the analysis is complete.

API format

GET /migration/service/dependency/{id}

Request

curl --request GET \
  --url "https://platform.adobe.io/migration/service/dependency/<WORKFLOW_ID>" \
  --header "Authorization: Bearer <IMS_ACCESS_TOKEN>" \
  --header "x-gw-ims-org-id: <IMS_ORG_ID>" \
  --header "x-api-key: <CLIENT_API_KEY>"

When the status field shows Completed, the dependency analysis is ready. Use the workflow output to build your migration dependency mappings:

Step 2: Execute the migration execute-migration

Once you have analyzed the dependencies and prepared your mappings, you can execute the migration.

Create a migration workflow create-migration-workflow

Use the dependency mappings from Step 1 to configure and execute your migration.

API format

POST /migration/service/migrations

Sandbox-level migration

To migrate all decisioning objects from one sandbox to another:

curl --request POST \
  --url "https://platform.adobe.io/migration/service/migrations" \
  --header "Authorization: Bearer <IMS_ACCESS_TOKEN>" \
  --header "x-gw-ims-org-id: <IMS_ORG_ID>" \
  --header "x-api-key: <CLIENT_API_KEY>" \
  --header "Content-Type: application/json" \
  --data '{
    "imsOrgId": "<IMS_ORG_ID>",
    "sourceSandboxDetails": { "sandboxName": "<SOURCE_SANDBOX_NAME>" },
    "targetSandboxDetails": { "sandboxName": "<TARGET_SANDBOX_NAME>" },
    "createDataStream": true,
    "dependency": {
      "profileAttributeDependency": {
        "sourceAttr1": "targetAttr1"
      },
      "segmentsDependency": {
        "sourceSegmentKey1": {
          "segmentNamespace": "<TARGET_SEGMENT_NAMESPACE>",
          "segmentId": "<TARGET_SEGMENT_ID>"
        }
      },
      "contextAttributeDependency": {
        "sourceCtx1": "targetCtx1"
      },
      "datasetName": "<TARGET_DATASET_NAME>"
    },
    "requestLevel": "sandbox"
  }'

Offer-level migration

To migrate specific offers only, use requestLevel: "offer" and add an offersList array:

"offersList": ["offer-id-1", "offer-id-2"]

Decision-level migration

To migrate specific decisions only, use requestLevel: "decision" and add a decisionsList array:

"decisionsList": ["decision-id-1", "decision-id-2"]

Monitor migration status poll-migration-status

Poll the migration workflow to track its progress.

API format

GET /migration/service/migrations/{id}

Request

curl --request GET \
  --url "https://platform.adobe.io/migration/service/migrations/<WORKFLOW_ID>" \
  --header "Authorization: Bearer <IMS_ACCESS_TOKEN>" \
  --header "x-gw-ims-org-id: <IMS_ORG_ID>" \
  --header "x-api-key: <CLIENT_API_KEY>"

Migration results

When the status field shows Completed, the migration was successful. The workflow result includes:

When the status field shows Failed, review the errors[] array and result.error field for details about what went wrong.

Validate your migration validate-migration

After the migration completes successfully, verify that all objects were migrated correctly.

Validation checklist validation-checklist

Example test-runtime-delivery

If your migration created a datastream, you can test offer delivery using the following example:

curl --request POST \
  --url "https://edge.adobedc.net/ee/or2/v1/interact?configId=<DATASTREAM_ID>" \
  --header "Content-Type: application/json" \
  --header "x-request-id: <uuid>" \
  --data '{ "events": [ ... ] }'

Rollback a migration rollback

If you discover issues during validation, you can roll back a completed migration to restore the target sandbox to its previous state.

Create a rollback workflow create-rollback-workflow

Initiate a rollback by creating a rollback workflow that references the migration you want to revert.

API format

POST /migration/service/rollbacks/{migrationWorkflowId}

Replace {migrationWorkflowId} with the ID of the migration workflow you want to roll back.

Request

curl --request POST \
  --url "https://platform.adobe.io/migration/service/rollbacks/<MIGRATION_WORKFLOW_ID>" \
  --header "Authorization: Bearer <IMS_ACCESS_TOKEN>" \
  --header "x-gw-ims-org-id: <IMS_ORG_ID>" \
  --header "x-api-key: <CLIENT_API_KEY>"

Monitor rollback status poll-rollback-status

Poll the rollback workflow to track its progress.

API format

GET /migration/service/rollbacks/{rollbackWorkflowId}

Request

curl --request GET \
  --url "https://platform.adobe.io/migration/service/rollbacks/<ROLLBACK_WORKFLOW_ID>" \
  --header "Authorization: Bearer <IMS_ACCESS_TOKEN>" \
  --header "x-gw-ims-org-id: <IMS_ORG_ID>" \
  --header "x-api-key: <CLIENT_API_KEY>"

Handle concurrent workflows handle-concurrency

The Migration API allows only one workflow to run at a time per organization. If you attempt to create a new workflow while another is in progress, you will receive a 409 Conflict error response (“A workflow is already in progress…”).

In this case, wait for the in-progress workflow to complete, or retrieve the workflow ID and poll its status. Once the current workflow finishes, you can create a new one.

Entity mapping reference entity-mapping

When migrating from Decision management to Decisioning, entities are mapped as follows:

Workflow cleanup cleanup

Workflow resources can be deleted by service users only. Delete operations require an If-Match header with the workflow’s _etag value.

Available delete operations:

Related topics related-topics