A website does not need to be rebuilt simply because you changed developer.
That is the first thing I would establish during a takeover.
If the existing site is healthy, the job may simply be:
- confirm ownership;
- get access;
- understand deployment;
- check backups;
- document the stack;
- take over maintenance.
If the previous developer disappeared halfway through the work, the same “takeover” can become a rescue project.
For planning:
| Situation | Planning budget |
|---|---|
| Basic takeover / audit | $300–$1,000 |
| Healthy site + migration/setup | $500–$2,500 |
| Repair and stabilization | $1,500–$5,000 |
| Serious rescue / rebuild | $3,000–$15,000+ |
The right range depends on what the new developer is inheriting.
Recover control before redesigning anything
Start with the accounts that determine whether the business can continue operating:
- domain registrar;
- DNS;
- hosting/cloud account;
- CMS;
- repository/source code;
- database;
- analytics;
- Search Console;
- transactional email;
- payment providers;
- booking/CRM integrations.
If you do not have access, that is the first problem to solve.
My website ownership guide explains which accounts I would normally keep under the business’s control.
A takeover audit should answer one question
Can this website be safely continued?
I would inspect:
- technology stack;
- dependencies;
- deployment process;
- source-control history;
- security issues;
- backups;
- performance;
- forms;
- analytics;
- SEO;
- CMS editability;
- database;
- integrations;
- known defects.
You are not looking for reasons to criticise the previous developer.
You are looking for risk.
Why inherited websites are hard to quote
A new project contains unknowns.
An inherited project contains unknown decisions.
The new developer may need to discover:
- why a component was built a certain way;
- which code is actually deployed;
- whether production matches the repository;
- what credentials are current;
- what hidden dependency a feature relies on;
- whether changing one part affects another.
That discovery takes time.
A complex takeover quote given from three screenshots is mostly a guess.
When a simple takeover is enough
Keep the site when:
- it loads reliably;
- the CMS is maintainable;
- the code/source is available;
- important forms work;
- ownership is clean;
- SEO performance is useful;
- problems are isolated.
Changing developer should not be an excuse to replace working assets.
When repair makes sense
Repair is appropriate when the foundation is sound but important parts are broken.
Examples:
- contact-form delivery;
- mobile navigation;
- checkout;
- analytics;
- speed;
- deployment;
- content editing;
- plugin/dependency conflicts.
If you are budgeting repair, see my website repair cost guide.
When rebuilding becomes defensible
A rebuild becomes easier to justify when:
- source code is missing;
- the current platform blocks normal changes;
- the site is repeatedly compromised;
- small changes routinely break unrelated features;
- new functionality no longer fits the architecture;
- critical accounts cannot be controlled safely;
- technical debt makes every repair disproportionately expensive.
Use repair vs redesign vs rebuild before deciding.
Protect SEO during takeover
Changing developer should not automatically change URLs.
If a rebuild or migration does require URLs to move, Google recommends permanent server-side redirects such as 301 or 308 and direct mappings from old URLs to the most relevant new destinations. See Google’s redirect guidance.
Before launch, preserve where practical:
- valuable URLs;
- useful content;
- titles/descriptions;
- analytics;
- Search Console;
- sitemap behaviour;
- canonical URLs;
- internal links.
A takeover should not erase search value the business already paid to create.
What if the previous developer disappeared?
I have a dedicated guide for what to do when your web developer disappeared with an unfinished website.
The short version:
Do not immediately pay someone to “finish it.”
First determine what actually exists and what you control.
What should the new developer hand you?
After the takeover, I would expect some combination of:
- account inventory;
- architecture/stack summary;
- deployment instructions;
- backup status;
- known issues;
- security concerns;
- keep/repair/rebuild recommendation;
- ownership clarification.
If ongoing maintenance follows, define what counts as:
- maintenance;
- bug fix;
- content edit;
- new feature.
A good takeover reduces dependency
The successful outcome is not only “new developer can work on the site.”
It is:
The business now understands what it owns, where it lives and how another competent person could take over again later.
If your current developer has disappeared, stopped responding or simply is no longer the right fit, send me the website URL and tell me what access you currently have. I can help determine whether this is a clean takeover, repair job or rebuild.
