PRACTICAL GUIDE · IT TO WEB

Website Redesign & Migration Checklist

A redesign is successful when customers can still find the right page and complete their task after the release. Use this checklist to protect working content, search signals and business connections while improving the experience.

Discuss Your Project →

1. Define the problem before the design

Record specific defects such as a broken enquiry form, unclear service description, inaccessible navigation or slow loading on a representative device. Capture current desktop and mobile screens. A new visual style is not evidence that an operational problem has been fixed. Compare a focused repair with a rebuild before committing to a larger change.

2. Inventory what must be preserved

List important pages, indexed URLs, campaign links, forms, languages, media and external integrations. Establish which content and images you are authorized to use. Record the current source and backups. Decide who owns each service account and how the team will restore the previous version if release checks fail.

3. Map old URLs to useful destinations

Preserve a working address when practical. When a page moves, choose the closest relevant replacement and use the appropriate permanent redirect. Avoid sending every retired page to the homepage. Check response codes, canonical tags, language alternates, sitemap entries and links with campaign parameters. Do not invent a new URL inventory merely to make the sitemap larger.

4. Test real tasks in staging

A visitor should understand the service, reach Contact without using an optional AI demo, and receive an accurate submission result. Test invalid inputs, duplicate submission handling and temporarily unavailable providers. Use a controlled plan for any delivery test so it does not create unnecessary notifications, customer contact or financial actions. Test keyboard navigation, zoom, reduced motion and mobile layouts as separate concerns.

5. Release and observe

Compare before and after performance under equivalent conditions. Keep field Core Web Vitals separate from a single laboratory run. Publish only the reviewed source, verify the resulting files and keep a rollback path. Check ordinary public URLs afterward, then monitor search and enquiry evidence over time. A launch-day test cannot establish long-term rankings, sales improvement or complete accessibility certification.

Discuss your requirements

Tell us what needs to work, who will use it and which systems are involved. Scope, delivery responsibilities and support are agreed for your project.