Supported migration scope and limitations
Ensure that you confirm the released support status before starting a migration. Availability can depend on your Splunk AppDynamics deployment, Splunk Observability Cloud realm, user role, agent version, and enabled product features.
Ensure that you confirm the released support status before starting a migration. Availability can depend on your Splunk AppDynamics deployment, Splunk Observability Cloud realm, user role, agent version, and enabled product features.
Supported environments
Before you create a migration job, confirm that your source and destination environments are supported.
| Environment component | Supported scope | How to identify your environment |
|---|---|---|
| Splunk AppDynamics deployment | Splunk AppDynamics SaaS | Confirm that the source Controller is a Splunk AppDynamics SaaS Controller. |
| Splunk AppDynamics Controller regions/versions | The following regions are supported: Oregon, São Paulo, Frankfurt, London, Mumbai, Singapore, and Sydney. | Record the Controller URL, version and region. Contact your Splunk representative or Splunk Support if you cannot determine the region. |
| Splunk Observability Cloud realms |
Supported realms: us0
Important: This feature is being released as part of a phased rollout. Access is currently limited to a select group of accounts within specific realms and will be gradually expanded to all accounts across all realms. If you would like to request access to this feature, contact your account representative for further information.
|
In Splunk Observability Cloud, open the user menu and record the organization and realm. |
| Splunk Observability Cloud organizations | Migration Tool feature must be enabled for the destination organization. | Log in to the intended organization and confirm that is available. |
| Operator roles | Administrator and power user | Ask an organization administrator to confirm your role. |
| Agent types and versions | Java, .NET, Node.js, and Machine Agent versions that support dual-signal mode and the required service, tier, and deployment-environment attribute propagation. See the agent-specific documentation for the minimum version for each agent. Extensions are not included in this release. | Inventory the agent type and version for each application in the migration wave. |
Supported operators
You can access Migration Tool if you have an administrator or power-user role in the destination Splunk Observability Cloud organization and your organization has the required entitlement and feature enabled.
Telemetry prerequisite
Migration Tool migrates supported monitoring configurations and artifacts. It does not transfer historical Splunk AppDynamics metrics, traces, logs, or transaction snapshots.
Before migrating configurations that depend on APM telemetry, establish a supported OpenTelemetry ingestion path for every application in the migration wave. Confirm that the selected instrumentation supports the application's agent version, runtime, operating system, architecture, and deployment method.
If a supported Combined Agent is not available, determine whether you can use independent Splunk OpenTelemetry instrumentation.
Applications that do not have an approved instrumentation path require special handling and must not proceed as an automatic telemetry migration.
Application Performance Monitoring telemetry and configuration dispositions
The table describes how common Splunk AppDynamics APM data and configurations are handled. Support can depend on the current Migration Tool release, agent version, runtime, platform, packaging method, and enabled Splunk Observability Cloud capabilities.
Available from new telemetry
These capabilities are not copied from Splunk AppDynamics. Splunk Observability Cloud derives them from new telemetry after supported OpenTelemetry instrumentation and ingestion are active.
| Capability | Target result | Requirements and limitations |
|---|---|---|
| Service topology | Service Map | Requires instrumented services, representative traffic, and working trace-context propagation. Services without trace traffic might not appear. |
| Request rate, error rate, and duration | APM service and endpoint metrics | Derived from received spans. Validate metric availability, dimensions, units, and expected values. |
| Distributed traces | Traces and span waterfalls | Includes spans produced by supported automatic and custom instrumentation. Trace completeness can depend on context propagation, instrumentation coverage, and sampling. |
| Service dependencies | Trace-derived service relationships | Requires trace traffic between the participating services and successful propagation of trace context. |
| Database activity | Database client spans | Available when the selected instrumentation captures the database library and operation. Query text and attributes can be limited or redacted by configuration and security policy. |
| Outbound HTTP activity | HTTP client spans | Available when the client library is supported and instrumented. |
| Application errors | Error status, exception events, and related attributes | Available when instrumentation records the error or exception. Validate that sensitive information is not captured. |
Explicit migration or configuration
| Splunk AppDynamics artifact | Splunk Observability Cloud result | Required treatment |
|---|---|---|
| Business Transaction naming | Operations or workflows | Configure instrumentation, endpoint, operation-grouping, or workflow rules when the default operation names do not provide the required grouping. |
| Health Rules | Detectors | Translate supported conditions into detector and SignalFlow logic. Validate thresholds, evaluation windows, severities, recovery behavior, and missing-data behavior. |
| Dashboards and widgets | Dashboards and charts | Migrate supported artifacts and translate metric expressions, filters, aggregations, variables, and units. |
| Entity filtering | Dimensions and MetricSets | Configure stable resource attributes and create the required MetricSets when a dimension is not available for the intended filtering or analytics. |
| Notification actions | Notification integrations and detector notification rules | Recreate or migrate supported integrations. Translate supported payload variables and test delivery, recovery messages, and severity behavior. |
| Baseline thresholds | Detector thresholds or baseline logic | Establish sufficient target telemetry and recalibrate the threshold. Historical Splunk AppDynamics baseline data is not transferred. |
Special handling
| Splunk AppDynamics artifact | Disposition | Required treatment |
|---|---|---|
| Data collectors | Rebuild | Implement the required data collection using supported OpenTelemetry instrumentation. |
| Custom exit calls | Rebuild | Create supported custom spans and propagate trace context where required. |
| Custom extensions | Rebuild or replace | Replace the extension with supported OpenTelemetry instrumentation, Collector components, or another supported integration. |
| Transaction snapshots | Replace | Use distributed traces, spans, attributes, and profiling for new investigations. Existing snapshots do not transfer. |
| Diagnostic sessions | Replace | Use trace analysis, Call Graph Profiling, AlwaysOn Profiling, or another approved diagnostic workflow. |
| Historical metrics, logs, traces, and snapshots | Retain temporarily or retire | Historical Splunk AppDynamics telemetry does not transfer. Retain access to Splunk AppDynamics for the approved historical-data period when required. |
After submitting the job, monitor it on the Migration Jobs page. Open Job Details and review the summary for any failed, partially complete, or skipped item. Do not interpret the presence of a source item as confirmation that the current release can migrate it.
Supported artifacts
The table lists the self-service scope:
| Splunk AppDynamics SaaS artifact | Splunk Observability Cloud artifact |
|---|---|
| Health Rule | Detector |
| Dashboard | Dashboard |
| Dashboard widget | Chart |
| HTTP Request Template | Integration, such as a webhook |
Data that is not migrated
Migration Tool does not transfer historical Splunk AppDynamics metrics, logs, traces, or transaction snapshots to Splunk Observability Cloud.
You must generate telemetry in Splunk Observability Cloud using a supported agent and OpenTelemetry ingestion path.
Target-artifact limitations
Migration Tool does not delete detectors, dashboards, charts, or integrations from Splunk Observability Cloud.
Re-migrating an artifact can overwrite the corresponding artifact in Splunk Observability Cloud. Review the transformed configuration and preserve any required target configuration before re-migrating.
Validation requirement
A successful migration status confirms that the target artifact was created or updated. It does not confirm functional equivalence.
Validate the artifact's data, calculations, thresholds, schedules, severity, notifications, ownership, and operational behavior before enabling it in production.