When should a rollback plan be written?

Before cutover. The source path, rollback triggers, switching order, owner and validation checks should be known before production ownership changes.

Should the old Zapier or Make automation be deleted immediately?

No. During the agreed verification and rollback window, the source automation should remain available unless a specific technical or business constraint requires another plan.

What triggers a rollback?

Triggers are defined per workflow and can include blocking parity failures, missing or duplicate side effects, unacceptable error rates, or an incident that breaches the agreed acceptance threshold.

Evidence artifact · rollback trigger matrix

A rollback plan belongs before cutover.

“We can switch it back if something breaks” is not a rollback plan. A usable plan names the source state to preserve, the triggers that stop the cutover, the switching order, the owner, and the evidence that proves recovery.

Run the Free Fit Check See parity testing

The matrix below is a synthetic example. Actual triggers and actions are scoped per workflow.

Rollback trigger matrix

Decide in advance what makes “go back” the correct action.

Observed condition	Decision	Way-back action	Evidence after recovery
Blocking parity case fails	Do not cut over	Keep source as production owner; fix candidate	Source still handles accepted traffic
Missing or duplicate business write	Stop / rollback	Return ownership to preserved source path	Counts and affected records reconciled
Critical destination API failure beyond threshold	Rollback if threshold is breached	Restore source routing in documented order	Expected source executions resume
Intentional difference is not approved	No-go	Keep candidate inactive	Gap remains explicit and unresolved

Minimum rollback packet

Preserved source state

What remains available, what is frozen, and what must not be deleted or downgraded yet.

Ownership map

Which platform owns triggers, webhooks, schedules and writes before, during and after cutover.

Switching order

The exact dependency order for redirecting traffic and restoring the source path.

Recovery checks

The observable facts that prove the source path is safely handling production again.

Reversible cutover sequence

Freeze the accepted candidate

Record the exact n8n version/configuration and unresolved gaps.

Confirm rollback readiness

Source path, trigger ownership, credentials and recovery checks are still available as planned.

Human-approved switch

Production changes happen only after the acceptance evidence is reviewed.

Watch the acceptance window

Use the agreed monitoring signals and rollback triggers, not intuition.

Close the rollback window deliberately

Only after the replacement is accepted and the business chooses to retire the source path.

Related evidence

Parity testing

Define what must pass before cutover.

Independent migration audit

Review rollback readiness before production change.

n8n monitoring

Keep post-cutover incidents and stale runs visible.

Know the way back first

Check whether a reversible migration is realistic for your workflow.

The Fit Check is free and comes before paid work or production credential handling.

Run the Free Fit Check