Still on Drupal 7?
Drupal 7 migration
A fixed-price rebuild of your Drupal 7 site on Drupal 11: valuable URLs preserved or redirected, content migrated by script, a planned low-downtime cutover.
This is for you if
- your site runs Drupal 7, which stopped receiving security fixes on 5 January 2025
- you need a price and a date before you can get budget approved
- the people who built the site are gone and nobody fully knows what is in it
- you cannot afford to put search visibility, inbound links or editor workflows at risk during the move
What is included
- Five-day assessment
- A fixed fee, quoted after a free initial review and deducted from the migration if you go ahead. We read the code, the database and the traffic logs, then hand you a written scope and a fixed price. If you walk away at that point, you keep the document.
- Content model on Drupal 11
- Content types, fields, taxonomies, users and files are rebuilt on Drupal 11 with the same names where that makes sense and better ones where it does not.
- Scripted content migration
- Content moves with the Migrate API, migrate_upgrade and migrate_plus. The scripts run repeatedly during the build, so the final run on launch day is a rehearsal we have already done.
- URL and redirect plan
- Every valuable public URL on the old site either keeps its path or gets a 301 redirect, checked by script against a crawl of the live site and your Search Console data. Nobody can guarantee rankings; the SEO signals are protected through that mapping and thirty days of post-launch monitoring.
- Planned low-downtime cutover
- A final content sync, a DNS change and a rollback path that stays open. We plan for zero downtime and schedule for low impact, because DNS changes reach different networks at different speeds. Editors are told in advance when the content freeze starts and ends.
- Thirty days of monitoring
- We watch error logs, redirect hits, Search Console and uptime for a month after launch and fix what we find at no extra cost.
Drupal 7 was released in January 2011 and reached end of life on 5 January 2025. It still works, but it no longer gets security releases from the Drupal Security Team, and it runs on PHP versions that hosting providers are removing. Moving off it is not a question of whether, only of when and how carefully.
How the assessment works
It starts with a free initial review. Send us the URL and within one working day we tell you whether a migration makes sense and what the assessment will cost. The assessment itself is a paid piece of work at a fixed fee, deducted from the migration price if you go ahead.
The five working days are spent reading your site, not selling to you. We look at the codebase, the database, the contrib module list and the traffic logs. The output is a written document listing every content type, module and integration, sorted into three groups: moves as-is, needs rebuilding, and can be retired. It also contains the fixed price, the launch date and the name of the engineer who will do the work, who is the person who wrote it.
You decide what to do with the third group. Old sites carry features nobody has used in years. Dropping them shortens the project, and we will say so, but the call is yours.
What happens during the build
The new site is built on Drupal 11, which requires PHP 8.3 or newer and is managed with Composer and Drush. Content migrates by script: the core Migrate API plus migrate_upgrade and migrate_plus read the Drupal 7 database directly and write nodes, terms, users, files and menus into the new structure. Because the migration is code, we run it many times during the build. Each run surfaces edge cases, such as a field that held HTML it should not have, and each fix goes into the script rather than being done by hand.
Editors see the new site early on staging. Their feedback on the editing screens, usually the biggest visible change, is folded in before launch rather than after. Every Friday you get a written status: what was done, what is next, what needs a decision from you.
What can go wrong
Three things cause most trouble in Drupal 7 migrations. Custom modules with undocumented behaviour are the first. We read them line by line during the assessment so surprises land before the price is agreed. Field data that does not match its declared type is the second. The migration scripts validate as they go, and mismatches are reported to you with a suggested fix. Third, URLs. A site of any age has links pointing at it from places nobody remembers. We crawl the live site before launch and test every path against the new one, either matching it exactly or mapping it to a 301 redirect.
Launch and after
Cutover is a rehearsed sequence: content freeze, final migration run, verification, DNS switch. The old site stays available for rollback. DNS propagates gradually and at different speeds for different networks, so both sites serve identical content during the overlap. For most visitors the switch is invisible; the plan is built so that any interruption is measured in minutes, not hours.
For thirty days after launch we monitor logs, uptime and Search Console and fix whatever appears. Then you receive the repository, the hosting credentials and a runbook explaining how to update and deploy the site. Many clients then move to a support retainer or ask for a hosting review, but that is a separate decision and the site works without us. If you want to see the shape of a finished project, read the case studies or start a conversation.
Common questions
- Why does a Drupal 7 site need a rebuild instead of an upgrade?
- There is no in-place upgrade path from Drupal 7. Drupal 8 changed the underlying framework, so a Drupal 7 site is rebuilt on the new version and its content is migrated across. Core provides the Migrate API for exactly this. Configuration, theme and custom modules are written again, usually smaller.
- How long does a Drupal 7 to Drupal 11 migration take?
- The assessment tells you. As a rough shape: a brochure site with a few content types is weeks, a site with many custom modules, integrations or thousands of nodes with complex fields is months. The fixed price and the date are in the scope document, and both are agreed before work starts.
- What happens to our Drupal 7 contrib modules?
- Each one is checked for a Drupal 11 release, a replacement in core or a different module that does the same job. Views, Media, Layout Builder and CKEditor 5 are now core, so a lot of Drupal 7 contrib simply disappears. Anything with no successor is rebuilt or dropped, and you decide which.
- Can we keep the site running while you build the new one?
- Yes. The Drupal 7 site keeps serving traffic until the day of cutover. If it needs patching in the meantime, our Drupal 7 extended support covers that.
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.