Validate migrated telemetry and configurations

Overview

Validate each migrated APM component through controlled tests before beginning sustained dual-platform validation. Use representative traffic and the success criteria approved for the migration wave.

Prerequisites

Confirm that:

• All in-scope applications send current telemetry to Splunk AppDynamics and Splunk Observability Cloud.
• Business Transaction rules, MetricSets, detectors, dashboards, and notification integration in scope are available.
• Non portable artifacts have an approved disposition.
• A test environment or an approved safe production test method is available.
• Application and configuration owners can review the results.
• Baseline detectors have enough target telemetry for meaningful evaluation. Baseline bounds can require 15 to 30 days of data.

Confirm migration coverage

Compare the Migration Analytics Dashboard with the approved migration-wave inventory.

Confirm that:

• Every in-scope application is represented in the migration results.
• Artifact counts are consistent with the approved scope and individual Migration Jobs results.
• Investigate unexpected partial, pending, warning, or failed results.
• Account for excluded, deferred, unsupported, and manually recreated artifacts.

The analytics dashboard reports migration processing. It does not replace functional validation in Splunk Observability Cloud.

Validate Business Transactions

For every critical Business Transaction:

1. Generate representative traffic.
2. In Splunk Observability Cloud, select APM > Overview > Business Transactions.
3. Confirm that the approved Business Transaction name appears.
4. Open the Business Transaction and verify that it contains the expected traces, services, and endpoints.
5. Confirm that dashboards and detectors filtering by sf_workflow use the generated Business Transaction name.
6. Compare request rate, error rate, and duration with Splunk AppDynamics over equivalent traffic and time ranges.
7. Confirm that excluded health checks and unwanted operations do not appear.
8. Correct the applicable Business Transaction or endpoint rule and repeat the test when required.

Use the migration wave's approved match target. Record every missing, renamed, consolidated, or intentionally different transaction.

See Configure Business Transaction rules.

Validate detectors

For every critical detector:

1. Record the signal, scope, trigger condition, clear condition, evaluation window, and notification route.
2. Use controlled traffic or error injection to exercise the condition.
3. For a multi-condition detector, test each condition separately and in the required AND or OR combination.
4. Verify warning and critical criteria separately.
5. Confirm that the alert triggers with the intended severity and affected dimensions.
6. Confirm that the alert clears when the condition resolves.
7. Verify missing-data behavior and sustained-duration or X-out-of-Y logic when applicable.
8. Confirm that the expected notification and runbook link are delivered.
9. Record the result and any tuning required.

Evaluate baseline detectors only after sufficient target history has accumulated. Preview the detector against representative data before enabling production paging.

See Preview detector alerts.

Validate dashboards

Open the corresponding Splunk AppDynamics and Splunk Observability Cloud dashboards and use equivalent traffic, filters, and time ranges.

For every migrated chart, verify:

• Metric identity and duration unit.
• Aggregation, rollup, and grouping.
• Service, environment, namespace, workflow, endpoint, and instance filters.
• P50, P90, P95, or P99 calculation when applicable.
• Trend shape and data freshness.
• Missing-data and no-traffic behavior.
• Chart type, labels, variables, links, and permissions.
• Drill-down and filtering behavior.

Record material differences and correct the SignalFlow or chart configuration. Use the migration wave's approved data-variance tolerance.

See Create and customize dashboards.

Validate traces and service topology

1. Run representative transactions across every critical path.
2. In APM > Trace Analyzer, locate the corresponding traces.
3. Confirm that each trace contains the expected services, spans, timing, attributes, errors, database calls, and external calls.
4. In APM > Service map, select the applicable environment and validation time range.
5. Confirm that expected upstream and downstream relationships, databases, APIs, and inferred services appear.
6. Investigate missing, orphaned, or incorrectly connected services.
7. Verify supported profiling or custom-span visibility when it is part of the approved replacement workflow.

See Search traces using Trace Analyzer and View dependencies in the service map.

Validate notification integration

For every approved notification integration:

1. Use a controlled detector test.
2. Confirm delivery for both trigger and clear events.
3. Verify severity, detector and rule names, affected service and environment, timestamp, message, and deep link.
4. Confirm routing, deduplication, authentication, and payload formatting.
5. Record delivery or formatting issues and repeat the test after correction.

For setup and channel-specific validation instructions, see Send alert notifications to services using Splunk Observability Cloud. To verify the recipients assigned to each detector rule, see Manage notification recipients. For webhook-specific payload, authentication, testing, and delivery requirements, see Migrate HTTP Request Templates to webhook integrations and Send alert notifications to a webhook.

Do not enable production paging until you validate and approve the notification behavior.

Validate MetricSets

For every MetricSet used by a migrated dashboard or detector:

1. Index and activate the required dimension.
2. Verify that expected dimension values appear.
3. Apply the filter and confirm that it selects the intended telemetry.
4. Verify the required grouping in the dashboard or detector.
5. Open Tag Spotlight for the applicable service. Select the indexed dimension and confirm that the expected values appear and can be used to filter request, error, and duration data. See Analyze service performance with Tag Spotlight.

Controlled-validation gate

Controlled validation is complete when:

• Critical Business Transactions have approved target behavior.
• Critical detectors trigger, clear, and notify as intended.
• Dashboards meet the approved accuracy and usability criteria.
• Required traces, services, dependencies, and attributes are visible.
• Required MetricSets support the intended filters and groupings.
• Every identified issue has an owner and treatment.
• The migration owner approves beginning sustained dual-platform validation.