Free site health check. Results within 1 hour. Get yours

Craft CMS rescue: what a takeover from another developer actually includes

by Billy Patel
Craft CMS rescue: what a takeover from another developer actually includes
Back to blog

A Craft CMS rescue happens when a business or agency takes over a Craft site that someone else built, and the original developer is no longer available. Maybe they moved on, retired, went out of business or the relationship ended. Either way, the site is now an orphan, and the next developer has to start by working out what they have inherited.

A proper takeover has its own structure with specific deliverables. The stages below run in sequence.

Stage one: gain access to everything

Hosting credentials, domain registrar access, code repository, deployment pipeline, admin accounts for the Craft control panel, any external services like CDN, email, analytics, error tracking. Every credential that the previous developer used needs to be inventoried, transferred to the client's ownership and rotated for security.

This stage often surfaces the first surprises. Domains registered in personal email accounts. Hosting paid for on personal credit cards. Repositories on a personal GitHub account. Each of those needs to be moved before the takeover is complete.

Stage two: the technical audit

The audit covers six areas. Craft version and update status. Plugin inventory and licence ownership. Custom module code quality and complexity. Hosting configuration and resource use. Security configuration including admin accounts, two-factor authentication and known vulnerabilities. Performance against current standards.

The output is a written report that the client can read without technical knowledge. The report identifies what is solid, what is at risk, what is broken and what is so non-standard that any future developer will struggle with it. Each issue has a recommended action and an effort estimate.

Stage three: content model documentation

The content model is the part of the site that the marketing team interacts with every day. Sections, entry types, field layouts, Matrix configurations, asset volumes, user groups and permissions. Most rescue projects find that this is documented nowhere outside the running site.

Documentation might sound like overhead but it pays back the first time a content editor asks why a field disappeared from one entry type and not another, or why the same kind of content lives in three different sections. The documentation answers those questions without diving into the codebase each time.

Stage four: stabilise before improving

The temptation in a rescue is to fix the obvious problems first. Resist it. A site that has been running on auto-pilot for two years has a working balance, even if that balance is precarious. Touching the codebase before understanding it is how rescues turn into rebuilds.

Stabilisation work is the small set of safety improvements that protect the site while the audit and documentation happen. Backups verified. Admin accounts secured. Critical security patches applied. The deployment pipeline tested. Everything else waits for the audit to inform the priority order.

Stage five: present the plan

After the audit and stabilisation, the client gets a written plan covering the top priorities ranked by risk and impact. Some items will be urgent. Some will be next-quarter work. Some will be flagged but parked. The plan is a starting point for the relationship rather than a set of unilateral decisions.

From there the engagement either continues into ongoing work or hands off cleanly to another developer with all the context documented. Either way, the client now owns a clear picture of what they have, which is the part that was missing when the takeover began.

What a rescue does not include

A rescue is not a redesign. It is not a rebuild. It is not the first phase of a new project. Those things can come later if the audit recommends them, but the rescue itself is about establishing what is there, securing it and documenting it so any future work has a stable foundation.

Clients who push for new feature work during the rescue tend to regret it. The rescue is the cheapest part of the relationship. New work built on top of an unverified foundation is the expensive part.

For more on Craft CMS work, see Craft CMS developer UK or Craft CMS agency UK for agency-only enquiries.

Frequently asked questions

How long does a Craft CMS rescue audit take?

For most sites, three to seven working days. Smaller sites complete in two or three days. Sites with significant custom code or unclear histories can take longer.

What does a Craft CMS rescue cost?

A standard audit and stabilisation engagement runs between £1,500 and £5,000 with a UK senior freelancer. Sites with significant custom code or major issues run higher.

Can we keep our old developer involved during the takeover?

Helpful but not required. Most rescues happen because the old developer is unavailable. A handover call where possible saves time but the takeover is designed to work without it.

Inherited a Craft CMS site that needs rescuing?

I can take over the site cleanly. Audit, stabilisation and a written forward plan, usually within five working days.

Get in touch
Message Call Email