Analyze Business Transaction compliance

Compare the Business Transactions discovered in Splunk AppDynamics with the OpenTelemetry operations identified in Splunk Observability Cloud and included in the Business Transaction comparison report.

Splunk AppDynamics uses entry-point detection and naming rules. Splunk Observability Cloud derives operations from trace spans and uses APM rules to control aggregation and display names. You do not need exact object parity, but operators must retain access to critical transaction monitoring outcomes.

Prerequisites

Confirm that:

• You can view representative traces and metrics in Splunk Observability Cloud.
• The target telemetry contains the approved service identity values.

Review operations in Splunk Observability Cloud

Splunk APM derives operations from the names of spans received from OpenTelemetry instrumentation. A trace can contain operations from multiple services. Server and consumer operations can also appear as service endpoints.

To review the operations for an application:

1. Generate representative traffic for the application.
2. In Splunk Observability Cloud, select APM > Trace Analyzer.
3. Select the migration environment and a time range containing the representative traffic.
4. Filter the traces by the applicable service.
5. Open representative traces and review the operation name and service associated with each span.
6. Open the service view and select Endpoints to review the server and consumer operations exposed as endpoints.
7. Confirm that important operation and endpoint names remain stable and do not contain unbounded values such as request IDs or raw identifiers.

See Key concepts in Splunk APM and Use the service view in Splunk APM.

Generate the comparison report

Generate the Business Transaction Analysis: Splunk AppDynamics vs Splunk Observability Cloud report by following the steps outlined in Migration Tool reports.

The analysis uses these inputs:

Analyze the results

1. Compare the Splunk AppDynamics and Splunk Observability Cloud totals and match rate.
2. Review every missing, misnamed, split, consolidated, or extra operation.
3. Confirm whether OpenTelemetry instrumentation produces stable, low-cardinality span and endpoint names.
4. Determine whether differences represent intentional improvements, acceptable differences, or gaps requiring correction.
5. Assign the appropriate treatment.

Do not create rules only to make the totals equal. Preserve the names and groupings that operators, detectors, dashboards, and runbooks depend on.

Reference example: MovieService application

Use the following iterative approach to improve Business Transaction parity. Run the comparison report after each stage so that you can measure the effect of each configuration change.

1. Establish the baseline

Generate representative traffic for the application and run the Business Transaction comparison report.

For example, Splunk AppDynamics might report one Business Transaction named /movie, while Splunk Observability Cloud initially shows several operations:

MovieService identifies the originating tier or service. In Splunk Observability Cloud, the corresponding Business Transaction appears as MovieService:/movie because the service name has the prefix.

Record the initial match rate and identify any dynamic path values, such as movie IDs.

2. Normalize dynamic values

Before adding backend rules, confirm that instrumentation produces stable, low-cardinality names. For example:

GET /movie/847293 → GET /movie/{id}

Correct any unbounded span or endpoint names before continuing.

3. Apply operation grouping

Group related movie operations that have the same monitoring and alerting requirements. Use the stable operation prefix identified in the report and configure the rule at the MovieService service level.

Generate new traffic and verify that:

• The configuration aggregates the intended movie operations.
• Unrelated operations remain separate.
• The configuration reduces cardinality.
• The original operation names remain searchable in traces.

Run the comparison report again and record the change in match rate.

4. Apply endpoint rules

Use endpoint rules to normalize the remaining endpoint variants. Configure the narrowest match conditions and place specific rules before broader rules.

For example, map the approved movie endpoint variants to /movie:

• GET /movie
• POST /movie
• GET /movie/{id}
• DELETE /movie/{id}

The endpoint remains /movie; the MovieService: prefix applies to the resulting Business Transaction display name.

Generate new traffic and verify that the Endpoints view, endpoint metrics, dashboards, and detectors use the expected endpoint name. Confirm that unrelated endpoints, such as health checks, remain unchanged.

Run the comparison report again and record the remaining differences.

5. Apply the workflow rule

After operation and endpoint normalization, configure a workflow rule to align the final Business Transaction display name with Splunk AppDynamics.

Create a custom workflow rule that matches the approved movie operation or endpoint set and assigns the display name MovieService:/movie. Place more-specific rules and exclusions before broader rules.

Verify that:

• MovieService:/movie appears as the Business Transaction name.
• The Business Transaction contains the expected traces, services, and endpoints.
• The associated Business Transaction rule matches the intended rule.
• Dashboards and detectors using sf_workflow=MovieService:/movie return the expected data.
• The configuration excludes health checks, database operations, and internal operations unless you intend to include them.

6. Validate the final result

Run the comparison report one final time and compare the baseline with the post-configuration result.

Record:

• The initial and final match rates.
• Operations grouped.
• Endpoints renamed or consolidated.
• Workflow rules added.
• Any intentional differences from Splunk AppDynamics.
• The validation traffic and rule owners.

This sequence isolates the effect of each configuration layer: operation grouping reduces operation fragmentation, endpoint rules normalize endpoint identity, and workflow rules establish the final service-prefixed Splunk AppDynamics-aligned Business Transaction name.

Record the analysis

For every important transaction or gap, record:

• Source Business Transaction and target operation.
• Match classification.
• Required rule or instrumentation change.
• Rule owner and application owner.
• Expected sf_workflow, service, and endpoint values.
• Validation traffic and test method.
• Approved difference or accepted gap.

This task ends when every critical Business Transaction has a corresponding target operation or an approved treatment, and every required rule has an owner.