Week one of a Drupal consulting engagement produces an inventory, not a plan. The first five days establish what is actually deployed, whether the repository describes it, what is configuration and what is content, and who can change the structure without telling anyone. Every recommendation made before those facts exist is a guess in a confident voice.
The Drupal consulting page covers what the engagement is for and when it is worth buying. This page covers the mechanics of the first week. Every screen and command named below was checked against Drupal core 11.4.6 and the Drush shipped alongside it.
Why week one reads instead of fixes
A site that is misbehaving is evidence, and the standard instinct destroys it. Rebuilding caches loses the symptom. Updating the module that looks guilty erases the version that was failing. Importing configuration overwrites the drift that would have explained everything. By Wednesday you have a site that behaves differently and no record of how it behaved before.
So the first week is read-only on production, and anything intrusive happens against a copy. That is not caution for its own sake: it is the only way the second week can be argued about rather than believed.
The reading order, day by day
| Day | What gets read | Where it comes from | What it settles |
|---|---|---|---|
| 1 | The running site | Status report at /admin/reports/status; drush status |
Core and PHP version, database, cron, and every warning core already knows about |
| 1 | The installed code | The Extend page at /admin/modules; drush pm:list |
How much is core, how much is contributed, how much is custom |
| 2 | Configuration against code | $settings['config_sync_directory'] in settings.php; drush config:status |
Whether the repository actually describes the running site |
| 2 | Pending database updates | drush updatedb:status, and /update.php in a browser |
Whether the code on disk is newer than the database it runs against |
| 3 | The content model | /admin/structure/types, /admin/reports/fields, /admin/structure/views |
What the site thinks its content is, and how much of it is unused |
| 4 | Who can do what | /admin/people/permissions |
Which roles can change structure, and who can publish raw HTML |
| 5 | The error and risk record | /admin/reports/dblog, /admin/reports/updates, composer audit |
What is failing now and what is unpatched |
Three of those rows are where inherited sites usually surprise you.
The field list says more than the content types page
/admin/reports/fields is the most informative screen on a site you did not build. Content types tell you what somebody intended; the field list tells you what was actually created, which storages are shared across several bundles, and which are attached to nothing at all. A pair of fields whose machine names differ only by a numeric suffix is usually the fossil of a failed change.
Configuration drift decides everything after it
Drupal keeps site structure in configuration objects that can be exported to YAML in the directory named by $settings['config_sync_directory']. drush config:status compares what is live against what is exported. If that comparison comes back with differences, the repository does not describe the site — and every deployment plan and estimate afterwards is built on sand until somebody decides which side is authoritative.
On a site where nobody has exported configuration in a year, that single check reorders the engagement: the first job becomes making the repository true, which is considerably cheaper than discovering it during a release.
Permissions are where the surprises live
Two questions on /admin/people/permissions are worth the whole afternoon. Who holds administer site configuration — the permission core requires just to view the status report — and which roles can use the most permissive text format. Drupal generates a permission per text format in the form use text format <id>, so the roles that can publish unrestricted markup are listed right there. On a site with a content problem nobody can explain, that list is frequently the explanation.
If you are weighing whether a week like this is worth buying, the consulting page sets out when it pays for itself. If you already know it is, describe the site in a quote request — size, Drupal version and what is going wrong is enough to scope the week.
The five questions the week has to answer
- What is actually running — core version, PHP version, module inventory, and which of it is custom?
- Does the repository describe the site, or has it drifted?
- What is the content model, and does it match how editors really use the site?
- Who can change structure without a deployment?
- What is failing today, and what is unpatched?
Nothing on that list is a matter of opinion. That is the point: week one closes the questions that have answers, so week two can spend its time on the ones that do not.
The artefact: a facts sheet with sources attached
What comes out is a written sheet, and every row carries where the fact was read, so anybody can re-check it without me.
- Platform
- Core and PHP versions, database, hosting, and which environments exist.
- Code inventory
- Contributed modules with versions, custom modules with a size estimate, and which contributed projects carry local patches.
- Configuration state
- Whether configuration is exported, whether it matches, and which direction the differences point.
- Content model
- Content types, field count, unused fields, and the views driving the main pages.
- Access
- Roles that can alter structure, roles that can publish unrestricted HTML, and who holds the credentials.
- Open risks
- Unpatched advisories, recurring log errors, and anything on a version that no longer receives fixes.
A sheet like that is dull to read and hard to argue with, and it travels: if the engagement ends there, the client keeps a document their next developer can use on day one.
What week one deliberately does not do
No module installs, no updates, no configuration imports, and no writes to production. A bug found in week one gets named, evidenced and ranked — it does not get fixed in passing, because a fix applied mid-inventory removes the evidence the inventory was collecting.
It also does not produce a rebuild recommendation. That judgement needs the facts sheet plus a conversation about budget and appetite, and anybody offering it on day three is selling rather than diagnosing.
Common questions
Do you need access to production?
Read access to the site and the repository. Anything that could change state runs against a database copy in a local environment.
Can we skip this if we already know what the problem is?
Sometimes. The risk is that the named problem is a symptom: a "slow site" is frequently a caching or image problem rather than a code one, which is why the diagnosis for a slow Drupal site runs in layers. If the brief is specific and the site is small, a targeted look is honest and cheaper.
How long does it really take?
It scales with the site, not the calendar. The drivers are the number of content types and fields, the volume of custom code, how many environments exist, and whether anyone can still answer questions about the build. A site with two content types and no custom modules is a short read; one with forty custom modules and no documentation is not.
What if the previous developer is gone?
Then the inventory starts one step earlier: hosting, DNS, repository and credentials. Establishing what you control is part of week one, and it is the part that most often turns out to be incomplete.
Does the site have to be on Drupal 11?
No. The reading order is the same on 9 and 10 — the paths above were read from core 11.4.6, and the ones that matter have been stable for years. If the site is on Drupal 7, the week looks different, because the question stops being "what should we change" and becomes what a rebuild would actually cost.
Next steps
If what you need is a decision rather than a diagnosis — one site or several, coupled or decoupled — that is architecture work, and it starts from the same inventory. If you have a site whose state nobody can describe, tell me what you have and I will tell you what the first week would look at.
