Migrate HTTP Request Templates to webhook integrations

Learn how to migrate Splunk AppDynamics HTTP Request Templates to Splunk Observability Cloud webhook integrations and validate their payloads and routing.

Migrate supported Splunk AppDynamics HTTP Request Templates to Splunk Observability Cloud webhook integrations, then review authentication, transport security, payload variables, notification routing, and unsupported source behavior.

Migration Tool can translate common payload variables. Conditional source logic and source-specific delivery controls require manual review.

Prerequisites

Confirm that:

  • The HTTP Request Template inventory identifies the templates in the migration wave.

  • Each endpoint and integration has an owner.

  • The target endpoint supports HTTPS and the required TLS version.

  • Store authentication secrets through the approved secret-management process.

  • Define required detectors and notification routing.

  • Document the source payload, headers, conditional logic, retry settings, and success criteria.

Run the migration

  1. Follow New Migration Job.

  2. Select the approved source and destination connections.

  3. Select the HTTP Templates tab.

  4. Select only the templates approved for the migration wave.

  5. Review the migration summary, including the selected templates, source and destination connections, and the migration tag used to identify the job in the Migration Jobs list.

    A migration tag uniquely labels the migration job. You can keep the generated tag or customize it before starting the job, for example, wave1-prod-apps.

  6. Start the migration job.

  7. Review artifact-level results in the Migration Jobs Dashboard.

  8. Open every created webhook integration.

Review the payload

Common source values require target alert-message variables. Verify every value against the current Alert message variables reference.

Source purpose Candidate target value

Health Rule name

Detector name variable

Severity and event type

Severity and event-type variables

Message and title

Description and message-title variables

Deep link

Detector URL

Timestamp

Timestamp

Application

An approved dimension such as service.namespace

Tier or service

service.name

Host

An approved host dimension such as host.name

Account or organization

Organization identifier

Rewrite each Splunk AppDynamics Velocity variable and conditional expression using a supported Splunk Observability Cloud variable or helper function. Copy the target syntax from the applicable variable reference. Use triple braces only where the reference specifies that the value must remain unescaped. After editing the payload, send test trigger and clear notifications and confirm that the rendered request contains valid JSON with the expected values.

Note:

Detector alert messages and webhook custom payloads can provide different variables. Use the variable reference for the field you edit.

Rebuild unsupported behavior

  1. Rewrite source #if or #else behavior that Migration Tool cannot translate automatically.

  2. Split conditional behavior across detector rules or notification routes when required.

  3. Replace source-specific custom retries, redirect limits, and success or failure evaluation with the supported target behavior.

  4. Replace custom email-template behavior with detector-level messages or another approved notification service.

  5. Define another operational workflow for Splunk AppDynamics actions that have no webhook equivalent, such as taking a thread dump, running a diagnostic session, or running a script.

  6. Record every accepted payload or delivery difference.

Secure and test the integration

Follow Send alert notifications to a webhook.

Confirm that:

  • The endpoint uses HTTPS and the required TLS version.

  • Protect authentication and secret configuration.

  • A controlled detector test sends the expected trigger and clear notifications.

  • The endpoint receives the expected headers and payload.

  • Encoded and raw values render correctly.

  • Verify severity, service, environment, detector, rule, timestamp, and deep link values.

  • Understand platform-defined retry behavior.

  • Attach the integration only to the approved detector rules.

Complete this task when every selected template has a tested target integration, an approved alternative, or an assigned disposition.