A redesign is justified when it addresses a documented problem: a confusing offer, inaccessible tasks, a difficult editing workflow or a platform that no longer supports the work. Age alone does not prove the site needs replacement.
Identify What Should Improve
Review task completion, enquiries, content accuracy, accessibility, performance and maintenance effort. Ask users and editors where the site gets in their way. Separate a design issue from missing content, a broken integration or a business-process problem.
Keep what works. A clearer contact form or updated service page may solve the immediate issue without replacing the entire site.
Distinguish Redesign from Migration
A visual redesign changes presentation and interaction. A migration may also change the CMS, hosting, domain, URL structure or content model. Identify which changes are actually required and assess their dependencies separately.
For a WordPress site, compare improving the existing implementation with moving to another stack. Use the editing needs, integrations, maintainability and total cost; no framework automatically makes migration worthwhile.
Inventory the Existing Site
List current URLs, useful content, downloadable files, forms and integrations. Record important entry pages and links using available data. Identify outdated material, duplicates and content owners.
Map each existing address to an appropriate destination. Preserve useful URLs where practical. Where a page moves permanently, use a direct permanent redirect to relevant content rather than sending every old URL to the homepage.
Develop and Test the New Experience
Use representative content and test the full visitor and editor journeys. Verify navigation, form delivery, error handling, authentication, bookings or payments as applicable. Check mobile, keyboard access and text enlargement alongside automated diagnostics.
Review titles, descriptions, canonical URLs, language links, sitemap and indexation settings. A staging environment’s blocking rules must not accidentally remain on the public release.
Plan the Release and Recovery
Confirm backups, access, publication responsibility and a rollback approach. Test redirects and integrations on the released environment. Monitor errors, search coverage and relevant business outcomes after launch, accounting for seasonality and other changes.
A careful migration reduces avoidable risks, but cannot guarantee unchanged rankings or traffic. Search engines and user behaviour are outside the supplier’s complete control.
Agree the Budget and Acceptance
Separate content work, design, development, migration, testing and post-release support. Include work on legacy integrations and data where needed. Define what must be demonstrated before each approval rather than relying on a visual sign-off alone.
Working with Q-Dev
Q-Dev is QA10’s software house offering. Scope, price and schedule are agreed for each project. Four gates cover design, MVP, deployment, and training with the start of maintenance. Each gate has a review meeting and an agreed corrections document; after approval, two further rounds of changes to completed work are available at that gate. Changes may affect timing; price changes only outside the contract scope. The first six months of maintenance are included. Code rights transfer after full project payment.
Describe your website project.
Frequently Asked Questions
Does an old site always need replacing?
No. First identify the problem and compare a focused improvement with a larger redesign or migration.
Can a redesign guarantee no loss of rankings?
No. URL mapping, redirects, content preservation and monitoring reduce avoidable migration risks, but search results are not fully controllable.
What should be checked after launch?
Critical user tasks, integrations, redirects, indexation settings, content, accessibility and operational monitoring in the actual released environment.