Build a staging-to-production deployment checklist
A deployment checklist scenario for pushing staging changes live without overwriting fresh orders, comments, or form submissions that arrived on production during the build.
I've been building a redesign and new plugin set on staging.[clientsite].com for the
past three weeks while the live site at [clientsite.com] kept taking real WooCommerce
orders and contact form submissions. Now I need to push staging to production without
losing any of that live activity.
Build me a deployment checklist that treats this as a one-directional, partial sync
instead of a naive "clone staging over production," covering what generic deployment
guides miss:
1. Data direction conflict: identify which tables must come FROM staging (theme,
plugin config, new page content) versus which must be preserved FROM production
(orders, order meta, customers, comments, form entries created during the staging
build), and the specific method to merge these instead of overwriting one with the
other.
2. Environment-specific settings that must NOT copy over: payment gateway sandbox keys
on staging versus live keys on production, staging's noindex/robots setting, any
"coming soon" or maintenance-mode flag, and SMTP settings that might be pointing
staging's test emails somewhere different from production's real customer emails.
3. File and plugin parity: how to confirm plugin versions match between staging and
production before cutover (a plugin updated on staging but not on production is a
common source of a broken deploy), and how to diff the wp-content/uploads folder so
production-only media uploaded during the staging build isn't lost.
4. Cron and scheduled task duplication: since staging is often a clone of production's
database including its wp_options cron schedule, explain how to prevent both
environments from firing the same scheduled email or report during the transition
window.
5. Post-deploy verification order: the specific sequence to check (cache purge, test
transaction, test form submission, spot-check redirects) before announcing the
deploy is done.
Give me this as a checklist I can literally follow top to bottom during the deploy
window, not general advice.
The riskiest part of a staging-to-production deploy is rarely the code, it’s the data
that changed on both sides while you were building. This prompt forces the plan to treat
that as a merge conflict rather than a straight overwrite.
Pro tip: run through this checklist once as a dry run against a throwaway copy of
production before the real deploy window, so the timing estimate you give the client is
based on something you actually measured.