Dedicated Drupal training: how we plan workshops on the client system (1–5 days)

12.08.2026

Dedicated Drupal training is a workshop built around a specific site, the participants' daily tasks, and the project's workflows - not a generic course from scratch. Drupal can run in an organization for many years, but team knowledge does not always grow with the system. People who remember the launch leave, new staff join the project, and working habits slowly drift apart. In that situation, training should cover the real site and everyday tasks - not a textbook installation. In this article, we explain how we prepare and run these workshops at Droptica.

In this article:

When does dedicated Drupal training make sense?
How do we gather needs and assess participant levels?
How do we set scope and choose the environment?
What does Drupal training look like in practice?
How long does dedicated Drupal training last?
What did a public-sector workshop look like?
What do participants get after training?
What won't training replace?
What questions come up most often before dedicated Drupal training?

When does dedicated Drupal training make sense?

Droptica typically receives two to six inquiries per year about training prepared for a specific team. Most come from large public-sector organizations and companies already using Drupal - typical requests for Drupal training for a company with a long-running system. They have people responsible for operating or developing the site, but need to organize knowledge and align how the team works.

The most common situations look similar:

the system was launched several years ago,
important knowledge stays with people who leave or change roles,
new staff join the project without Drupal experience,
editors, administrators, or developers follow different rules,
the team has a specific problem with configuration, updates, content publishing, security, or releasing new versions.

This is rarely just a panel usability issue. More often, the team lacks a shared, repeatable way of working with a long-running system. An open course can introduce Drupal well, but it will not show participants why their site has specific modules, roles, exceptions, and dependencies.

How do we gather needs and assess participant levels?

We do not start the program from a fixed topic list. First, we talk to the people who will attend. We ask about their daily tasks, level of independence, and situations where work with Drupal stalls or requires help from someone more experienced.

We do not rely on self-assessment on a 1-to-5 scale alone. That number means little without context. An administrator who handles users and content well may never work with configuration synchronization. A developer who knows PHP may not understand the entity model, cache, or publishing workflow on a specific site.

Before building the program, we collect information such as:

Drupal version and history of major updates,
participants' roles and tasks in the project,
list of modules in use,
custom code details,
description of development, staging, and production environments,
examples of recurring problems in daily work,
expected level of independence after training.

If the topic involves administration, the starting point may also be the current roles and permissions model in Drupal. Editors, site administrators, and teams responsible for code and deployments need different exercises. That is why we often plan separate blocks in one cycle - for example Drupal administrator training and Drupal developer training.

How do we set scope and choose the environment?

We set scope together with participants. It may cover administration, content publishing, site building, configuration, security, theming, development, Webform, or the process of releasing new versions. The program keeps only the areas participants will use in their project.

The second important decision is the exercise environment. We can work on a clean Drupal installation or a safe copy of the client's system, if access rules and confidentiality allow it. When possible, we prefer the second option.

A clean Drupal install works well for explaining basics because it has no historical exceptions. A client system copy gives participants what they need most: contact with their configuration, modules, and processes. They can practice tasks waiting for them back at work without exercising on production.

Before training, we confirm:

topics and block order,
environment used for exercises,
required access and tools,
group composition and participant roles,
problems worth reproducing during the workshop.

What does Drupal training look like in practice?

We prefer in-person Drupal workshops because they make it easier to work hands-on and respond to questions from the whole group. Participants complete tasks on their own computers, and the trainer can immediately see where someone gets stuck. Slides are supporting material, not the main content of the day.

A typical training block consists of a short introduction, a demo in the system, and independent practice. Then we review the result, errors, and variants seen in the client's project. If a participant's question reveals an important configuration or process issue, we stop there instead of sticking rigidly to the presentation.

This approach has two advantages. First, the trainer sees the group's actual level, not declarations collected before training. Second, participants immediately connect new knowledge to the system they work with every day.

For maintenance-focused training, it helps to pair the workshop with concrete procedures - for example checking available updates. We describe that process in our guide to preparing a Drupal version upgrade.

How long does dedicated Drupal training last?

The minimum is one day. That format makes sense for a narrow topic, a clearly defined group, and a similar participant level. Examples include a workshop on a single module, publishing process, or selected configuration management element.

The longest training sessions we have run lasted four or five days. That much time is needed when a team wants to walk through an entire release process or combine several areas - for example configuration, release management, and work with a business module. A longer cycle also allows returning to tasks, gradually increasing difficulty, and checking whether participants can complete the process on their own.

Length is not decided by the number of topics alone. These factors matter too:

number and level of participants,
system complexity,
work on a clean install or project copy,
number of exercises,
need to walk through a process from start to finish.

What did a public-sector workshop look like?

During one training session for a public-sector organization, we walked the team through the entire process of releasing a new software version. The topic covered configuration management, separating settings for development, staging, and production environments, and configuring the Webform module.

This was not an exercise prepared only for the course. Participants worked on a process that later came up during site maintenance. That let them see not only the sequence of clicks and commands, but also dependencies between configuration, testing, and deployment.

These examples are the most valuable because errors surface in safe conditions. The team can analyze the cause, repeat the task, and document the agreed approach before performing a similar operation on a real release.

What do participants get after training?

After completion, participants receive PDF materials with slides and theory, plus a training completion certificate. The materials help recall concepts and the order of steps, but they are not the most important outcome.

Most of what remains is in how the team works. After well-run training, participants should:

handle problems in their project more confidently,
complete practiced administrative or technical tasks on their own,
understand the impact of configuration changes,
know when they can act independently and when they need consultation,
use shared language and agreed practices.

The effect shows up the next day when the team returns to their site. The goal is not abstract CMS knowledge, but greater independence in specific tasks.

What won't training replace?

Training will not pay down technical debt or turn a junior into a senior in two days. It also will not replace ongoing maintenance, an audit, or development. Its purpose is to teach the team to work better with the current system and show which actions they can handle on their own.

A workshop on a project copy often reveals topics beyond the program: overdue updates, inconsistent configuration, security risks, or missing change-release procedures. Worth documenting and assessing those separately. Do not try to fix the entire system in the time reserved for learning.

Based on our experience so far, roughly half of clients decide to continue working with Droptica after training - for example an audit, configuration cleanup, upgrade, or ongoing support. That follows from topics noticed during exercises, not from adding a sales presentation to the program. If the team needs ongoing help, a separate step may be Drupal support and maintenance.

What questions come up most often before dedicated Drupal training?

The answers below summarize decisions that most often appear before preparing the program.

Does training have to be in person?

We prefer in-person work, especially for workshops based on the client's system. It makes shared exercises and quick troubleshooting easier. We agree on the format together with the team after gathering needs and checking organizational constraints.

Do participants need to know Drupal?

Not everyone needs the same level, but large gaps make group work harder. That is why we ask about roles and tasks before training. If one group mixes beginner editors and experienced developers, it is usually better to split the program into separate blocks.

Can we practice on the client's system?

Yes, if the client can provide a safe copy and the project information needed. We do not run exercises on the production environment. When project access is not possible, we recreate the required elements on a prepared Drupal installation.

Is one day enough?

Yes, if the topic is narrow and ends with a specific skill. For an entire release process, several participant roles, or a mix of administration and development, plan for several days.

Want dedicated Drupal training for your team?

This article draws on our experience running training for companies and public institutions already using Drupal. During one public-sector workshop, we walked the team through the entire process of releasing a new software version - from configuration management, through separating settings for development, staging, and production environments, to Webform configuration. Participants worked on a process used later in daily site maintenance, not on an exercise prepared only for the course.

Start by gathering three pieces of information: who will attend, which tasks the team struggles with today, and what they should be able to do after training. Contact us to discuss available topics and use that as a starting point for planning the program. We will first collect technical context and participant roles, then propose Drupal training for your team matched to scope, format, and number of days.