David Burns is the Director of Lullabot’s Support and Maintenance department (LSM). In this interview, he discusses when an organization should start considering support help, how to get the most out of your time and money with a support and maintenance relationship, what problems LSM has been set up to help solve, and words of wisdom for those still on Drupal 7.
What are some clues that an organization should get help with maintenance?
The two most critical signs are falling behind on security updates and a growing backlog of bugs. Both lead to a fragile system. It’s understandable to focus on new features and improvements, but eventually, you will be building those new features on a house of cards.
A support and maintenance partner can take that burden from you. They can keep your foundation healthy while your own team focuses on building new stuff on top of it.
If you have a lack of institutional knowledge of the Drupal ecosystem, a support partner can provide much-needed mentorship for your development team. Experienced developers and managers can leave for a variety of reasons. Sometimes the entire team who built your Drupal site rolls off to move on to something else.
If you feel the pain of this absence, a support partner can help fill the gap. They can help you pick the right module for the job and provide guidance on implementing Drupal’s APIs. Since Drupal is a flexible framework, you can tie yourself into knots implementing a feature a certain way. A support partner can help you write more maintainable code.
Another clue is when you have repeat regressions during deployment. This slows down velocity, forcing you to roll things back and spend more time fixing things you swore had been fixed 2 weeks ago. A support partner can help you improve your local environments, streamline your deployment process, and start setting up good automated testing habits.
How far behind in security updates would you say is critical? Is there a different weight you put on Core updates versus contrib module updates?
It depends on the severity of the security issue. Usually, Drupal.org will make a public announcement for high or critical security issues for core and common contrib modules. These should be addressed within 1 or 2 days.
Lower severity security issues should be addressed ideally within a week, and you shouldn’t wait longer than 2 weeks. Exceptions can be made after reviewing how the security exploit is exposed and to see if the site has a module configured, permissions set, or trusted users in specific roles that would be able to make use of the security exploit. An example would be the multiple security updates over the last few months regarding the 8.x-5.x version of Webform.
What is an unhealthy ratio of bugs vs. features?
It depends on the complexity of your installation. Some organizations can handle more bugs than others, so it is a continuous conversation. If you know that you have 2:1 or 3:1 bugs to features ratio, then it would be good to work on those issues as close to that ratio as possible.
It’s also a balance. If you work on nothing but bugs for a couple of months, it’s harder to show progress. Many stakeholders need to be able to show off new features to justify budgets.
When you first start an engagement, what type of things are typically uncovered in an initial audit? What are the most common issues?
Outdated Core and contrib modules are very common. This is not a surprise. If someone is reaching out to us about support and maintenance help, that typically one of the first things they need help with.
Unused code is also prevalent in the form of modules that are no longer used or content types and fields that are no longer relevant. These are good opportunities for starting conversations around how clients are using their site and their main goals. These things are usually identified by performing an initial site audit.
Poor Lighthouse scores for Accessibility, SEO, and Performance are another great conversation starter. We can educate on the negative impact these results have on user experience and the SERPs (Search Engine Results Pages), bringing in other experts from Lullabot to help make recommendations.
Performing a coding standards audit can also be a good indicator of areas that need to be addressed. PHPStan and Drupal Rector inform us how much code may need to be fixed or how well custom modules and themes have been documented.
What can an organization do to get the most out of a support/maintenance partnership?
There are unavoidable onboarding tasks, and sometimes, just getting the process started can help increase the velocity of that first week.
- Have a groomed backlog of tickets. By “groomed,” we mean a selection of tickets that have been prioritized and clarified. If your needs are not in ticket form, then at least have a clear set of goals you like to achieve, and we can help distill them into actionable tasks.
- Be ready with code and database access. Make sure the people responsible are aware and ready to onboard the members of the support team.
- Be ready to share any available documentation. It doesn’t matter if it is disorganized or outdated. Any information can give insight into how teams are working together and can highlight potential places for improvement.
- Be ready with communication tool access. This can be a Slack channel or some other online tool. If you want recommendations or want the support team to set something up for you, be sure and communicate that long before the official start date.
Make sure you establish direct points of contact between your team and the new support team. Reduce the number of decision-makers to as few as possible (ideally 1 person), so there is a smaller chance of collision between competing requests. You want your support and maintenance team spending their hours fixing issues and not juggling multiple points of contact.
Along the same lines, to make the best use of limited hours, have all of your requirements in place before jumping on a call. This makes scoping out the work as streamlined as possible. Be able to speak about the areas of the site people are having troubles with and for which roles. You, as the site owner, understand your organization’s needs better than anyone. Outside perspectives can be helpful, but try to eliminate any guesswork the support team has to make.
What are the biggest differences between engaging Lullabot for a full project versus engaging Lullabot to support and maintain an existing project?
Smaller, concrete scopes of work. No single task should take more than 20hrs to complete, though some exceptions are made.
Timelines need to be a bit more flexible for adding enhancements. Since support clients are not working with full-time developers, they understand that they are not the only project our support team is working with. We prioritize tasks as a department based on urgency and need.
We do have quick response times for critical issues, and sometimes we’ll have multiple team members swarm an issue if it needs to be resolved as quickly as possible.
What are some examples of features you have implemented in under 20 hours?
Infrastructure and developer workflow. We see many projects where developers repeat things that can and should be automated to reduce human error. We want changes seen and shared well before they hit the main branch or development environment, so implementing build scripts and setting up Tugboat are common tasks that pay lots of dividends in the future. If an issue is identified, we don’t have to go through the time-consuming process of rolling code back out of a release to unblock work ready to be deployed. Once code is merged into the main branch, it’s likely going to get deployed.
Some other features that can be completed in under 20 hours:
- Custom blocks
- Carousels
- New entity types with custom fields and display modes
- Menu refactors
- Enabling and configuring newly introduced modules
- Installing spam blockers
- Custom webforms
- Implementing content and moderation workflows
- Custom views and/or enhanced administrative views
- SEO modules, like Metatags
After engaging with Lullabot Support & Maintenance, walk us through the first few weeks.
During the first couple of weeks, you will spend time working with a support team manager to determine how best to work together and optimize productivity. The goal is to get a good sense of the answers to the following questions:
- What are the preferred channels of communication?
- What is the optimal frequency and cadence for meetings?
- What level of experience does your team have with Drupal?
- What are the primary objectives that are trying to be achieved with the current support contract?
After ensuring all onboarding issues are resolved and documented, we start planning out the next few months of work, leaving room for potential unexpected emergencies. We start grooming a backlog of tickets in whatever ticketing system your team is currently using. If you don’t currently have a ticketing system, we can make recommendations and set up one that best fits the needs of a project and team.
Next, we will determine who your project lead will be. This will be a full-time Lullabot employee whose skills, personality, and communication style mesh well with your existing team. This project lead will become your primary point of contact for all your support requests.
What are some of the frustrations traditionally experienced with support and maintenance contracts that Lullabot has tried to address?
Inconsistent points of contact. We solve this by having a dedicated project lead for all our engagements. This gives you the same person, a real person, that you can reach out to in Slack, via email, or schedule a meeting with.
As a result, we don’t have a traditional help desk where a random developer will be delegated to pick up the next task from the queue. Our teams will always consist of real people: a project lead and at least one primary developer who both understand your site and your organization's needs. They plan to be involved with your project for an extended period of time. The people working on your site will be the people most familiar with your site or the support team member with the best skills to complete the request.
To capture requests and requirements, or to groom tickets, you can work with your project lead to schedule recurring meetings on a weekly or bi-weekly basis. This provides an environment that allows everyone to prepare and use the time more efficiently than relying on ad-hoc calls. However, if an urgent task like a critical bug fix is needed, a client can reach out to their project lead at any time.
We aim for transparent communication at all times. Slack channels and ticketing systems like Trello or Jira help facilitate this. By turning requirements into actionable tasks or tickets onto a Kanban or Sprint board, we visualize progress and improve communications between the client and developers. We have also found that this helps everyone on the team acquire similar terminologies or vernacular that everyone can use to improve communication.
We also like to go beyond the technical aspects of problem-solving. Our support team is here to help you achieve your organization's goals. We are not only fixing bugs or adding features. We are here to understand the needs of your business and the people that use your site. It’s possible that what you are asking for might be different from what we are being asked to fix or create. We can raise flags or ask questions when appropriate to better understand what is being requested.
To this end, depending on the number of monthly hours within a support engagement, we would like to meet all of the members of your team. While we want to reduce the number of decisions makers, we also want to make ourselves available as a resource of knowledge and mentorship for everyone involved. We want to help unblock people who are stuck because they may not understand how something works or are experiencing issues that are new to them.
As a team, LSM has experience solving many things that come up when building and maintaining websites. We can leverage that experience to help you solve issues. If that knowledge doesn’t exist within our support team, we have immediate access to the brightest minds within Lullabot and the rest of the Drupal community.
Any tips (or words of comfort) for those still on Drupal 7?
With D7ES (Drupal 7 Extended Support), Drupal 7 sites will be supported through Nov. 2025. This leaves plenty of time to have conversations and make decisions about what to do next. If you’re worried about the editorial changes because of upgrading to Drupal 8 or 9, know that they are not drastically different. Visually they are incremental improvements to what you see in Drupal 7 with much better editorial and developer experiences when set up correctly.
At Lullabot Support and Maintenance, many members of our team have been involved with Drupal 7 to 8 migrations and have worked on Drupal 8 to 9 upgrades. Planning a roadmap for your future migrations or upgrades can be part of the help we provide.