A migration moves your content, users, files and addresses off Drupal 7 or another CMS and onto current Drupal. It tends to break in the same places: content that does not map cleanly, custom modules with no modern equivalent, and URLs that change and take search visibility with them. We audit the old site first, map every field before migration code is written, and run a trial migration you can browse, so the comparison with your live site happens before cutover rather than after it.
Who this is for
- You are still on Drupal 7. Community security support ended on 5 January 2025. The site now depends on paid extended support, or on nobody finding the next vulnerability.
- Your CMS has become the constraint. WordPress, Joomla or a bespoke system that editors work around rather than with, and a content model it can no longer hold.
- The site carries years of content and search visibility. Thousands of pages, documents and inbound links that have to arrive intact and keep answering at their old addresses.
- Nobody holds the whole picture any more. The team or agency that built the site has moved on, so the work starts by finding out what is actually in it.
On Drupal 8, 9 or 10 rather than 7? That is an upgrade, not a migration: the site, the database and the editors' screens stay where they are. See Drupal upgrade to Drupal 11 and 12.
What you get from a migration
- A content and module audit you keep whether or not you hire us for the migration
- An entity mapping sheet: every old content type and field against its place in the new model
- A recommendation against every module: Port, Replace, Drop or Decide
- A trial migration you can browse, run again each time the mapping is corrected
- A redirect map for every address the old site published, checked against a crawl
- A rehearsed cutover plan that keeps the old site live until the new one is proven
Sample Module report Drupal 7 to current Drupal · example.org
| Module | Installed | Recommendation | Reason |
|---|---|---|---|
member_import Custom | 7.x-1.2 | Port | The import rules are still needed; rewritten as a Migrate API source for the new site. |
legacy_gallery Contributed | 7.x-2.1 | Replace | No release after Drupal 7; core Media and a gallery component cover the need. |
php Drupal 7 core | 7.x | Drop | Code stored in content is a security risk; the few pages using it become blocks. |
print_catalogue Contributed | 7.x-1.4 | Decide | One team still orders print from it; rebuild, replace or retire is a business call. |
The labels are the same ones we use on Drupal upgrades, so an audit reads the same way whichever route your site takes.
An engineer reads it and replies within one business day.
How a Drupal 7 migration runs
A migration is a content problem before it is a code problem, so the order of work is built around the content: find out what exists, agree where each piece goes, then move it repeatedly until the copy matches.
How a Drupal 7 migration runs
- Audit Content, users, files, modules and integrations, and what should not come across. You keep the audit report
- Entity mapping Every old field mapped to its place in the new model, agreed before code. You keep the mapping sheet
- Fixed price The migration is quoted against the audit and the mapping. You keep the priced scope
- Trial migration Run again each time the mapping is corrected, on a site you can browse. You keep the trial site
- Rehearsed cutover The switch is practised on a copy first, with the old site still live. You keep the cutover runbook
- Watch window Redirects, search coverage and errors checked after launch. You keep the launch report
Images and documents pasted into old body text are pulled out into Drupal media on the way, so editors inherit reusable files rather than raw markup. How the wider project runs, from the free prototype to acceptance, is written up in our process for direct clients.
Keeping your search rankings through a migration
The most expensive thing a migration can break is not content. It is the search visibility the old site built up over years, and it breaks quietly: the new site launches, looks better, and traffic falls for months before anybody connects the two. Nobody can promise rankings, because search engines decide those. What the plan controls are the causes, and each of these is preventable:
- Addresses change and nothing redirects. Every indexed URL that returns a not-found page throws away its ranking and every link pointing at it. The redirect map covers every address the old site published, including the ones the old CMS generated that nobody remembers.
- Titles and descriptions stay behind. They often live in a module's own table, which a content migration that only reads nodes never sees.
- Content arrives as rendered markup. Headings become styled text and the pages stop describing themselves to a search engine. Structured fields are migrated as structure.
- The new site is slower than the old one. We measure the old site first and treat its numbers as the floor, not the target.
- Nobody watches after cutover. Coverage and errors are checked through the weeks after launch, while a mistake is still cheap to put right.
Sample Redirect map Checked against a crawl of the live site · example.org
| Old URL | New URL | Status | Crawl check |
|---|---|---|---|
/node/1284 | /publications/annual-report-2024 | 301 | 200 OK |
/taxonomy/term/37 | /topics/water-quality | 301 | 200 OK |
/sites/default/files/report.pdf | /sites/default/files/2024-05/report.pdf | 301 | 200 OK |
/events/archive?year=2019 | /events?year=2019 | 301 | Fix before cutover |
WordPress, Joomla or a bespoke CMS to Drupal
Moving off another CMS follows the same order of work with a different starting point. There is no shared schema to lean on, so the audit reads the old database directly: posts and pages, custom post types or articles, categories and tags, authors and the media library. Each is mapped to a Drupal content type, taxonomy or media entity before migration code is written, and the Migrate API does the move, so it can be run again rather than retyped by hand.
The parts that need the most care:
- Shortcodes and page-builder markup. Content saved as builder markup is turned into structured fields or reusable components, not carried across as raw HTML.
- Features that live in plugins. Forms, galleries, memberships and SEO fields sit in plugin tables of their own. Each gets the same Port, Replace, Drop or Decide recommendation as a Drupal module.
- Addresses. Date-based permalinks, category prefixes and query-string URLs all go into the redirect map.
Drupal 7 end of life: what it means for your site
Drupal 7 reached end of life on 5 January 2025, and the Drupal Security Team no longer publishes fixes for it. A vulnerability found in core or in a contributed module will not be fixed for you, and the ones already published are public. Commercial extended support exists and buys time, not a way forward.
It does not mean the site stops working tomorrow. Where a site takes nothing in from the public, holds nothing sensitive and is due to be retired anyway, migrating it spends money on a risk you are not carrying, and we will say so.
| What the site does | Move now | Can wait |
|---|---|---|
| Input from the public | Forms, comments or file uploads | Publishes only; nothing comes in |
| Personal data | Member, donor or customer records | Nothing personal stored |
| Accounts and payments | User logins, payments or bookings | No logins, no payments |
| Expected life | Needed for years to come | Due to be retired soon |
What a Drupal migration costs
A migration is priced from the audit, never from the brief, because the cost sits in things nobody can see from outside: how many content types exist as opposed to how many are used, how much content is structured rather than pasted markup, and how many custom modules have no modern equivalent.
The audit is scoped and priced on its own, and its report and mapping sheet are yours to keep. The migration is then quoted at a fixed price against them, on the same project sizes as a new build: the Small size describes a corporate site whose old content migrates alongside the build, and the Large size a platform whose migration plan is part of the architecture. The audit tells you which size yours is before you commit.
Work we have delivered
The full case studies behind the screenshots on this page.
Terms that hold
These terms hold across our services; where a service starts differently, its page says how. The full wording is on the warranty page and in why you own the source code.
- A prototype before you sign a build Before a build project is signed, we build a prototype at no charge: a design, a clickable prototype or a working demo on real code, so you decide against something real.
- You receive the system and its source code Custom work is yours from the first commit: the repository, custom modules, theme and deployment configuration. When we build your system on one of our platforms, you receive the whole system and its source code as well.
- A warranty on development work Development projects carry a 1-year warranty by default, up to 3 years. It covers defects in what we built, and applying the security releases of Drupal core and contributed modules while the warranty runs. Maintenance picks up where the warranty leaves off.
- Response targets we publish A first response in 4 hours for critical issues, 1 business day for high priority and 3 business days for normal. Support runs in business hours; cover outside them is an option, priced separately.
Questions we get asked
Which migration route is yours?
It depends on where you start. From Drupal 7 or another CMS, the content moves into a rebuilt site through the Migrate API. A Drupal 7 site lands on Drupal 11, because Drupal 12 removes the Migrate Drupal modules from core, and moves to Drupal 12 as an ordinary upgrade. From Drupal 8, 9 or 10 it is an in-place upgrade instead, covered on Drupal upgrade to Drupal 11 and 12. The audit confirms the route before any build budget is committed.
What carries over from Drupal 7, and what is rebuilt?
Content, users, taxonomy, files and the relationships between them carry over through the Migrate API. The theme, the custom modules and much of the contributed-module layer are rebuilt for current Drupal. The audit decides what still deserves to move before that rebuild starts.
Will we lose our search rankings?
We cannot promise rankings; search engines set those. What we control is the usual cause of a loss, addresses that stop resolving, which is why the redirect map is a deliverable checked against a crawl before go-live rather than an afterthought.
Can we migrate in stages?
Often, yes. Where a single cutover is too risky, the old and new sites run side by side and sections move across one at a time, with the redirect layer keeping both addressable.
Do users have to reset their passwords?
Not when they come from Drupal 7. Accounts migrate with their existing password hashes, and current Drupal accepts Drupal 7 hashes, so people sign in with the password they already have. Accounts from other systems are checked during the audit, because their hash formats differ.
What do you need from us while it runs?
A decision-maker for content that may be retired, access to the current hosting and repository, and the campaign URLs that must keep working. Your team also reviews the trial migration against real content, which is where mapping errors are caught before cutover.
How long does a migration take?
It depends on content volume, how much custom code exists and how many integrations have to be re-pointed. The audit puts a figure against each of those before you commit, so the estimate is written down rather than guessed.
What can go wrong?
Inconsistent source content, integrations whose owners or documentation are missing, and new features folded into the rebuild without a separate decision. The audit records each risk and the plan assigns a treatment to it; new features are priced and approved apart from the migration.
Not covered here? Ask us directly.
Start with an auditAn engineer reads it and replies within one business day.
Migrate & Audit
Related services
Send us the site, we will tell you what is in it
The content and module audit is the first deliverable, and it is yours whether or not you hire us to do the migration. It is specific enough to hand to any vendor for comparison.
An engineer reads it and replies within one business day.