Launch with a way back.

Inventory what must keep working

Record who controls the domain, hosting, content, forms and any connected services. Know which accounts are needed and who can recover them. Do not assume replacing website files also safely migrates every other business dependency.

List important existing URLs, contact paths and any checkout or account features. A new homepage is not a migration plan.

Prepare redirects deliberately

Google's site-move guidance describes mapping old URLs to their relevant replacements, updating links and monitoring the move. Do not send every missing page to the homepage and call the mapping complete.

Changes to hosting and changes to DNS are different operations. Preserve unrelated email records when adjusting website routing. Confirm the actual account settings rather than relying on a remembered screenshot.

Define the release evidence

Our checklist uses Pass, Fail, Not run and Not applicable. A pass points to a test result. Not applicable includes a reason. Not run remains visible and may block the release when it concerns an essential function.

Test the main journey, forms, narrow screens, keyboard access, production redirects and indexing configuration. Keep a human decision about whether the outstanding risks are acceptable.

Make recovery specific

Save the previous deploy identifier and know how to restore it. Identify what a rollback does not restore, such as new submissions, database changes or third-party actions. A recovery instruction should name the operator and the verification steps.

After the change, check the actual public pages and the next real enquiry. Publishing files is an event; keeping the business journey operational is the job.

A practical checklist

• Inventory live URLs, domain access and connected services.
• Map relevant redirects and verify production indexing settings.
• Record a recovery route and test the essential journey after launch.