Taking Over a Craft CMS Site Built by Another Developer: What We Look for First

Posted by: Karl Bowers | April 01 2026

A meaningful part of the work we do at Expression 37 involves inheriting Craft CMS sites that were built by developers or agencies who are no longer involved. The circumstances vary: the agency has folded, the relationship has ended, the original developer has moved on. But the practical challenge is always similar.

You’re starting with a site you didn’t build, with code you didn’t write, and decisions that were never documented. Here’s what we look at first and why.

Access and licensing

Before anything else: do we have the access we need? That means the Craft control panel, the hosting account, the domain registrar, the Craft license, and ideally the version control repository.

The Craft license is specific to the CMS and worth checking early. If the license is registered to the previous agency’s account, it needs to be transferred. The same applies to any paid plugins purchased through the Plugin Store. Missing or incorrectly registered licenses can surface as unexpected errors or put the site into trial mode.

Software versions

Once access is secured, the first technical check is versions: what version of Craft is running, what PHP version the server is on, and whether the two are compatible with each other and with the installed plugins.

This tells us immediately whether the site is at risk of breaking due to a server environment change, and whether there are any urgent security concerns. A site running Craft 3 on a server that’s about to move to PHP 8.2 is an urgent situation that needs a plan before the hosting provider acts.

The plugin inventory

Craft sites vary significantly in how they use plugins. Some are built almost entirely on native Craft functionality. Others depend heavily on plugins for core features, image transforms, form handling, SEO, and commerce. An audit of installed plugins, their versions, and their current maintenance status tells us a lot about the ongoing support requirements and any immediate vulnerabilities.

Plugins that are no longer maintained, or that are incompatible with current versions of Craft or PHP, go on the risk register immediately. A plugin that’s end-of-life but handling critical functionality needs a replacement plan.

The codebase and deployment setup

How is the site deployed? Is there version control? Is there a clean Composer setup, or has someone been manually copying files? Is there a staging environment, and does it actually reflect the production site?

A Craft site maintained properly should have a clean Composer setup, a Git repository, and a deployment process. When these are missing, it significantly increases the risk of something going wrong during routine maintenance or updates.

The content structure

Craft’s content modelling is one of its strengths, but how the site is structured in terms of sections, entry types, and field layouts can vary enormously. Understanding the content structure matters for ongoing maintenance: is it logical, is it what editors actually use, and is there anything that looks like it was added for a purpose that’s no longer relevant?

A content structure that’s been built and then left, with entry types and fields that no one uses any more, is not a problem in itself, but it’s a signal about the level of care the site has received.

What we do with all of this

The output of this initial review is a clear picture of what the site is, what state it’s in, and what work needs to happen before ongoing support can be put in place. Some sites are well-maintained and just need continuity. Others need remedial work first. Knowing which situation you’re in is the starting point for everything else.

Posted by: Karl Bowers
Posted in: Craft CMS
Post Date: April 01 2026 View all latest posts