Webvelopment
Connected solutions

Modernise your website without losing what works

Website modernisation should preserve valuable content, URLs and working customer journeys while improving a defined weakness. Assess what can be retained before treating a new visual design as a reason to replace the entire site.

Let’s talk

A redesign is a migration decision

Two colleagues reviewing information together on a laptop.
Illustrative photography · Vitaly Gariev / Unsplash

Your website may look dated and still do useful work. Customers may know where to find a particular service, staff may rely on an enquiry form, and older pages may answer questions that never made it into the latest brochure. Those are worth understanding before a redesign removes them.

We start with the reason for change. Is the content hard to update, the navigation confusing, or a key task difficult on a phone? Each points to different work. Some sites need a clearer structure and better page design; others need a different technical foundation too. Understanding the problem helps you decide how much to replace.

Preserve before you replace

Bring the current website URL, any known problem pages and a list of the systems it connects to. We can use those to examine content, assets, forms and publishing responsibilities. Where analytics or search data is available and authorised, it can help identify pages people use. Staff knowledge matters too: a rarely visited page may still answer a specific customer question.

For each page, decide whether to keep it, rewrite it, combine it with another page or retire it. For example, three overlapping service pages might become one clearer explanation, while a useful technical guide stays separate. That choice also tells us which old addresses need a relevant new destination.

The implementation can include a revised site structure, original responsive design, content editing, accessible component patterns and a more appropriate technical stack. The audit helps separate work the site needs from changes that would simply make it look different.

Keep launch risks visible

Before launch, we need to check how the new site will take over from the old one. A practical migration plan covers:

  • Redirects from old URLs to relevant new destinations.
  • Form delivery and the team responsible for receiving enquiries.
  • Metadata, canonical URLs, sitemaps and language relationships.
  • Content approval, account access and asset ownership.
  • A tested build, release sequence and rollback route.

Changing DNS, replacing production infrastructure or removing an existing system requires authorisation. We need to know who controls those accounts and what else depends on them before scheduling the release.

Make the new site easier to own

Think about the next ordinary update: a changed service description, a new staff profile or an outdated download. Who should make that change, and how often will they need to do it? A site that requires a developer for every sentence may not suit your team. A complex publishing platform may also be unnecessary for a small set of pages that rarely changes.

We connect website design, UX and development to those editing needs. It is useful to try a representative update while reviewing the proposed approach, rather than judge it only from finished page designs. Ongoing maintenance can be scoped separately, including which updates your team will handle and which need our help.

Plan a careful website modernisation. Share the current URL, the main reasons for change and any systems or pages that must continue working throughout the transition.

Rehearse a migration decision before release

For a proposed rebuild, choose an existing service URL with useful content and a working enquiry route. Follow it through the preview site: does the old address reach the intended new page, does that page still answer the customer’s question, and can the customer send the information your team needs?

Then try a page being retired. If an old page explains a service now covered elsewhere, check that its onward route leads to that explanation rather than the homepage. This illustrative exercise helps expose gaps before release; it does not guarantee preserved search performance. The people managing content, hosting and enquiries should each check the parts they depend on.

List what must survive before approving replacement

Start a simple list of existing URLs, useful content, enquiry paths and integrations. Beside each, note what should happen to it and who can confirm that it still works. Include details that are easy to overlook, such as a download linked from a service page or a form field staff use to route enquiries. Review representative tasks in the preview environment before approving replacement.

Explore the delivery disciplines · Discuss this business change.

Modernisation programme questions

A few useful answers before you decide.

How do we decide what to preserve?
Start with the content, URLs, assets and workflows customers or staff still use. Available search or analytics information can help when authorised, alongside the team’s explanation of why a page matters. If there is no data, say so and identify what needs checking. Age alone is a poor reason to keep or remove a page.
Is changing the platform necessary for a redesign?
Not automatically. We look at what makes the current site difficult to use, edit or maintain. If the platform supports the required work, a targeted change may be enough. If it cannot support the agreed editing or integration needs, a different foundation may be worth considering. Compare the migration effort and future maintenance needs before choosing.
What should happen to obsolete pages?
Decide whether the material needs updating, combining with another page or removing. Identify a relevant destination where appropriate, and update internal links as well as redirects. Listing an old and new URL in a spreadsheet does not make the redirect work: it must be configured and checked in the hosting environment. Keep that list for launch checks and later editing.
Can the existing site stay live during the build?
A separate development or preview environment can support that, depending on the available setup and access. We also need a plan for changes made during the build. If your team updates a service page on the live site, for example, someone must carry that update into the replacement. Access to investigate the site does not authorise changes to production.
How should forms and integrations be handled?
List what each form or integration does, where its information goes and what it depends on. Then test the replacement route with safe information. Keep fields the receiving team needs, and keep secrets out of browser code. For an enquiry form, check that the intended recipient receives the submission with the expected details; a success message on the page is only part of the check.
What does a rollback plan need to establish?
It should explain which previous version can be restored, who is authorised to restore it and what would trigger that decision. Include redirects, forms and connected services where relevant, since restoring page files may leave other changes in place. Write down the steps and test what can safely be tested before release.

Plan the scope and estimate

Website Redesign & Migration Estimator · Website & Email Migration Estimator. These tools separate known labour from work and supplier costs that need a custom quote.

Keep exploring

Keep the right things connected.

Websites

Website Design

Create a responsive business website design around a clear offer, useful content, consistent page layouts and a practical customer and publishing journey.

Websites

Website Maintenance

Give website maintenance a defined scope covering routine updates, issue triage, account ownership, recovery responsibilities and separately agreed improvements.

Let’s move things forward

Start a conversation

Tell us what you are working towards. We’ll help you find a practical next step.

Let’s talk