Drupal vs Backdrop CMS: when to rebuild and when to upgrade in place
A Drupal 7 site past end of security support has to move now, and the choice is between a rebuild and an in-place upgrade. Drupal 7 security support ended on January 5, 2025, and drupal.org lists migrating to modern Drupal or buying extended security support from certified vendors as the options. A rebuild on Drupal 10 or 11 fits best when you want the current core, a long-term roadmap and the largest pool of contributed modules. Drupal 10 reaches end of life on December 9, 2026, so a rebuild that targets Drupal 10 now will need another move within months, while Drupal 11 is the current major version and Drupal 12 is scheduled for the week of December 7, 2026. Drupal.org documents that Drupal 7 sites cannot simply be updated to Drupal 10 or later. They are migrated into a new site with the core Migrate, Migrate Drupal and Migrate Drupal UI modules, and every theme must be rebuilt because themes cannot be migrated.
An in-place upgrade to *Backdrop CMS* fits best when budget for a rebuild is limited, the site is stable, and most of its contributed modules already have a Backdrop equivalent. Backdrop documents the path as running update.php on the existing site after removing content or features Backdrop no longer supports, and it recommends keeping the original site for comparison. Check the module list first: Backdrop's top 100 Drupal 7 modules page counts 19 modules included in core, 17 with an alternative in core, 59 ready in contrib, 2 underway, 7 with an alternative in contrib and 2 not started. Confirm that each module your site depends on falls in a usable category, and confirm your hosting meets Backdrop's requirements, which list PHP 7.1 or later and MySQL or MariaDB 5.5.0 or later.
The decision turns on four inputs: module coverage, theme rebuild effort, hosting plans and the size of the developer pool each route depends on. Backdrop has a much smaller community than Drupal, so ask any implementation partner how many developers they can staff on Backdrop and how they will support fixes to modules that have no maintained equivalent. Ask for a written inventory of modules and custom code in the quote, since that inventory drives effort on both routes. Treat the Drupal 7 site's remaining life as a planning constraint, and do not assume Drupal 7 extended support will be available indefinitely.
Which route fits which Drupal 7 site
This table maps common Drupal 7 site profiles to the route that usually fits best, with the fact behind each judgment. Every row depends on a site audit of modules, themes, custom code and sign-in requirements, so treat each answer as the route to test first. The main takeaway is that module coverage and PHP targets decide most cases, while a small team should choose update.php only when the audit comes back clean.
| Drupal 7 site profile | Better fit | Reason |
|---|---|---|
| Mostly core and well-maintained contrib modules | Backdrop update.php, if the modules map | Backdrop's top 100 list shows 19 modules in core, 17 with a core alternative and 59 ready in contrib. Confirm each module on your list. |
| Many custom modules | Drupal 11 rebuild | Custom code is reworked in both routes. Drupal 10 reaches end of life on December 9, 2026, so a rebuild should target Drupal 11 or 12. |
| Custom theme | Drupal 11 rebuild | Drupal themes must be rebuilt rather than migrated. Confirm with your designer whether your theme can be carried into Backdrop. |
| Sign-in through SAML or OpenID Connect | Drupal 11 rebuild | The samlauth 8.x-3.14 release supports Drupal 10.3 and later and Drupal 11. Confirm a Backdrop equivalent before choosing update.php. |
| Must stay on current PHP and database versions | Drupal 11 or 12 rebuild | Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5. Backdrop's documented floor is PHP 7.1 and MySQL or MariaDB 5.5. |
| Small internal team | Backdrop update.php, if the audit is clean | The update path keeps the original site for comparison. A Drupal rebuild adds a new site, content migration and theme work to staff. |
How each route changes the platform underneath your site
Both routes end on a different runtime, database and patch rhythm than the Drupal 7 site you run today. The cards below cover the components that move with the choice, so you can compare hosting changes and patching cadence before you commit to either path.
PHP version floor and end of life
Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later. Drupal 10 reaches end of life on December 9, 2026, so a rebuild on Drupal 10 starts with a short support window. Backdrop's floor is lower, at PHP 7.1 or later from Backdrop 1.31.0. Check whether your current host can run the PHP version each route needs, and whether your hosting provider schedules PHP upgrades for you or leaves them to your team.
Backdrop PHP and database minimums
Backdrop lists PHP 7.1 or later and MySQL or MariaDB 5.5.0 or later as minimums, with the MySQL and PHP floors raised in the 1.30.0 and 1.31.0 releases. Those minimums are older than current database and PHP versions, which means a Backdrop site can sit on hardware and runtimes that no longer receive vendor patches. Ask whether your team will pin the stack to versions you can still patch, and who owns that decision after go-live.
Database choice and engine support
Drupal 11 supports MariaDB 10.6 or later, MySQL 8.0 or later, PostgreSQL 16 or later and SQLite 3.45 or later, with Microsoft SQL Server and MongoDB available through contributed modules. Backdrop's documented requirement is MySQL or MariaDB. A rebuild on Drupal opens PostgreSQL as an option, while an in-place upgrade keeps your current engine. Confirm which engine your database team supports and whether you need PostgreSQL for other systems.
Web server support
Drupal runs on Apache, Nginx and other web servers. Backdrop recommends Apache with mod_rewrite and supports Nginx. If your current Drupal 7 site depends on Apache-specific rewrite rules, .htaccess handling or a shared hosting control panel, the rebuild and the in-place upgrade both need those rules tested again. Confirm the rewrite configuration, TLS termination and caching layer in a staging copy before you choose a route.
Disk footprint Backdrop lists
Backdrop's system requirements list at least 15 MB of disk space for the software itself. That figure covers the core install only, not your files, database, logs or backups. A Drupal rebuild will need more room for the new codebase, contributed modules and the parallel site you keep for comparison. Measure your current file directory, database size and backup retention before you size storage for either route.
Drupal 10 or 11 and Backdrop side by side on the factors that decide the move
This table sets Drupal 10 or 11 against Backdrop on the factors that usually decide a Drupal 7 exit: licensing, release timing, API promises, identity integration, module coverage and PHP requirements. Read each row as a question to answer for your own site, and treat the module status as a starting point to verify against the current project pages.
| Factor | Drupal 10 or 11 (rebuild) | Backdrop (in-place upgrade) |
|---|---|---|
| License | GPL-2.0-or-later for Drupal and contributed files on Drupal.org. No paid edition of Drupal itself. | Core repository licensed GPL-2.0. Confirm the license of any third-party contributed module you plan to use. |
| Release cadence | Bugfix releases on the first Wednesday of each month, security releases on the third Wednesday. Drupal 10 reaches end of life on December 9, 2026. Drupal 12 is scheduled for the week of December 7, 2026. | A new minor release every four months, on January 15, May 15 and September 15. No major release is currently planned, and future majors may come every three or more years. |
| API compatibility | Major versions carry deprecation cycles between releases, so custom code and contributed modules need periodic updates. Confirm the deprecation policy for the target version with your module list. | Aims for API compatibility within a major version, covering public function signatures, hooks, front-end markup and Form API element properties. Database and configuration schemas may change in minor releases, so plan database backups before each update. |
| Identity integration | Contributed SAML Authentication module (samlauth) acts as a SAML service provider. Latest stable 8.x-3.14 supports Drupal 10.3 and later and Drupal 11. OpenID Connect module covers Google, GitHub, Okta and generic OAuth 2.0. | Confirm SAML and OpenID Connect module availability for Backdrop with the Backdrop project pages before scoping. Do not assume a Drupal 7 module carried over unchanged. |
| Module coverage | Modules are rebuilt for Drupal 10 or 11, and themes must be rebuilt because they cannot be migrated. Coverage depends on the contributed projects you use. | Of Backdrop's top 100 Drupal 7 modules list, 19 are included in core, 17 have an alternative in core, 59 are ready in contrib, 2 are underway, 7 have an alternative in contrib and 2 are not started. Recheck this list for your modules. |
| PHP requirements | Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later. | PHP 7.1 or later (from Backdrop 1.31.0). Confirm the PHP version your hosting stack supports for long-term operation. |
| Database and hosting | MariaDB 10.6 or later, MySQL 8.0 or later, PostgreSQL 16 or later or SQLite 3.45 or later, with web servers such as Apache or Nginx. | MySQL or MariaDB 5.5.0 or later, Apache with mod_rewrite recommended and Nginx supported, and at least 15 MB of disk space. |
| Upgrade effort | Migration into a new site with the core Migrate modules or Drush. Content, configuration and theme work are all in scope. Ask for a written estimate covering each. | Three stages: research the Drupal 7 site, remove content or features Backdrop no longer supports, then run update.php. Keep the original site for comparison. |
Licensing, editions and what costs money on each side
Drupal core and the contributed files hosted on Drupal.org are licensed under the GNU General Public License version 2 or later. There is no paid edition of Drupal itself, so the software line in a budget is zero. The paid options that exist sit around the code: services, hosting and extended security support for sites that cannot migrate yet. Review the Drupal.org licensing page with your legal team before you rely on this summary.
- Core license: GPL-2.0-or-later covers Drupal and derivative contributed files on Drupal.org, so you can run and modify the software without a per-site or per-user fee.
- No paid edition: There is no commercial Drupal tier to purchase. Moving to a newer major version means project labor, not a license upgrade.
- Extended security support: For Drupal 7 sites that cannot migrate yet, drupal.org lists HeroDevs and Tag1 Consulting as certified providers. These are separate contracts with recurring fees set by each vendor.
- Migration labor: Drupal 6 and 7 sites move into a new Drupal 10 or later site with the core Migrate tools, and themes must be rebuilt. That work is a one-time project cost, scoped by the content and features you carry over.
Ask each extended support vendor for its coverage period, scope, renewal terms and exit conditions in writing.
Backdrop core is licensed under GPL-2.0, and the project describes itself as free and open source. Backdrop does not document a paid edition of its core in the material reviewed here, so confirm that with the project before you budget. Costs appear in the same places as on the Drupal side: labor for the upgrade, hosting, and any support you choose to buy from a provider.
- Core license: GPL-2.0 covers the core repository on GitHub, so the software itself carries no license fee.
- Upgrade path: Backdrop documents an update.php route from Drupal 7 that follows removing content or features Backdrop no longer supports. The main one-time costs are the research, preparation and testing stages.
- Release cadence: Minor releases arrive every four months, on January 15, May 15 and September 15. The releases page says no major release is currently planned, and future major releases may come every three or more years.
- Support providers: Backdrop's upgrade documentation links a directory of certified upgrade specialists. Ask any specialist for scope, response terms and who is responsible for applying security updates.
Confirm which Backdrop minor line your chosen modules support, and ask whether any paid support arrangement covers the minor releases that ship during your project.
Contributed modules are free to download on both sides, but each one carries its own maintenance status. That status drives most of the long-term cost, because a module that stops receiving updates turns into custom code you must patch and test. Coverage also differs between the two ecosystems, so the same site can need more custom development on one platform than on the other.
- Maintenance status: Drupal.org shows each contributed project's release and support status. Confirm that every module you depend on supports the Drupal version you target.
- Backdrop coverage: Backdrop's top 100 Drupal 7 modules page counts 59 modules as ready in contrib, 19 included in core, 2 underway and 2 not started. Check your own module list against that page before you assume coverage.
- Custom code: A module with no maintained equivalent becomes custom development, which recurs as long as you run it.
- Identity modules: Drupal's contributed SAML Authentication module supports Drupal 10.3 and later and Drupal 11. Confirm the equivalent identity option on Backdrop before you assume single sign-on works the same way.
- Advisories: Confirm how security advisories reach your team for each module on either platform, and who is accountable for applying the fix.
Export your full module list and mark each entry as maintained, replaced or custom before you request a quote from any implementation partner.
License fees are zero on both routes, so budgets go to people, infrastructure and contracts. The split between one-time project work and recurring operating work decides which route costs more over several years. Compare three-year totals rather than only the first project invoice, since the recurring items are where the routes diverge.
- One-time project labor: A Drupal rebuild through migration or a Backdrop upgrade through research, preparation and testing. Implementation partners usually price these as fixed-scope work agreed in writing.
- Recurring labor: Module updates, patching, runtime upgrades and regression testing. Drupal major versions arrive on a published schedule, and Backdrop minor releases also require testing.
- Hosting requirements: Drupal 11 requires PHP 8.3 or later and a supported database such as MariaDB 10.6 or later. Backdrop's documented minimum is PHP 7.1 or later and MySQL or MariaDB 5.5.0 or later. A lower minimum is not a security baseline, so set your own runtime policy.
- Support contracts: Extended security support for Drupal 7 is a recurring vendor fee until migration completes.
- Quote requests: Ask for labor by phase, the assumptions behind each effort estimate, hosting sizing and the renewal terms for every support contract.
Before comparing offers, confirm which runtime versions your hosting team will support for the full contract period.
What drives the cost of running each route
The cost of either route splits into one-time work and recurring running costs, and the people paid for each part differ. On the Drupal rebuild, you pay for a site audit, a new Drupal 10 or 11 build, rebuilt themes (Drupal.org documentation states that themes cannot be migrated and must be rebuilt), custom module rewrites and a content migration using the core Migrate, Migrate Drupal and Migrate Drupal UI modules or Drush. On the Backdrop route, the one-time work is the audit, removing unsupported content or features, porting modules that have no Backdrop equivalent, and running update.php on a copy of the site. In both cases the fixed-scope agreement should itemize these lines so you can compare them. Recurring costs on either route are hosting, patching, support contracts and internal staff time, and they continue for the life of the site.
The main drivers are the number of custom modules, theme complexity, content volume and the number of integrations. Backdrop's top 100 Drupal 7 modules page counts 59 modules as ready in contrib, 19 included in core, 2 underway in contrib, 7 with an alternative in contrib, 17 with an alternative in core and 2 not started, so your own module inventory matters more than the headline count. Each custom module, and each integration with identity, payment or ERP systems, adds testing and rework on either route. Ask the vendor to price the two open-module categories separately and to state which assumptions about content volume and theme scope its quote depends on. Ask for the audit deliverable to be fixed in writing before design work begins, so the rebuild estimate rests on a known inventory.
If the rebuild will not finish before Drupal 7 support ends, ask about extended security support now rather than later. Drupal.org lists HeroDevs and Tag1 Consulting as certified providers for sites that cannot migrate yet, and Drupal 7 security support ended on January 5, 2025. Ask each provider for the coverage period, the modules and versions covered, the price basis and whether the fee recurs, and whether the contract ends automatically once you migrate. Keep the written quote explicit about who holds upgrade and maintenance responsibility after go-live, the handover of documentation and the test evidence used to accept each phase. Confirm these points with the vendors and your own environment, since terms are set by each provider.
Moving a Drupal 7 site to Backdrop or to Drupal 10 or 11, in order
The two routes start from the same audit but diverge at the preparation stage: Backdrop upgrades the existing site in place, while Drupal 10 or 11 rebuilds it in a new site and moves content across. Following the steps in order shows what transfers, what is rebuilt and what must pass testing before either route goes live.
Audit the Drupal 7 site and its dependencies
Start by inventorying content types, fields, views, custom and contributed modules, themes, integrations and authentication. Your team, or a partner you contract, does this work. For Backdrop, the documented first stage is to research the Drupal 7 site to estimate effort, and Backdrop's top 100 Drupal 7 modules page shows which contributed modules already have a counterpart in core, in contrib or no path yet. Check each module against that page and against the Drupal.org project pages for Drupal 10 and 11 equivalents. The step is done when you have a written list of every module, theme and integration marked as core, contrib, alternative or rebuild, with an owner for each open item.
Decide the route with the audit in hand
Use the module list to choose between an in-place Backdrop upgrade and a Drupal 10 or 11 rebuild. Backdrop's upgrade path keeps the existing database and content structure, but it requires removing content or features Backdrop no longer supports. A Drupal rebuild moves content into a new site and requires rebuilt themes and custom modules. Confirm with each module maintainer or vendor whether the version you need supports your target. Record the decision, the owner and the reasons. The output is a signed-off route decision that names the target platform, its PHP and database versions, and the modules that block the route.
Prepare the source site for the chosen route
For Backdrop, this is the second documented stage: remove content types, fields, modules or features that Backdrop no longer supports, and clear out stale data. For a Drupal rebuild, clean up content, remove unused fields and confirm the database is consistent before migration. In both cases, take a full backup of the database and files, and keep the original Drupal 7 site running unchanged so you have a reference for comparison. Check the target requirements too: Backdrop's system requirements list PHP 7.1 or later and MySQL or MariaDB 5.5.0 or later, while Drupal 11 requires PHP 8.3 or later and supports MariaDB 10.6, MySQL 8.0, PostgreSQL 16 or SQLite 3.45. The output is a tested backup and a documented list of content removed or changed.
Run the upgrade or build the migration
For Backdrop, run update.php on a copy of the site and record every error, skipped module and changed configuration. For Drupal 10 or 11, install the core Migrate, Migrate Drupal and Migrate Drupal UI modules, or use Drush, to create a new site and migrate content, users, files and configuration. Drupal.org documents that Drupal 6 and 7 sites cannot be updated directly to Drupal 10 or later, so the new site is built and populated as a separate project. Rebuild each theme because themes cannot be migrated, and rewrite custom modules against current APIs. The step produces a staging environment and a migration log that lists what moved cleanly and what needs manual work.
Rebuild themes and custom functionality
Themes are rebuilt on both routes that move to a new theme system, and custom modules are reviewed for compatibility with the target version. On Backdrop, check that custom code and theme overrides still behave under its API, which Backdrop aims to keep stable within a major version. On Drupal 10 or 11, rewrite themes and custom modules against current core. Identify contributed modules that need a new release or a replacement, and document any decision to drop a feature. The output is a list of rebuilt components with reviewers and a staging build that renders every template your site uses.
Test content, access and integrations before cutover
Test against the original Drupal 7 site as the reference. Compare content counts, URLs, redirects, user accounts, roles and permissions, forms, search, scheduled content, and every integration, including authentication. If you need single sign-on, confirm the contributed modules you plan to use: the samlauth module lists support for Drupal 10.3 and later and Drupal 11, and the OpenID Connect module offers built-in clients for several providers. Run accessibility, performance and security checks on staging, and have content editors sign off their workflows. The output is a signed test report with every failed case either fixed or accepted by its owner.
Cut over and keep the rollback path
Schedule the cutover with a freeze on content changes, run the final migration or update, and redirect traffic to the new site. Keep the original Drupal 7 site, its database and the backup available until the new site has run in production through a full cycle of normal use. Confirm with your hosting team who runs the cutover, who can execute rollback and what the rollback trigger is. The step is done when production traffic is served by the target platform, the rollback path has been rehearsed, and the Drupal 7 archive is stored under your retention rules.
Plan for a later move between Backdrop and Drupal
Treat any later move between Backdrop and Drupal as a new migration project, not a simple switch. The two platforms share a Drupal 7 origin, but their cores, module ecosystems and release cycles have diverged, so content, configuration and custom code would need to be exported, mapped and tested again. Record this in the decision log at step two, along with the module names and the people who would own the work. Ask any implementation partner to quote the later move separately from the first migration, based on the written scope.
Where Drupal 7 projects usually run long
The biggest overruns in a Drupal 7 exit tend to come from work nobody scoped: custom modules with no Drupal 10 or 11 equivalent, content types and fields that were built around Drupal 7 field and view behavior, and themes that must be rebuilt. On the Drupal route, Drupal.org documents that Drupal 6 and 7 sites are migrated into a new site with the core Migrate, Migrate Drupal and Migrate Drupal UI modules or with Drush, and that themes cannot be migrated. On the Backdrop route, the upgrade ends with update.php on the existing site, but only after you remove content or features Backdrop no longer supports. In both cases, the first risk is the custom code inventory, so count it before anyone estimates a timeline. Backdrop's top 100 Drupal 7 modules page shows 59 modules ready in contrib, 19 included in core and 2 not started, so check every contributed module on your site against that list and against your own dependencies.
Authentication is a frequent source of rework. The contributed samlauth module lets a Drupal site act as a SAML service provider, and its 8.x-3.14 release supports Drupal 10.3 and later and Drupal 11. The OpenID Connect module ships built-in clients for generic OAuth 2.0, GitHub, Google, LinkedIn, Facebook and Okta and creates accounts on first sign-in. Confirm which of these your identity provider needs, whether your Drupal 7 site uses a different login module today, and whether the Backdrop equivalents match your current setup. Editorial retraining and integration testing also tend to be underestimated, because content editors and downstream systems depend on the existing workflows and feeds.
Team skills differ by route. A Drupal 10 or 11 rebuild needs developers comfortable with the modern Drupal architecture, its configuration system and the PHP version each release requires, which is PHP 8.1 or later for Drupal 10, PHP 8.3 or later for Drupal 11 and PHP 8.5 or later for Drupal 12. Backdrop is closer to the Drupal 7 mental model, so a team that knows Drupal 7 can often work on it sooner, but it needs Backdrop-specific knowledge for modules and upgrades. Compare community size as a hiring and support factor: confirm with each vendor and your own developers how many local contractors and maintainers are available for your modules, and who will fix a contributed module that stalls. Before committing to either route, run a scoped audit that inventories modules, content types, fields, themes, integrations and editorial workflows, then ask the vendor to confirm these items in writing.
Questions teams ask before choosing a Drupal 7 route
How much does a Drupal 7 rebuild cost, and what drives the price?
The cost of a rebuild is set by the content, the design work and the integrations, not by the platform license, because Drupal itself has no paid edition and its code is licensed under GPL-2.0-or-later. Drupal.org documentation states that Drupal 6 and 7 sites cannot be updated to Drupal 10 or later, so the work is a new site plus a content migration. The main cost drivers are the number of content types and fields to map, the volume and quality of content to move, the themes that must be rebuilt because they cannot be migrated, and the custom modules or integrations that need new versions. Most of the fee is paid for analysis, build, testing and cutover labor, which is largely one-time. Ongoing hosting, module updates and security work recur. Ask any provider for a quote that separates discovery, theme rebuild, migration scripts, testing, cutover and first-year support, and that states which Drupal major version it targets.
Is an in-place Backdrop upgrade faster than a Drupal rebuild?
Usually the in-place route involves less rebuilding, because Backdrop documents an upgrade from Drupal 7 that ends by running update.php on the existing site after content or features it no longer supports are removed. Backdrop's guide has three stages: research the Drupal 7 site to estimate effort, prepare it by removing unsupported content or features, and run update.php while keeping the original site for comparison. The speed depends on how much of the site depends on Drupal 7 modules that Backdrop has not yet ported. Backdrop's top 100 Drupal 7 modules page counts 59 as ready in contrib, 19 included in core, 2 underway in contrib, 7 with an alternative in contrib, 17 with an alternative in core and 2 not started. Check each module your site uses against that list before estimating anything, and confirm the status of any module that is not on it.
How long does each Drupal 7 route take?
No supplied source gives a reliable duration for either route, so treat any number you hear as a claim to test rather than a planning fact. The timeline is set by the size of the content inventory, the number of custom modules and themes, the count of unsupported modules that need replacement or removal, the number of stakeholders who sign off, and the amount of testing before cutover. A Drupal rebuild also depends on the target version: Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026, so a rebuild that targets Drupal 10 may need a second upgrade soon after launch. Ask each provider to show a dated plan with the Drupal or Backdrop version it targets and the risks it has already listed.
Can our own team do the Drupal 7 work without an outside partner?
A team can do it alone if it has developers who know PHP and Drupal, time to run the migration or update in a staging copy, and the discipline to test before production. The in-place Backdrop route asks less of a team's Drupal depth, but it still requires someone to audit custom code, replace modules and verify the result, and Backdrop's own documentation directs users to a directory of certified upgrade specialists. A rebuild on Drupal 10 or 11 requires skills in the core Migrate, Migrate Drupal and Migrate Drupal UI modules or in Drush, plus theme rebuilding. Be honest about the skills gap before you start. If you engage a partner, the work is usually fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and DeployOpen only offers this kind of implementation on self-hosted platforms inside your own infrastructure.
What does the project need from content owners, developers and approvers?
Every route needs three groups. Content owners must confirm which content types, pages and taxonomy terms still matter, and they must check migrated content against the original. Developers must audit custom modules, rebuild or retire themes, and handle any integration with identity, search or payments. Approvers, usually a business owner and a security or compliance lead, must sign off on what is removed, what changes in the editorial interface and the cutover date. Backdrop's upgrade guide explicitly asks you to remove unsupported content or features before running update.php, so content owners have a decision to make early. For a rebuild, the theme is never migrated, so design sign-off comes later and takes longer. Set these roles and sign-off points in the written scope before work begins.
Is Drupal 7 extended security support a viable bridge?
It can be a short bridge, but it does not solve the underlying problem. Drupal 7 security support ended on January 5, 2025, and drupal.org lists migrating to modern Drupal or buying extended security support from certified vendors HeroDevs and Tag1 Consulting as the options. Extended support is a paid service that keeps a site patched while you plan, so its cost recurs for as long as you use it and the vendor, scope and term should be confirmed directly with it. Ask what it covers, which modules are included, how fixes are delivered to your environment, and what happens at contract end. Any bridge still leaves you on a platform that receives no new upstream development, so it works best as a dated transition with a defined exit route.
Can we move from Backdrop back to Drupal later?
A later move is practical but not free, because the two projects share a Drupal 7 origin but then diverge. Backdrop describes itself as a fork of Drupal 7 that presents itself as the next version of Drupal, and its database and configuration schemas may change in minor releases, so data and configuration are not guaranteed to move without work. Moving to Drupal 10 or 11 would still follow the migration path that Drupal.org documents for Drupal 6 and 7, which means building a new site and migrating content, with themes rebuilt. Plan the first move to preserve clean content exports, document custom modules, and keep configuration in versioned files so that either route stays open. Confirm the exact export and import options in each project's documentation before you commit.
Which Backdrop release cadence should we expect after an upgrade?
Backdrop publishes a new minor release every 4 months, on January 15, May 15 and September 15, and it says no major release is currently planned. Its releases page states that it aims for API compatibility within a major version, covering public function signatures, hooks, front-end markup and Form API element properties, while database and configuration schemas may change in minor releases. In practice, that means each minor update may need a database or configuration check, so schedule updates in a staging environment before production. Backdrop 1.35.2 was published on October 14, 2026, which is the latest version in the supplied facts, so confirm the current release on the Backdrop releases page before planning. Drupal, by contrast, runs bugfix releases on the first Wednesday of each month and security releases on the third Wednesday, so your operations calendar will differ by platform.
How DeployOpen helps choose and carry out a Drupal 7 route
DeployOpen plans, implements, customizes, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, so the Drupal or Backdrop decision can be tested against your real site before any work starts. The route is set in a written scope, then carried out and handed over in your environment.
How we scope
- Inventory of the Drupal 7 site's modules, themes, integrations and content types against the route you are weighing
- Module-by-module check of which contributed or core replacements exist for the Backdrop or Drupal 10 or 11 path
- Written scope stating deliverables, timelines and exclusions before any migration or upgrade work begins
- Identity integration, hosting stack and database requirements confirmed for the chosen platform and version
- Engagements are fixed-scope, so the quote follows from the agreed written scope
How we build
- Migration to Drupal 10 or 11 with core Migrate modules, rebuilding themes rather than assuming they carry over
- Backdrop upgrade run on a copy of the existing site, with unsupported content or features removed first
- Custom modules or integrations built or adapted, with each gap from the module inventory tracked to a decision
- Testing of content, permissions, forms and integrations on a staging environment inside your infrastructure
- Hardening and backup configuration applied before cutover, with the original Drupal 7 site kept for comparison
How we hand over
- Written documentation of the chosen route, configuration, module decisions and any known gaps for your team
- Runbook covering deployment, backup, restore and the update procedure your platform team will follow
- Evidence and control records prepared for your compliance assessment, which independent auditors then assess
- Knowledge transfer sessions with your administrators on the platform you end up running
- Clear list of items your team must confirm with the vendor or in your own environment after handover
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Upgrade planning tied to each platform's release schedule, so future major versions are scoped before they arrive
- Security testing of the live site and its integrations available as a separate engagement
- Retainer scope agreed in writing, covering which releases, modules and environments are included
- Support questions answered against your own environment, with changes documented as they are made
