Inherited sites

Taking on a website somebody else built.

You do not need a rebuild to change who looks after your site. Most inherited sites can be supported as they stand, once somebody has established what is actually in them.

Review first Documented handover No rebuild required
The situation

Changing developer is not the same as starting again.

Agencies are often quick to recommend a rebuild when they inherit a site, and sometimes that is right. But it is also the answer that suits the agency, and plenty of sites are perfectly sound — they have simply been neglected, or the person who understood them left.

What an inherited site usually lacks is not quality but knowledge. Nobody knows why a particular plugin is there, what that scheduled task does, or which of the three staging copies is current. That is a documentation problem, and it is far cheaper to fix than a codebase problem.

So we start by establishing what is there and writing it down. Only then is it possible to say honestly whether the thing is worth keeping — and to show you the reasoning rather than asking you to take it on trust.

Able Web Services Ltd.UK web development
200+PROJECTS DELIVERED
140+CLIENTS SUPPORTED
15+YEARS ESTABLISHED
UKBASED & HOSTED

What we do

  • Bespoke websites and custom CMS development
  • Ecommerce, custom checkout and subscriptions
  • Web applications, portals and internal tools
  • API, CRM and business systems integration
  • Retained support, maintenance and managed hosting
  • White-label development for agencies

Working UK-wide — directly with businesses, and white label behind design and marketing agencies.

Discuss a project
The review

What we establish before quoting.

What it is built on

Platform, versions, and how far behind they are. Being behind is normal; being so far behind that updating is itself a project is the thing worth knowing.

What is custom

Which parts are off-the-shelf and which were written for you. The custom parts are where the risk and the value both sit.

What it connects to

Payment providers, CRMs, feeds and third-party services — including any running on credentials belonging to somebody who has left.

Security position

Known vulnerabilities in the versions running, and anything exposed that should not be. This is usually the most urgent finding.

Backups and recovery

Whether backups exist, whether they run, and whether a restore has ever been tried. All three are different questions.

How it is deployed

Whether changes can be tested before they go live, or whether every edit has been made directly on the production site.

Straight answers

How this works in practice.

We quote after looking, not before

A fixed price for supporting code nobody has read is a guess. The review is what makes a real quote possible.

The findings are yours

Whether or not you go on to work with us. You should not have to buy a relationship to find out what you already own.

Urgent things get flagged immediately

If the review turns up something actively dangerous — an exposed admin, an unpatched vulnerability — you hear about it that day, not in a report.

Related services

The wider picture.

Related work

Projects of a similar shape.

A lot of our work is delivered white label or under agreement, so these describe the problem and the approach rather than naming the client.

Questions

What people ask about handing a site over.

Do we have to rebuild?
Usually not. Most inherited sites can be supported as they stand once someone has established what is in them. Rebuilding becomes the right answer when the foundation actively prevents what you need to do next, or when the security position cannot be brought up to date — and we would show you why rather than assert it.
What do you need from us to start?
Ideally hosting and CMS access, and the repository if one exists. If you do not have all of that, say so — it is common, and establishing what you control is part of the work rather than a prerequisite for it.
Will you talk to our previous developer?
If they are contactable and you are happy for us to, yes — a short handover conversation can save days. Where that is not possible we work from the code, which is slower but perfectly workable.
What does ongoing support look like afterwards?
A retainer with a named developer and an agreed number of hours a month, with unused hours. Coverage is Monday to Friday, 8am to 6pm, and our response target for a site that is offline or unusable is two business hours.
Next step

Send us the address and current setup.

We will review what is there and tell you what you have, what state it is in and what supporting it would involve — including when the right answer is to leave it alone.