Drupal work, including the part nobody wants to quote on
Most Drupal enquiries we get are one of two things: a Drupal 7 site that’s years past end of life and can’t be upgraded in place, or a Drupal 10 site that works fine and needs someone who’ll still answer the phone next year. Both are work we take on.
What we take on
Drupal 7 migration
Moving a Drupal 7 site onto the supported line. This is a content migration into a fresh build, not an update — see below for why that distinction costs people money.
Custom module work
New modules, and rewriting Drupal 7 modules for the current plugin and service architecture, which is a different codebase rather than a port.
Content modelling
Content types, fields, taxonomy, Paragraphs and Layout Builder set up so editors can work without a developer in the loop for routine changes.
Views and display logic
Listings, filters, feeds and the display configuration that most “simple” Drupal requests actually turn out to be.
Performance work
Caching layers, BigPipe, object caching, and the slow queries that appear once a site has accumulated contributed modules for a decade.
Security and version upgrades
Composer-managed updates, applying security advisories, and an honest assessment of what an unsupported core version exposes you to.
Why Drupal 7 can’t just be updated
This is the single most expensive misunderstanding in Drupal, and it’s an easy one to have, because every other version jump worked the way you’d expect.
Drupal changed architecture fundamentally after 7. The current line is a different framework underneath — Symfony components, Composer-managed dependencies, Twig templating, configuration held in files rather than the database. So:
- Content migrates, configuration doesn’t. Nodes, fields, users, taxonomy and files move across with the migration tooling. The site’s behaviour gets rebuilt.
- Custom modules get rewritten, not ported. Code written against Drupal 7’s hook system doesn’t map onto the current plugin and service pattern. The logic survives; the code doesn’t.
- Some contributed modules have no successor. Each one is a decision: a replacement module, core functionality that absorbed it, or custom code. This is where the estimate actually lives.
- The theme is new work. Twig templates and current front-end build tooling, not the old template layer.
Anyone quoting a Drupal 7 migration as an upgrade hasn’t looked at your module list. We price it after an audit of that list, because before the audit nobody can honestly tell you the number.
How exposed an old version is
Drupal 7 has been past end of life since early 2025. Drupal 9 since late 2023. Past end of life means the security team no longer issues advisories for it, so newly found vulnerabilities stay open permanently.
Two things are worth being clear about:
- Nobody is targeting you specifically. Unsupported installs get found by automated scanning that works through known vulnerabilities against every address it can reach.
- Commercial long-term support exists for Drupal 7 through vendors outside the project. It buys time; it isn’t a destination.
If the site still earns, the honest sequence is: contain the security exposure now, then plan the migration as a project with a budget rather than an emergency. If it doesn’t earn, that changes the answer, and we’ll say so.
A site audit tells you which situation you’re in, and it costs nothing.
How a Drupal 7 migration runs
Audit the module list and the custom code
Every contributed module gets a decision: successor exists, absorbed into core, needs replacing, or needs writing. Custom modules get read, not guessed at. This is the step that produces a real number.
Inventory every URL first
Drupal sites generate URL aliases, and those aliases are what Google has indexed and what other sites link to. The alias map is built before any content moves, so nothing launches without a redirect behind it.
Build the content model on the new version
Content types and fields set up to match what the content actually is, rather than reproducing a structure that grew by accretion over ten years.
Run the migration repeatedly
Migrations get re-run as the model is corrected, which is normal and expected. The old site stays live and authoritative throughout.
Theme, test, and go live with redirects already in place
Then 30 days watching Search Console for 404s, because migration problems surface after launch rather than during it.
When staying on Drupal is right
Drupal is genuinely good at some things, and we’d rather migrate you onto a current Drupal than off it when:
- The content model is complex — many interrelated types, deep taxonomy
- Editorial workflow and granular permissions matter
- You run multiple sites off one codebase
- You need it as a content back end for a separate front end
- You have in-house Drupal skill and want to keep using it
- Multilingual content is central rather than an add-on
When moving off it is right
And the other direction, which is the more common answer for smaller sites:
- It’s really a brochure site or a blog. Drupal’s strengths cost you maintenance you’re not getting value from.
- Every change needs a specialist. If your team can’t edit the site, the platform is working against you.
- Quotes keep coming back high. That’s a supply problem, and it gets worse each year, not better.
- The store is the business. Ecommerce has better-supported options — Shopify, WooCommerce or Magento.
We migrate Drupal to WordPress regularly. The work is in the content model — Drupal’s nodes and fields don’t map one-to-one onto post types and custom fields, so that mapping is designed rather than automated. URL aliases carry across as 301s, so search history survives.
Common questions
Our Drupal developer is gone and nobody knows how the site works. Can you take over?
Yes, and it’s a common starting point. It begins with an audit, because we need to know what’s custom and what’s stock before changing anything. Custom modules written by someone who left and documented nothing are readable — it just takes time, and we quote that time honestly rather than discovering it later.
Can you give a rough Drupal 7 migration cost before the audit?
Not an honest one. The cost is driven almost entirely by your contributed module list and your custom code, not by how many pages you have. A 2,000-page site with a stock module set is cheaper than a 200-page site with eleven custom modules. We can usually scope it from a module list and database access in a few days.
Will we lose our Google rankings?
Not if the URL alias map is built before anything moves. Rewriting content doesn’t lose rankings; changing or deleting URLs does. Those are different things, and conflating them is why most platform migrations lose traffic. More under search engine optimization.
Can you just keep our Drupal 7 site secure instead?
To a point, and sometimes that’s the right call for a year or two. It means commercial long-term support for core, hardening at the server and firewall layer, and accepting that some contributed modules will never be patched again. We’ll tell you what’s still exposed rather than implying it’s solved.
Do you work alongside an existing team or agency?
Often, including white-label under an agency’s name. Being the specialist brought in for the Drupal-shaped part of a larger project is a normal arrangement for us.
Send us your module list
That, your core version, and what’s currently going wrong. It’s enough for us to tell you whether this is a security job, a migration, or a move off Drupal entirely.