Resolve nonportable or unsuccessful artifacts

Resolve APM data and configurations that Migration Tool cannot migrate directly, can migrate only partially, does not support, or cannot migrate successfully during Phase 4.

Do not force every Splunk AppDynamics implementation into Splunk Observability Cloud. Preserve the required monitoring outcome and document every accepted difference.

Classify each item

Review the Migration Analytics Dashboard to identify applications and artifact categories that the dashboard reports as partially migrated or pending. Use the Migration Jobs Dashboard to identify the affected artifacts.

Assign one disposition:

Record the rationale, owner, due date, validation method, and operational effect.

Handle nonportable data and capabilities

The following items require special handling:

• Historical Splunk AppDynamics metrics, logs, traces, and events remain in Splunk AppDynamics.
• Use distributed traces in place of transaction snapshots.
• Diagnostic sessions require trace analysis, profiling, or another approved workflow.
• Data collectors require manual OpenTelemetry instrumentation.
• Custom exit calls require custom OpenTelemetry spans.
• Custom extensions require supported OpenTelemetry instrumentation.
• Method-level call graphs can require supported Call Graph Profiling.
• Critical code paths can require additional custom spans.
• Custom metrics can require a new collection and dimensional model.
• Applications that cannot use a supported combined agent require another supported OpenTelemetry instrumentation method. Resolve instrumentation compatibility issues in Phase 3: Establish dual telemetry before migrating configurations that depend on the resulting telemetry.

Define the approved period for retaining Splunk AppDynamics historical access and assign an owner.

Review partially portable configurations

Review and document differences such as:

• Dashboard widgets without a direct visualization equivalent.
• Baseline and trend behavior that cannot be reproduced exactly.
• Replace health-state widgets with charts linked to detectors.
• Health Rule conditions that require manual SignalFlow.
• Wait-time, scheduling, missing-data, or severity differences.
• Custom email templates or digest behavior without a direct equivalent.
• Conditional HTTP-template logic that requires restructuring.
• Security or cross-origin restrictions block external images.
• Custom metrics or dimensions that you cannot use or index.
• Services without traffic that do not appear in the trace-derived Service Map.

Handle failed migrations

For every failed artifact:

1. Record the job identifier, artifact, source application, destination organization, timestamps, and error.
2. In the Migration Jobs Dashboard, open the failed artifact and select View Details. Record the error message and the failed step.
3. Determine where the failure occurred:

1. Review the corresponding Migration entry in Audit Logs to confirm the job activity, user, and time of the failure.
2. Correct the identified issue. If the error does not identify the cause, preserve the job ID, artifact name, timestamps, and error details, and contact Splunk Support.
3. Review the transformed configuration before retrying the artifact.

Review Migration entries in Audit Logs when you need the recorded job activity, user, and timestamp. Use Migration Jobs for artifact-level errors, results, and remigration actions.

An overall completed job does not mean that every artifact succeeded.

Prepare for and re-migrate artifacts

Re-migration can overwrite the corresponding target artifact. Before retrying:

1. Open the artifact in Splunk Observability Cloud and determine whether it contains changes that must be preserved.
2. Record or export the current configuration using an approved method. For dashboards, see Import and export dashboards.
3. Correct the issue that caused the failed or partial result.
4. In the Migration Jobs Dashboard, open the applicable job and use Re-migrate to retry the affected artifacts.
5. Review the new artifact-level result.
6. Open the target artifact and confirm that the required configuration and any approved manual changes appear.
7. Restore or reapply preserved changes when required.

Migration Tool does not remove unwanted target detectors, dashboards, charts, or integrations. Manage these artifacts in Splunk Observability Cloud through your approved change process.

Replace diagnostic workflows

When direct migration is not possible:

• Investigate full distributed traces instead of transaction snapshots.
• Enable supported Call Graph Profiling when you need method-level hierarchy.
• Use supported AlwaysOn Profiling for CPU and memory visibility correlated with traces.
• Add custom spans for code paths requiring span-level detail.
• Use Service Map and trace dimensions instead of manually arranged Flow Maps.
• Create runbooks for every replacement workflow.

Completion criteria

This task is complete when:

• You assign an approved disposition to every failed, partial, unsupported, or non-migratable item.
• You assign an owner and validation method to every item.
• You complete, schedule, or explicitly defer required manual recreation or rebuilding.
• You reconcile target artifacts affected by retries or overwrites.
• You document historical-data retention requirements.
• You document replacement investigation and profiling workflows.
• No critical monitoring capability lacks an owner or approved treatment.
• Stakeholders approve accepted gaps and behavior differences.