Not ready to migrate yet?
Drupal 7 extended support
Monthly security patching, monitoring and backups for Drupal 7 sites that need a planned window before migration, with no minimum term.
This is for you if
- your Drupal 7 site is still in production and the migration budget lands next year, not this one
- your host or security team has flagged the site and you need a documented answer this month
- you have several Drupal 7 sites and want to move them one at a time rather than all at once
- you want the site watched by someone who will also do the migration when the time comes
What is included
- Security patching
- Drupal 7 core and contrib no longer receive official security releases. We track the D7 Security Support vendor programme, published advisories and upstream fixes, and apply patches to your site as they appear.
- PHP and server compatibility
- Drupal 7 is kept running on a supported PHP version, with the compatibility patches that requires, so your host cannot force an outage by retiring an old runtime.
- Uptime and error monitoring
- Availability checks, error log watching and alerting to us, not just to you. Problems are looked at by a Drupal engineer, not a ticket queue.
- Off-site backups with tested restores
- Daily database and file backups stored in an EU region, with a restore actually performed and timed every quarter so the procedure is known to work.
- Monthly written report
- What was patched, what was monitored, what we saw and what we recommend. Short, and written for whoever holds the budget.
- Migration groundwork
- While the site is under support we document its modules, content model and integrations. That document becomes the first half of the migration assessment, which shortens it.
Drupal 7 reached end of life on 5 January 2025. A site that is still on it is not broken, but it is exposed, and the exposure grows each month as new vulnerabilities are found in PHP libraries, contrib modules and core code that nobody upstream is fixing. Extended support is a way to hold that exposure steady while a migration is planned and funded properly.
What we actually do each month
Patching comes first. We follow the vendors in the official D7 Security Support programme, the public issue queues of the modules your site uses, and PHP security releases. Fixes are applied to a staging copy, tested, then deployed to production, and each one is logged. Where a module has no fix and a real exposure, we write a patch ourselves or disable the module, and you are told which.
Monitoring runs continuously. Uptime checks hit the site from outside; log watching catches errors and unusual activity from the inside. Alerts go to an engineer who knows the site, not to a generic on-call rotation. Backups run daily to an EU-region store and a restore is performed each quarter so the recovery time is a measured number rather than a hope.
At the end of each month you receive a written report: patches applied, incidents, monitoring findings and a recommendation. It is short on purpose.
What you decide
At the start we agree a target window for the migration, even if it is only a quarter. That date drives the support plan: what is worth patching properly versus what only needs to hold until cutover. You can move the date, but having one keeps the arrangement honest.
You also decide how to handle unfixable findings. If a vulnerability turns up with no patch available, we present the choices the same day: disable the feature, put a mitigation in front of it, or accept the risk for a stated period. We do not make that call for you and we do not bury it in a report.
What can go wrong
The main risk is a Drupal 7 site running on a PHP version its host is about to retire. Drupal 7 can run on PHP 8 with patches, and we apply them, but some contrib modules cannot follow. If the assessment finds one of those, you hear about it in the first week, with a workaround or a reason to bring the migration forward.
The second risk is drift: a site under extended support quietly becomes a site nobody plans to migrate. The monthly report includes the migration date and the state of the groundwork, so that question is asked every month.
How it feeds into the migration
Every month of support produces documentation: the module list with usage notes, the content model, the integrations, the traffic patterns. When you start the Drupal 7 migration, that material is the first half of the five-day assessment, which means a faster scope and fewer surprises in the price. If you later ask us to optimise and manage the hosting, the monitoring and backup checks carry across as well. To find out what state your site is in, start with a conversation.
Common questions
- Drupal 7 is end of life. Is it still possible to keep it secure?
- Reasonably, yes, for a defined period. After 5 January 2025 the Drupal Security Team stopped issuing advisories for Drupal 7, but a small set of vendors continues to produce fixes, and many contrib vulnerabilities are patchable by reading the code. Extended support reduces the risk; it does not remove it, and we will say so in writing.
- Is there a minimum contract length?
- No. It is billed month to month and you can stop at the end of any month. The intent is to buy time for a planned migration, not to keep you on Drupal 7 indefinitely.
- What if a vulnerability appears that cannot be patched?
- We tell you the same day, with the options: disable the affected module, put a mitigation in front of the site, or bring the migration forward. That decision is yours, and we give you the facts to make it.
- Do we have to migrate with you afterwards?
- No. The documentation we produce during support belongs to you and any competent Drupal team can use it. Most clients do stay, because the engineer who has been watching the site is the obvious person to move it.
Not sure which one you need?
Send us the URL and a sentence about what is bothering you. We will tell you which service fits, or whether you need one at all. The first reply is free and commits you to nothing.