Service
Drupal version upgrades
What you get
- Readiness assessment report
- Contrib module compatibility matrix
- Custom code deprecation audit
- Technical appendix and effort estimate
- Week-by-week build log
- Cutover runbook
- Emergency-freeze and rollback procedure
- Pre-launch and launch checklists
A major-version upgrade is not one task, it is a sequence of them, and the expensive surprises all live in contributed modules and custom code that nobody has read in three years. We start by reading them.
You cannot skip a major version — each one carries the schema floor the next expects — so a Drupal 7 or 8 site reaches 11 in documented hops, each one verified locally and on your hosting platform before the next begins.
Questions we get asked
Yes. The upgrade happens on a branch and a separate environment; your live site keeps running. We agree a content freeze only for the cutover window itself, usually a few hours, and the runbook includes an emergency-freeze procedure if something needs to stop sooner.
They get audited with upgrade_status and by hand, then fixed. Deprecated APIs are the easy part; the awkward cases are modules whose contributed dependency has no Drupal 11 release, where the choice is to patch it, replace it, or absorb it into custom code. That decision is made explicitly, with costs attached, not silently.
That is what the readiness assessment answers. A small site on current contrib can be weeks; a large portal with heavy custom code and a Drupal 7 origin is months. We would rather tell you a real number after looking than a comfortable one before.