Lessons from Supporting 300+ Drupal Sites Across Regions

Attico’s backend developer and team lead, Ryhor Kolzun, shares his experience about the main lessons learned from managing dozens of sites and explains what tools and processes make a Drupal website support more seamless and productive.

Lesson 1. Improve and organize all processes

“As they say, there’s a grain of truth in every joke, so the biggest lesson is, don’t deploy on a Friday. In general, when you support Drupal websites at scale, you really have to refine and organize every single process,” Ryhor says.

Let’s take deployment as an example. It’s simple math — if releasing updates for one website takes 20 minutes, doing it one by one for 50 sites would take almost 17 hours. Not fun to spend so much time on the same tasks, right? You need to find a way to make the processes run in parallel.

Or testing — in a Drupal multisite environment, automation is a must. We did it step by step, once we realized that a couple of testers just couldn’t figure out 50 sites manually. We checked which parts of the functionality required the most time and what was the most important, and then we began automating the top priorities. It worked really well: more bugs were caught before they went to production, which saved our team a lot of testing time.

Lesson 2. Always have a backup and recovery plan 

The main thing is just having the process in place. We do daily backups of websites, but how often you need to do them really depends on the site: whether it has user accounts, how frequently content is changed, and other factors.

Also, you need a working tool to restore a backup in case something goes wrong. And remember, don’t just overwrite the same file — it’s better to keep a “history” of backups.

“From experience, I can say that many incidents occur due to an old bug or a wrong content change. Backups from 3–6 months back helped us get to the bottom of it much faster,” Ryhor Kolzun adds.

Lesson 3. Test everything before release

Do every kind of testing you can — pre-release testing, unit tests, automatic checks, manual ones... The main thing is just making sure nothing breaks.

For example, on our project, we use automated visual comparison for key pages with a Cypress test. We create a separate test version of the site that’s an exact copy of the production site. Then, we take screenshots of the main pages, such as those from the main menu or important content types and taxonomies. After that, we deploy the new release to the test site, take the screenshots again, and compare them to see the different results. A developer or tester checks if it’s a planned change or a bug.

“This approach helps us make sure that nothing looks off on the site, so if anything breaks or changes by mistake, we catch it before it goes live.”

Lesson 4. Keep Drupal core and modules up to date

The golden rule is to keep Drupal core and modules updated. At the very least, it’s important for security.

When it comes to updating modules and using them, try to find a middle ground. If you stay on old but stable versions for a long time, sooner or later, you’ll need to add a new module or upgrade Drupal to a major new version. Then the old modules and core might not work well together. That means you will have to update the whole project at once, which takes plenty of time. For the client, it can cost a pretty penny, because everything was working before, and no one expected it would take so much time.

So it’s better to plan time for regular checks and updates, because the process will be less stressful for both the client and the team. But updating to a new version as soon as it comes out isn’t the best idea, especially if it is an alpha or beta version. Let the community test it, then check how many issues are open or closed, and see how widely it’s being used.

Lesson 5. Monitor performance and spot issues early 

There are many website monitoring services. They track response times, check for fatal errors, and unusual load. It’s important to use at least one of them and monitor alerts from the service.

For example, we at Attico use New Relic. These services also help identify bottlenecks in a project that may not be apparent during local development or testing, but become apparent when the website is under a real-world load.

Lesson 6. Follow security best practices

It’s important to use services or tools for security scanning and conduct regular audits. And of course, follow all the “golden” standards in development:

• ‍Don’t keep your API keys in Git.
• Anonymize real user data when you work locally or on dev/test sites.
• Assign CMS users clear roles, such as Editor, Manager, or Admin, and make sure only the authorized personnel can access sensitive information.
• Watch out for XSS and always double-check any data that comes from the frontend.
• Set up access checks for routes. 

Lesson 7. Use effective support strategies 

“The first thing I’d mention is having a well-organized ticket system. It is one of the key things that makes a Drupal website support smooth and efficient,” Ryhor points out.

The client doesn’t tell us that something is broken. They create a ticket and include some basic info, such as the URL, a brief description, and the priority. This helps us save time by not having to ask for details and understand how quickly we need to handle the ticket.

Next, code review is a key part of the development process. We monitor our tasks to make sure they follow best practices and meet the business requirements. We also make sure the code can be extended easily.

Then comes testing. I could discuss this at length, but utilizing different kinds of testing has saved hundreds of hours of support. You can start with manual checks of the main functionality, and then expand or cover it with automated tests. For supporting a large project, it’s really important to work on automating this process.

Many of the websites we support are Drupal multilingual projects, so we also test content consistency across different languages.

The next point is maintaining documentation. Developers can quickly get started on tasks and understand the project, even if they haven’t worked on it before, thanks to documenting requirements and technical functionality using pre-made templates. They can also store a lot of information about all the websites in one place, which helps save time on testing and communication. This approach works great for Drupal multisite projects, where each site might share the same core but have different configurations or modules.

Another helpful process is creating guidelines for editors, which helps the client find their way around the website faster and easier, and it also takes some of the load off us from answering the same questions all the time.

Lesson 8. Keep client communication clear and structured

Communication with the client has several levels and depends on the type of request, the complexity of the issue, and its priority.

Scenario one — we act as the first and only support level.

“As I mentioned earlier, we get alerts from monitoring systems such as New Relic or Glassbox, and we can react even before the client contacts us. We get the alert, create an internal ticket, and start investigating.”

Scenario two — the client notices the issue themselves.

“In this case, we utilize a reporting system known as the Client Help Center. It’s a dashboard where the client’s representative can quickly report and describe the issue, select its type, and set the priority.”

The report goes to the first support line. In case of a tech issue, the first line passes it to the development team’s Jira board, adding the priority and a brief description of the problem. Then, on the Dev Jira board, the ticket is reviewed by the manager, assigned to the team lead, and given to a developer depending on the complexity, urgency, and importance.