Staging to Production: The Deployment Checklist That Prevents Regression

Staging exists to make mistakes cheap — but the deployment step is where teams get careless, because “it works on staging” feels like the finish line. It is the starting line. This is the deployment checklist our team runs for every push, refined by every regression that slipped through.

Before deploying: inventory the change

• What exactly moves? Code files (theme, plugins), database changes (options, new tables), and content. Most botched deployments mixed all three without tracking which.
• Diff, don’t trust memory: diff -r the theme/plugin folders, and compare option tables. Staging accumulates experiment debris — deploy the intended change, not the whole staging state.
• Check the staging-config leak: debug constants, staging URLs in options, different SMTP settings. The environment-mismatch trap from the staging workflow guide bites hardest here.

The deployment order

1. Backup production — and verify it. The rollback plan is only as real as this backup (restorability per the backup test).
2. Deploy database changes first (if code depends on new options/tables), then files. Or files first if the reverse dependency — decide per change and write the order down.
3. Deploy during the low-traffic window you identified from analytics, not convenience.
4. Clear caches immediately after: page cache, object cache if options changed, and builder caches — stale caches make correct deployments look broken and broken ones look fine.

The verification pass (15 minutes, non-negotiable)

• Walk the critical flows as a real user: home → key landing page → form submit → (for stores) checkout. Logged in and out.
• Check the browser console on each — a new JS error is a regression even when the page “looks fine”.
• Read the debug log tail after a few minutes of real traffic — new warnings from the deployed change show up here first.
• Confirm forms deliver: one real submission, received in the inbox — the silent-failure mode from the email guide.

The rollback plan (write it before you deploy)

One line per deployment: what changed, how to revert (file set from backup, option snapshot, or plugin downgrade per the rollback options), and the decision threshold — “if checkout fails, revert within 10 minutes.” Teams with a written threshold revert quickly; teams deciding under pressure negotiate with themselves for an hour.

After the deploy

Watch Search Console coverage and Core Web Vitals for a week, and compare conversion metrics against the pre-deploy baseline — regressions in revenue signal technical regressions nobody noticed. The free audit catches deployment damage that accumulates quietly (orphaned options, duplicate caches).