Staging & Rollback Planning
Use a staging copy and a defined rollback path so a migration does not become an irreversible production experiment.
Keep staging separate from public indexing
Use authentication, robots controls or non-public hosts as appropriate. A staging site should not compete with the live site in search or expose unfinished customer information.
Test the real server environment
Local files can work perfectly while production hosting handles redirects, default documents, MIME types or permissions differently. Stage on an environment close to production when possible.
Define rollback before launch
Know what DNS record, document root or deployment package restores the prior version. Store the last known-good package and database backup before switching traffic.
Freeze changes briefly
If editors continue publishing to the old CMS during migration, decide how final changes will be captured. A short content freeze can prevent the new site from launching without the latest updates.
Record the cutover
Keep timestamps, DNS changes, deployment version and who performed the change. Clear records make troubleshooting faster if an issue appears hours later.
Create acceptance criteria before launch
Define what “ready” means before the pressure of launch day. Typical acceptance criteria include zero broken internal links, forms delivering correctly, mobile navigation working, priority URLs mapped, key metadata preserved, no unintended noindex directives and acceptable performance on the production-like host. This prevents subjective last-minute debates about whether a visual preview is good enough.
Rollback should preserve evidence
If a launch fails, do not immediately overwrite the new deployment with random fixes. Capture the failure state, record affected URLs and preserve logs where possible. Then roll back using the planned method. The evidence makes the next attempt faster and reduces the chance of repeating the same problem.