When you inherit a new Craft CMS project, there are several tasks you should consider to familiarize yourself with the project, its dependencies, and requirements.
So, you just inherited a Craft CMS project…now what?
When you inherit a new Craft CMS project, there are several tasks you should consider to familiarize yourself with the project, its dependencies, and requirements. Not everything in this checklist will apply to you, but it should be a helpful guide to making the project transition successful!
The checklist is broken up into two sections:
We assume you already have access to the Craft CMS control panel in the production environment.
This first step is all about information gathering, so you know how the project was setup, its current state, and any immediate work that might need to be done. This is where you’ll find out if you have an emergency or a project needing quality, ongoing care.
Log into the production sit Craft control panel, if there is one, and look at the following from the System Report (Utilities > System Report):
From this information, you’ll be able to assess the state of the project quickly.
Ask your project contact if there is a Git repository associated with the project, so you can clone the repository and run the project locally (using DDEV, the officially supported way to run Craft locally).
Suppose there is no Git repository (which is common, unfortunately). In that case, you must download all of the code (minus the vendor
directory) and create a Git repository.
If you get access to the code, look for a README.md
file for additional project information. A good README will include all project dependencies, software stack, local development information, and deployment details.
This may be more difficult to discern from the server or code, unless deployment configuration files are included in the project. You may need to rely on your project contact’s information.
This might be a good time to move to a modern development and deployment workflow for Craft CMS.
You’ll want to determine where the site is hosted to answer the following:
These checks will help determine if you will keep the same hosting/server/infrastructure or if it’s time to change to something more modern and reliable.
A critical part of maintaining a healthy Craft CMS project is ensuring the Craft and plugin licenses are current. All plugins and Craft licenses are managed through the Craft Console, a web interface for managing first- and third-party Craft software licenses.
Find out who owns the licenses and manages them. Is it the prior agency or developer? Is it the client? If you cannot find out, open a Craft CMS support ticket and inquire about the license owner for each plugin and for Craft CMS. You can access the plugin licenses from Settings > Plugins if allow admin changes is not disabled.
At this stage, you don’t need to do a deep dive into the templates, but you should answer the following questions:
In this step, you want to confirm that users with control panel access still need that access. If not, revoke their access (but don’t delete the account, in case you need to revert access later, and to preserve any content authored).
Document everything you found during the previous steps, so you can use your findings to build a plan for any work required on the project.
Now that you have done an audit of the project, you may know whether the project will be a simple transition to maintenance and updates or an inferno of multiple technical fires.
Now is the time to plan your next steps. What are your goals, as a developer, for this project? What are the goals of your client or customer?
The details of your plan for the project will depend on what you find.
I asked the CraftQuest community how they handle inheriting a Craft CMS site. Here are some of the responses I received:
When you inherit a new Craft CMS project, there are several tasks you should consider to familiarize yourself with the project, its dependencies, and requirements.
Not every project switches to a new developer because of a toxic fallout. But even if that was the case, I’ve found that most devs are willing to give the person taking over for them the benefit of the doubt.
So usually my first steps are to get familiar with the code base and the deployment setup if there is any, all the gotchas that arise. Then I want to be able to handle Business As Usual requests as quickly as possible. Then, depending on the project quality, I often need to do refactoring. Not just to make it a bit more “my own” so that I know where to find things and don’t spend minutes trying to find a single template, but also to make it more future proof.
Big picture, we have to work to get into the minds of the previous developers — their build approach and code. The better we understand the site build, the better we can manage expectations, workload, and make informed recommendations. We appreciate that while we are inheriting someone else’s work, we need to be prepared to “own it” with our client’s best interests in mind. This means we can’t always point fingers at the work of past developers when things are challenging and must balance delivering fixes and enhancements in a way that is consistent with our business values and process.