Establish baselines and success criteria

Record the current Splunk AppDynamics behavior for each application in the migration wave. Use these baselines to evaluate telemetry, configuration, and application performance in later phases.

Record the current Splunk AppDynamics behavior for each application in the migration wave. Use these baselines to evaluate telemetry, configuration, and application performance in later phases.

Select a representative time period that includes normal and peak traffic. Record the time range, time zone, source, aggregation, and units used for every baseline.

Note: During Phase 1, capture the current Splunk AppDynamics baseline and define how you will compare results. Do not calibrate Splunk Observability Cloud baseline detectors yet. Calibrate and validate them after Splunk Observability Cloud has collected sufficient representative telemetry.

Record the baseline

Area Information to record
Application scope Applications, services, environments, and dependencies that must remain visible
Business Transactions Critical Business Transactions, normal operation names, and expected transaction coverage
Traffic Request rate, throughput, and normal and peak traffic periods
Latency Average, P50, P95, and P99 response times for critical applications and transactions
Errors Error rate, important error types, and normal error patterns
Resources CPU, memory, garbage collection, thread-pool use, and network utilization when applicable
Dashboards Dashboards, charts, filters, units, and operational views required after migration
Alerting Critical Health Rules, normal alert frequency, severity, timing, recovery behavior, and recipients
Topology Required applications, tiers, nodes, backends, and upstream and downstream dependencies
Diagnostics Transaction snapshots, call graphs, diagnostic sessions, profiling, and troubleshooting workflows in use
Known exceptions Existing monitoring gaps, unusual traffic periods, maintenance events, and unreliable baseline data

Do not use a period affected by an unplanned incident or unusual change unless you document its effect on the baseline.

Define success criteria

For each important monitoring outcome, define how you will determine whether the migration is successful.

Outcome Define
Application visibility Applications, services, operations, and dependencies that must appear
Naming and grouping Required service, environment, operation, and workflow names
Metric comparison Metrics to compare and the acceptable difference in values or trends
Application performance Acceptable change in latency, throughput, error rate, and resource utilization
Traces and topology Required transaction paths, services, errors, attributes, and dependencies
Dashboards Charts, values, filters, units, and drilldowns that must work
Detectors Conditions, thresholds, severities, evaluation timing, recovery behavior, and missing-data handling
Notifications Required recipients, integrations, message content, and delivery behavior
Operational workflows Investigation, incident-response, escalation, and troubleshooting tasks that teams must be able to complete
Special handling Accepted differences, retained Splunk AppDynamics capabilities, deferred work, and documented gaps

Success criteria preserve the required monitoring and operational outcomes. They don't need to reproduce every Splunk AppDynamics object or behavior exactly.

Do not copy example percentage thresholds into the migration plan without review. Application owners must approve the acceptable variance and performance-impact limits for their applications.

Approve the baseline and success criteria

  • The baseline period includes representative normal and peak traffic.
  • Each baseline records its source, time range, time zone, aggregation, and unit.
  • Critical applications and Business Transactions have measurable success criteria.
  • Acceptable metric variance and application-performance changes are defined.
  • Required dashboards, alerts, notifications, traces, topology, and operational workflows are identified.
  • Accepted differences and known gaps are documented.
  • Each success criterion has a validation method and owner.
  • Application owners and migration stakeholders approve the baseline and success criteria.

This task is complete when the migration team has an approved baseline and a measurable validation plan for every application in the wave.