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

Posted by: Karl Bowers | March 30 2026

A significant part of the work we do at Expression 37 involves inheriting ExpressionEngine 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, documenting decisions that were never documented. Here’s what we look at first and why.

Access

Before anything else: do we have the access we need? That means the EE control panel, the hosting account, the domain registrar, and ideally the version control repository if there is one.

Missing access is extremely common in these situations. Hosting may be in the previous agency’s name. Domain registration may be with a registrar the business owner has never logged into. Getting these under the right ownership is the first priority, and it can take time depending on how cooperative the outgoing party is.

Software versions

Once we have access, the first technical check is versions: what version of EE is running, what PHP version is the server on, and are the two compatible with each other and with the installed addons.

This tells us immediately whether the site is at risk of breaking due to a server environment update, and whether there are any urgent security concerns.

The addon inventory

ExpressionEngine sites vary enormously in how they use addons. Some are built almost entirely on native EE functionality. Others depend heavily on third-party addons for core features. An audit of installed addons, their versions, and their current maintenance status tells us a lot about the ongoing support requirements and any immediate vulnerabilities.

Addons that are no longer maintained, or that are incompatible with current versions of EE or PHP, go on the risk register immediately.

Custom code

Most non-trivial EE sites have custom code somewhere: a custom addon, a modified template, a piece of middleware connecting EE to a third-party service. Understanding what that code does and how it interacts with the rest of the site is critical before making any changes.

This is where undocumented decisions cause the most problems. Code written for a specific reason, with specific constraints in mind, will sometimes look wrong or redundant when viewed in isolation. We make no assumptions until we understand what something is doing.

The first conversation

After the initial audit, the most useful thing is a conversation with whoever knows the site best on the business side. Not a technical conversation, but a practical one: what does this site do for your business, what features do you actually use, what’s changed recently, what’s been causing problems.

That context, combined with the technical audit, gives us everything we need to put together a clear plan for what needs to happen and in what order.

Taking over a site properly takes time to do well. But done properly, it results in a site that’s properly understood, properly documented, and properly maintained going forward.

Posted by: Karl Bowers
Posted in:
Post Date: March 30 2026 View all latest posts