Roll back the cutover
Reference information for rolling back a cutover and restoring dual-signal operation.
Use this procedure when you meet an approved rollback trigger during cutover or stabilization.
Start the rollback
The rollback decision owner must confirm the trigger and authorize the rollback. Stop further cutover activity for the affected wave.
Record the affected applications, trigger, time, agent versions, deployment method, and available evidence before changing the configuration.
Restore dual-signal operation
- Restore the last verified agent package, configuration, deployment manifest, and Collector settings.
- Return the agent deployment mode to the verified dual-signal value:
| Runtime | Restore |
|---|---|
| Java | Restore -Dagent.deployment.mode=dual or AGENT_DEPLOYMENT_MODE=dual, using the method you previously validated for the application. |
| .NET | Restore AGENT_DEPLOYMENT_MODE=dual. |
| Node.js | Restore the documented dual value in the same environment-variable or application-configuration location used before cutover. |
- If the cutover replaced the combined agent, restore the approved combined-agent package, dependency, and startup configuration.
- Restore previous notification routing when required.
- Restart or redeploy through the approved change process.
- Generate representative traffic.
Verify the rollback
Confirm that:
- Splunk AppDynamics and Splunk Observability Cloud receive telemetry from the affected application.
- Required services, operations, dashboards, and detectors are available.
- Application latency, throughput, error rate, and resource use fall within approved limits.
- Agent and Collector logs show no unresolved errors.
- Alert routing matches the rollback plan.
Record the rollback result, timestamps, evidence, and follow-up owner. Identify and resolve the cause before rescheduling cutover.