Migrate Application Performance Monitoring (APM) data
Application Performance Monitoring (APM) is the core of many Splunk AppDynamics deployments. Migrating APM to Splunk Observability Cloud requires more than transferring configuration: the platforms use different entity models, instrumentation, metrics, tracing, topology, and alerting concepts.
Application Performance Monitoring (APM) is the core of many Splunk AppDynamics deployments. Migrating APM to Splunk Observability Cloud requires more than transferring configuration: the platforms use different entity models, instrumentation, metrics, tracing, topology, and alerting concepts.
The APM migration consists of six phases. Each linked phase page provides the detailed APM procedures, prerequisites, and exit criteria.
APM migration requirements at a glance
Use this matrix to identify the migration work, the primary risks, and the detailed phase page for each requirement. Complete the work on the linked phase pages.
| What you need to do | What to watch for | Where to do it |
|---|---|---|
| Inventory agent versions, instrumentation, Business Transactions, custom metrics, dashboards, Health Rules, integrations, and dependencies. | An incomplete inventory can leave required configurations or dependencies outside the migration scope. | Phase 1: Discovery and Assessment |
| Select a supported OpenTelemetry instrumentation and ingestion path. | An unsupported agent, runtime, platform, or deployment method can result in incomplete or unavailable telemetry. | Phase 3: Enable Application Telemetry |
| Configure service names, namespaces, environments, and other required resource attributes. | Inconsistent attributes can divide one application into unexpected services or combine unrelated services. Unbounded attribute values can also create unnecessary cardinality. | Phase 3: Enable Application Telemetry |
| Confirm that services, operations, request rate, error rate, duration, traces, errors, and dependencies appear as expected. | Missing traffic, instrumentation gaps, sampling, or broken trace-context propagation can produce incomplete telemetry or service relationships. | Phase 3: Enable Application Telemetry |
| Align important Splunk AppDynamics Business Transactions with the required Splunk Observability Cloud operations or workflows. | Different discovery and naming behavior can change how requests are grouped, filtered, and reported. | Phase 4: Migrate Monitoring Configurations |
| Translate metric expressions, units, filters, aggregations, dashboards, Health Rules, and notifications. Create required MetricSets. | Differences in metric models, units, thresholds, missing-data handling, or severity behavior can change dashboard values and alert results. | Phase 4: Migrate Monitoring Configurations |
| Rebuild, replace, retain, retire, or document items that cannot migrate directly. | Capabilities such as custom instrumentation, diagnostic sessions, and historical data require an approved alternative or retention plan. | Resolve Non portable or Unsuccessful Artifacts |
| Validate Business Transaction alignment, metric values and units, detectors, dashboards, notifications, traces, Service Maps, and diagnostic workflows. | Small differences can affect operational workflows even when the migration job reports success. | Phase 5: Validate and Prepare for Operations |
| Stop Splunk AppDynamics ingestion only after the migration wave meets its validation and cutover criteria. | Cutting over before telemetry and operational workflows are stable can create a temporary monitoring gap. | Phase 6: Cut Over and Stabilize |
APM model differences
Splunk AppDynamics and Splunk Observability Cloud organize, collect, and present APM data differently, so most source concepts do not have an exact one-to-one equivalent. These differences affect naming, filtering, metric queries, topology, tracing, alert behavior, dashboard results, and troubleshooting workflows. Understanding the differences helps you plan the migration well.
Use the following comparison table to identify which capabilities appear automatically through OpenTelemetry, which configurations must be translated or recreated, and which operational practices must change. During validation, assess whether Splunk Observability Cloud provides the required monitoring outcome as every Splunk AppDynamics object or value may not look exactly the same.
| Aspect | Splunk AppDynamics | Splunk Observability Cloud |
|---|---|---|
| Data model | Application to Tier to Node | Service namespace to service name to service instance |
| Business visibility | Business Transactions | Operations and workflows |
| Instrumentation | Splunk AppDynamics agents | OpenTelemetry-based instrumentation |
| Metrics | Hierarchical, pre-aggregated metric paths | Dimensional metrics queried with SignalFlow |
| Traces | Sampled transaction snapshots | Full distributed traces with spans |
| Topology | Agent-reported Flow Map | Trace-derived Service Map |
| Code visibility | Automatic method-level call graphs | Call Graph Profiling, AlwaysOn Profiling, traces, and custom spans |
Map Splunk AppDynamics concepts
Understanding how Splunk AppDynamics concepts map to Splunk Observability Cloud helps you design the target environment and evaluate migration results. The mapping determines how applications and their components are named, grouped, filtered, queried, displayed, and monitored after migration.
Use this mapping when you create the application inventory, define OpenTelemetry resource attributes, configure MetricSets and workflow rules, translate dashboards and Health Rules, and establish validation criteria. Because some mappings require configuration rather than direct migration, document the approved target representation for every important Splunk AppDynamics concept before migrating production applications.
| Splunk AppDynamics concept | Splunk Observability Cloud concept | Attribute or action |
|---|---|---|
| Application | Service namespace | Use the OpenTelemetry service namespace attribute; create a MetricSet when it is needed for filtering |
| Tier | Service | Use the OpenTelemetry service name attribute |
| Node | Service instance | Use the service instance identifier; create indexing when required |
| Node host | Host | Use the host name attribute |
| Business Transaction | Workflow or operation | Align naming through instrumentation, endpoint, operation, or workflow rules |
| Health Rule | Detector | Translate conditions into SignalFlow detector logic |
| Dashboard | Dashboard | Convert widgets and translate metric expressions |
| Flow Map | Service Map | Generated automatically from trace data |
| Transaction snapshot | Distributed trace | Use full traces and spans for investigation |
Configure the environment and service namespace attributes together so that services can be organized and filtered consistently.
Determine the APM migration scope
Use the application inventory created during Phase 1: Discovery and Assessment to determine the APM migration scope.
For the selected migration wave:
- Confirm which applications and environments are included.
- Review the inventoried APM telemetry, configurations, integrations, and operational workflows with their owners.
- Identify the monitoring outcomes that must be preserved in Splunk Observability Cloud.
- Document items that are excluded, deferred, or retained temporarily in Splunk AppDynamics.
- Assign a validation method and success criteria to each important capability.
Assign migration dispositions
Assign a migration disposition to every telemetry type, configuration, artifact, and operational capability in the migration scope. Before assigning a disposition, review Application Performance Monitoring telemetry and configuration dispositions for the supported treatment, requirements, and limitations of each item.
| Migration disposition | Description | Examples |
|---|---|---|
| Available from new telemetry | Splunk Observability Cloud derives the capability from telemetry generated after you establish supported OpenTelemetry instrumentation and ingestion. Migration Tool does not transfer existing Splunk AppDynamics telemetry. | Service Map, request rate, error rate, duration, distributed traces, service dependencies, database spans, HTTP client spans, and captured error details. |
| Explicit migration or configuration | You must use Migration Tool or configure Splunk Observability Cloud to reproduce the required monitoring outcome. | Business Transaction naming, Health Rule translation, dashboards, MetricSets, notification integrations, and recalibrated baseline thresholds. |
| Special handling | The item cannot migrate directly or requires a different implementation. You must rebuild, replace, retain temporarily, retire, or accept it as a documented gap. | Data collectors, custom exit calls, custom extensions, transaction snapshots, diagnostic sessions, and historical Splunk AppDynamics data. |
| Excluded | The item is not required in the target environment and is intentionally omitted from the migration. | Obsolete dashboards, unused Health Rules, retired integrations, and applications outside the approved migration wave. |
Migration dispositions are not migration phases or alternative migration paths. A single application will usually contain items with several dispositions.
Capabilities listed as Available from new telemetry still depend on supported instrumentation, successful export, representative application traffic, trace-context propagation, resource attributes, and applicable sampling or data-capture settings. Validate each required capability before migrating configurations that depend on it.
Migration dispositions are not migration phases or alternative migration paths. A single application can include items with several dispositions.
Example
A team plans to migrate its production checkout application. The inventory in Before You Begin identifies distributed application services, Business Transactions, Health Rules, dashboards, a webhook integration, custom data collectors, and historical Splunk AppDynamics data.
The team assigns the following migration dispositions:
| Inventory item | Migration disposition | Planned treatment |
|---|---|---|
| Service topology, request rate, error rate, duration, and distributed traces | Available automatically | Enable supported OpenTelemetry instrumentation and verify the data in Splunk Observability Cloud. |
| Checkout Business Transaction | Explicit migration or configuration | Align the corresponding operation name by using the required endpoint or workflow rules. |
| Checkout Health Rules | Explicit migration or configuration | Translate the conditions into Splunk Observability Cloud detectors and validate their alert behavior. |
| Operations dashboard | Explicit migration or configuration | Convert the widgets and metric expressions, configure the required dimensions, and validate the displayed values. |
| Webhook notification | Explicit migration or configuration | Recreate the integration and translate its payload variables. |
| Custom data collector | Special handling | Rebuild the data collection by using supported OpenTelemetry instrumentation. |
| Diagnostic-session workflow | Special handling | Replace it with distributed-trace analysis and profiling. |
| Historical Splunk AppDynamics data | Special handling | Retain access to Splunk AppDynamics for the agreed historical-data period; do not include it in the data transfer. |
| Obsolete dashboard | Excluded | Retire it rather than recreate it in Splunk Observability Cloud. |
The resulting scope identifies the telemetry that becomes available automatically, the configurations that require explicit migration, and the capabilities that require special handling. It also records intentional exclusions. The application owner can now assign an owner, planned treatment, validation method, and success criteria to each included item.