Drupal Developer & Migration Consultant

Fourteen years and every major version from Drupal 6 to 11. Most of that time has been spent on platforms other people built — inheriting a codebase, working out what the original team intended, and getting it to a state where the next change is not frightening.

Migrations and version upgrades

The jump from Drupal 7 to 10 or 11 is a rebuild of the technical layer with the content carried across, not an update. That is the honest framing, and any proposal that describes it as an upgrade is setting expectations that will not survive contact with the work.

What a migration actually involves:

Audit first. Every contributed module gets a decision: a modern equivalent exists, the functionality moved into core, it can be dropped, or it needs rewriting. This list is where the real timeline comes from.
Content model review. A migration is the one cheap opportunity to fix a structure that has drifted. Migrating a bad model faithfully preserves the problem.
Migrate API. Repeatable, re-runnable migrations with mapping and validation, so you can migrate, review, fix and re-migrate rather than getting one attempt.
URL and SEO continuity. A complete redirect map from old paths to new, preserved metadata and structured data. Losing rankings in a replatform is common and entirely avoidable.
Editor transition. The new admin experience differs enough that documentation and a walkthrough are part of the job, not an optional extra.

Architecture and custom development

For new builds and significant features: content architecture using entities, fields, taxonomy and Paragraphs; custom modules following current Drupal standards with dependency injection, services and plugins rather than hooks everywhere; Twig theming; configuration management so environments stay in step; and multisite or multilingual setups where they genuinely earn their complexity.

I default to contributed modules over custom code, and to core over contributed. Every custom module is something you own forever, and the cost of that shows up in the next upgrade rather than in this sprint.

Where a build calls for AI — retrieval over your existing content, editorial tooling, semantic search — see AI for Drupal & WordPress. Doing it inside Drupal means respecting node access, cache tags and the queue system, which is where most AI-in-CMS implementations go wrong.

Performance

Drupal performs well when its caching is configured correctly and badly when it is not. The usual work: getting render caching and cache tags right so invalidation is precise rather than a blunt full flush, BigPipe for perceived speed, Redis for cache and sessions, Varnish or a CDN in front, and finding the views and custom queries that scan the whole node table.

Diagnosis before changes, always. Slow Drupal sites usually have one or two specific causes, and applying general advice without profiling tends to add complexity without moving the number.

Security and maintenance

Drupal core has a strong security team; most compromises come through contributed modules left un-updated. Staying current is the single highest-value security measure, which makes it a process problem more than a technical one — Composer workflows, a staging environment that matches production, automated tests giving enough confidence to apply updates promptly, and a deployment pipeline that makes doing so routine.

Retainer arrangements typically cover security updates within a defined window, monitoring, backups with tested restores, and a set amount of development time each month.

Rescue work

A recurring engagement: a site whose original agency is gone, with no documentation, an unknown deployment process and a version that stopped receiving security coverage some time ago. That starts with an audit — what is running, what is customised, what is exposed, and what will break — and produces a prioritised plan separating what must be fixed this month from what can wait for a planned migration.

See this in practice: Drupal Modernization & Migration

Common questions

How long does a Drupal 7 to 11 migration take?

It depends almost entirely on the module audit rather than on content volume. A site using mostly core features with a clean content model can move in a few weeks; one with substantial custom code and abandoned contributed modules takes months. The audit is the first deliverable precisely so the timeline is based on what is actually there rather than an estimate made before looking.

Will we lose search rankings?

Not if the migration is done properly. That means a complete redirect map from every old URL to its new location, preserved page titles, meta descriptions and structured data, and monitoring in Search Console through the transition. Ranking loss during a replatform is common but it is a consequence of skipping this work, not an inherent risk.

Should we move to Drupal 11 or switch platforms entirely?

A fair question and worth answering honestly. Drupal earns its complexity where you have structured content, multiple editorial roles, multilingual requirements or genuine integration needs. For a brochure site with occasional updates it is more platform than the job requires. I would rather advise a move to something simpler than migrate you onto a system you do not need.

Can you work with our existing development team?

Yes, and that is often the better arrangement. This can be architecture and code review, taking on the specific pieces your team has not done before, or leading a migration while the team continues feature work. Knowledge transfer is explicitly part of it — leaving a team unable to maintain what was built is a failed engagement.

Do you do Drupal core contribution?

I contribute modules and patches back where work I am doing produces something generally useful. Practically, the value to you is familiarity with how core actually behaves and with the issue queues where problems get discussed — which shortens diagnosis considerably when something is not behaving as documented.