Definition
What does modernizing Drupal 7 mean?
Modernization for Drupal 7 is the move from a PHP site that no longer receives vendor fixes to a platform that does, without losing the content, users, forms and integrations that took years to build.
In practice it is three projects at once: build the new system, keep the old one running, and make the switch between them reversible.
Most modernization guidance covers the first project. Jestr covers the other two. A live replica of the legacy Drupal 7 site is a clean, current reference to build against, a fallback that visitors can be switched to in seconds if the new platform fails, and a way to keep an unsupported site running without leaving it exposed on the internet.
Why now
Why Drupal 7 modernization stopped being optional on January 5, 2025
Drupal 7 to Drupal 10 is one of the hardest migrations in web content management, which is why so many sites never made the jump before January 5, 2025. The content model moves cleanly. The theme, the custom modules and years of accumulated configuration do not. Migrations run long, and the old site stays exposed the whole time.
The facts driving the decision for Drupal 7 today:
- Drupal 7 reached end of life on January 5, 2025, after several extensions of the original date.
- The Drupal security team no longer publishes advisories or fixes for Drupal 7 core or contributed modules. Paid extended support exists from a small number of vendors.
- Drupal 8 reached end of life in November 2021, so 8 is not a stopping point either. Drupal 10 and 11 are the supported line.
- Drupal 7 to 10 is a migration, not an upgrade: the theme layer, the module ecosystem and much of the site-building approach changed completely.
Migration risks
The risks of a rip-and-replace Drupal 7 migration
The classic modernization plan is a big-bang cutover: build the new site, freeze the old one, migrate the data over a weekend, switch the DNS, and hope. It fails in predictable ways.
- The migration runs long. Content models, URL structures, media libraries and user roles never map cleanly. The legacy site stays in production, exposed and under-maintained, for months longer than planned.
- The cutover is one-way. Once visitors are on the new platform and new data are flowing, going back means losing them. Teams push through launch-day failures they should have rolled back from.
- The reference disappears. The legacy site is frozen or decommissioned to save cost, and the next question about how a template used to behave has no answer.
- SEO and visitors trust take the hit. URL changes, missing redirects and a slow new site cost rankings that took years to earn.
- The legacy site gets breached mid-migration. An unpatched, half-forgotten production system is the softest target in the estate, and a compromise during the program can stop it cold.
The replica
How the Jestr replica de-risks a Drupal 7 migration
The replica does not build the new platform. It makes the migration survivable.
A clean reference the rebuild can trust
The replica is a current, working copy of the legacy Drupal 7 site, isolated from the change and churn of production. Developers and QA compare behavior against it, test data migrations against it and answer "how did this work before?" without touching production.
A cutover you can reverse in seconds
Launch the new platform with the replica standing by. If checkout, logins or integrations fail on day one, visitors switch back to the replica while the team fixes the problem. Changes made on the replica are reconciled afterwards. The launch stops being a bet.
Run past end of life without running exposed
Drupal 7 will not receive another vendor fix. The replica lets you shrink what is exposed: restrict or retire the internet-facing primary early and keep the isolated replica as the working copy while the migration finishes, however long it takes.
Retire the old infrastructure earlier
With the replica as the safety net, the legacy hosting, servers and contracts can be wound down on a schedule the finance team likes rather than after a year of "just in case".
How it works
How the replica fits a Drupal 7 modernization program
Jestr does not re-implement Drupal 7. It runs a copy of your actual site, kept current and kept apart, for as long as the program needs it.
Jestr builds a live copy of the legacy Drupal 7 site
Jestr replicates the site as it actually runs: application, data and configuration at the exact PHP version and dependencies the primary uses. Nothing is re-implemented, so the replica behaves like the site the business knows.
The copy stays current and isolated while you build
The replica follows the primary continuously at a known-good state. It runs on Jestr's side with no shared credentials, network or identity, so it is both a faithful reference and a safe one.
At cutover, the replica stands by
Visitors move to the new platform. If it fails, one action moves them back to the replica. Changes made there are captured and reconciled when the new platform is stable.
After cutover, the replica is the legacy system
The exposed primary can be decommissioned. The replica stays as the working reference and fallback for as long as the program needs it, then it is retired too.
What the replica preserves from Drupal 7
- Nodes, taxonomies, files, views and the theme, so visitors and editors see the same site on the replica.
- Forms, logins and the roles around them, so the site keeps functioning.
- The Drupal 7 runtime and module set kept current and isolated from the internet-facing primary.
- Separation from the primary's hosting credentials and network.
Destinations
Where Drupal 7 sites usually go
The destination depends on how much of the business lives in Drupal 7 customizations. Common paths from Drupal 7:
- Drupal 10 or 11 using the Migrate API, with the theme and custom modules rebuilt.
- Backdrop CMS, the Drupal 7 fork, for sites that want the smallest change.
- WordPress or a headless CMS for sites that no longer need Drupal's structure.
Side by side
Rip and replace vs a parallel Drupal 7 replica
The same migration, run two ways.
| Dimension | Rip and replace | Live Jestr replica |
|---|---|---|
| Legacy system during the migration | Exposed in production, under-maintained, single copy | Primary can be restricted early; the isolated replica is the working copy |
| Cutover | One-way; rolling back loses data | Reversible in seconds; changes on the replica are reconciled |
| Reference for the rebuild | Production, which keeps changing, or a stale staging copy | A current, isolated, working copy of the legacy site |
| Running past end of life | Every new vulnerability is permanent and the only copy is exposed | Exposure shrinks to what is strictly needed; the replica carries the rest |
| Timeline pressure | Every delay extends the exposed window | Delays are safe; the migration finishes when it is right |
| Decommissioning | Kept running for months as insurance | Retired on schedule; the replica is the insurance |
FAQ
Frequently asked questions
Can we keep running Drupal 7 after end of life?
Yes, and most teams will. The safe way is to reduce exposure rather than pretend the software is patched: keep the Jestr replica live and isolated so a compromise of the primary is contained, restrict the primary to what strictly needs it, and use the replica as the fallback at every migration milestone.
What happens if the new platform fails at cutover?
Visitors are switched back to the replica in seconds. It is current and running, so there is no restore. Changes made on the replica while the team fixes the new platform are captured and reconciled afterwards. Launch day becomes something you can retry.
How does the replica stay current during a long migration?
It follows the primary continuously at a known-good state, so content, media, users and configuration stay in sync until the day you freeze them for the final data migration. At that point the replica is the frozen reference the migration is validated against.
Does the replica preserve our Drupal 7 customizations and content history?
Yes. The replica is a copy of the site as it runs, including extensions, custom code, configuration and data. It is not a re-implementation, so nothing has to be ported to it.
When can we retire the replica?
When the new platform has run long enough that nobody would switch back, and the legacy site is no longer needed as a reference. Many teams keep it through the first full business cycle on the new platform and retire it after.