Occasionally a migration needs to be rolled back — a critical issue discovered post-launch, or an integration that broke unexpectedly. Most of an HTTPS migration is safely reversible, with one significant exception.
What rolls back cleanly
- The server-level redirect rule can simply be removed or disabled.
- CMS settings (like WordPress's Site URL) can be reverted to http:// values.
- A database search-and-replace can be run in reverse if it was done as part of the migration.
What doesn't roll back cleanly: HSTS
If you enabled HSTS before rolling back, every visitor whose browser already received that header will continue refusing plain HTTP connections to your domain until the max-age window naturally expires — there's no way to instruct an already-informed browser to forget the policy early. This is exactly why HSTS guidance recommends starting with a short max-age and only extending it once you're confident the migration is stable, rather than setting a long duration immediately.
If you must roll back with HSTS already active
The only real option is keeping HTTPS itself minimally functional (even if imperfectly) for affected visitors until the max-age window passes, since a full rollback to plain HTTP would break the site for anyone with the policy cached.
Why HSTS specifically is the one setting that can't be quickly undone
Once a visitor's browser has received an HSTS header, it will refuse plain HTTP connections to that domain for the remainder of the max-age window regardless of any subsequent server-side change — this is exactly why HSTS guidance recommends starting with a short max-age until migration stability is confirmed, rather than committing to a long window immediately.
What to do if you must roll back with HSTS already active
The only realistic option is keeping HTTPS minimally functional, even if imperfectly, for the remainder of the affected max-age window, since a full rollback to plain HTTP would simply break the site entirely for any visitor whose browser already has the HSTS policy cached.
What a partial rollback looks like versus a full one
Rolling back only the specific piece that's causing a problem, a particular redirect rule or a specific application setting, while leaving the rest of the HTTPS migration intact, is often more practical and less disruptive than a full rollback to the previous, entirely HTTP state.
What stakeholders should be informed before initiating any rollback
Informing anyone relying on the migration having completed, marketing team members who may have already updated materials, other engineers, before initiating a rollback avoids confusion and duplicated, conflicting effort if multiple people are unaware a rollback is in progress.
How to document what triggered a rollback for future reference
Recording specifically what issue triggered the rollback decision, and what the actual underlying cause turned out to be once diagnosed, provides valuable context for planning a more successful subsequent migration attempt rather than repeating the same issue.
Why a partial, targeted fix is usually preferable to a full rollback when possible
A full rollback undoes real progress and reintroduces the original insecure state entirely — isolating and fixing the specific broken piece, whenever possible, preserves the parts of the migration that were already working correctly rather than discarding all of it over one localized issue.
A closing thought on treating rollback planning as part of migration planning itself
Thinking through a rollback plan before starting a migration, not only after something goes wrong, means you're never making rollback decisions under time pressure — a small amount of upfront planning that pays off considerably if it's ever actually needed.
What a rollback runbook should specifically include if you want to prepare one
A rollback runbook should specify the exact steps to reverse, who has the access needed to execute them, expected time to complete, and any known limitations (like HSTS's irreversibility) — prepared in advance rather than improvised during an actual incident.
How to test your rollback plan without actually executing it on production
Walking through the rollback steps against a staging environment, or simply reviewing the documented steps with a colleague for completeness, validates the plan is actually workable without needing to disrupt production simply to test the rollback procedure itself.