Skip to content
BOA Documentation

Powered by Grav

Leaving Drupal 7: choosing your exit

Leaving Drupal 7: choosing your exit

Scoped the way it usually is, leaving Drupal 7 reads like a rebuild with a removals job stapled to it: audit spreadsheets, content-model workshops, a migration pipeline per content type, a verdict per module, a redirect map for every URL, a staging estate to rehearse on, freeze windows, delta syncs, a DNS cutover and a month of watching the rankings. Priced that way, the maths rarely works out for a modest site — which is a large part of why so many Drupal 7 sites simply stayed put.

Here the project changes shape, because most of that weight was never really about your site — it was migration infrastructure and cutover choreography, and the platform already owns both. Your account hosts both ends at once: the Drupal 7 site that keeps serving visitors, and — right next to it — the site it is becoming. Two exits are built in, both rehearsed safely beside the live site, and neither is ever picked for you.

The two exits

Upgrading to Backdrop is the continuity exit. One panel task converts a copy of your site to Backdrop CMS — the whole database travels: posts, comments, users, tags, files, URL paths, custom fields, menus, your saved views (Views is part of Backdrop core), and your settings become Backdrop configuration. The same content model, the same editorial habits, modern PHP underneath. Backdrop's own commitment is that its API stays close to Drupal 7's, so custom code is ported rather than rewritten — and the task prints a per-module compatibility report before anything is created, so you know what carries, what has a Backdrop port, and what would be switched off (with its data kept).

Migrating to Drupal CMS is the modern-toolset exit. A fresh Drupal CMS site is installed next door, and Drupal's own Migrate API pulls your content, files, taxonomy and users across — imported users keep their old passwords. What crosses is the content; the front end is a fresh start: your Drupal 7 theme, custom modules and views do not travel, and rebuilding them on the modern toolset is a real project of its own. In exchange you land on current Drupal core with its whole ecosystem ahead of you.

What stops existing here

Whichever exit you take, most of the classic project's line items have no counterpart on this platform:

  • The staging estate. Both ends live on one server, on your account. The rehearsal target is an ordinary site, running on the same production stack that will serve the result — no second machine, no database dumps shipped anywhere.
  • The rehearsal budget. Rehearsals are disposable copies: run, inspect, delete, redo. Every rehearsal is as clean as the first, and the live site is never in the write path — on either route, a failed attempt costs a Delete task, never a restore.
  • The redirect map. The cutover is a rename, so your domain does not change — and your URLs largely don't either: the Backdrop conversion carries URL paths in the database, and the Drupal CMS migration brings URL aliases and pathauto patterns across. Redirects shrink from an every-URL map to a short list of paths that genuinely changed.
  • Freeze windows and delta syncs. There is nothing to delta-sync, because there is no staging copy to reconcile: the final run is the cutover build. Content editing pauses for the length of one run — minutes on a modest site — not for days.
  • The DNS cutover. When both ends are on the same instance, the swap is panel rename tasks, with no DNS event and no propagation window. DNS is involved only when the old site lives elsewhere — and then it is a single ordinary change.
  • The rollback plan. Rollback is a state, not a document. On the Drupal CMS route the retired Drupal 7 site keeps serving at its retirement name, one rename away from taking back over; on the Backdrop route the original is never touched at all.
  • The forgotten noindex. Rehearsal protection is bound to the name: on a dev.-prefixed domain, crawlers and bots are served a 404. The protection disappears with the rename itself, so there is no launch-day setting to remember.

What remains yours

Neither exit makes the move free, and each route's page says so before you commit anything:

  • On both routes: walking the result like an editor and a visitor, re-checking anything that talks to an outside system, and an SEO once-over (page titles, sitemap, the short redirect list) before and after cutover.
  • On the Drupal CMS route: the front end. Theme, custom modules and views are rebuilt on the modern toolset — after the platform absorbs the infrastructure, this is the honest cost that remains.
  • On the Backdrop route: ports. A contrib module without a Backdrop port is switched off on the copy (its data tables are kept), a patched module needs its patch carried to the port, and your theme needs its Backdrop port too — the conversion carries the theme and keeps it serving as far as it works, and close APIs make the port an adaptation rather than a rewrite, but it is still work.

Which exit is yours

  • Choose Backdrop when continuity is the point: you want to keep the site's structure, its editorial habits and its D7-shaped custom code, on a maintained platform with modern PHP — at the smallest possible project size.
  • Choose Drupal CMS when the modern toolset is the point: a redesign is due anyway, you want current Drupal core and its ecosystem, or you need capabilities that only exist there.

And if you genuinely can't tell: run one rehearsal of each. Both exits work on disposable copies beside the live site, so trying both costs attention, not risk — and a converted copy of your site answers the question better than any decision matrix. Both exits stay open; nothing on this page, or on this platform, commits you to either.

Where to go next

© 2026 BOA Documentation. All rights reserved.