Still Running Drupal 7 or Magento 1? A Practical Survival and Migration Plan

Drupal 7 reached end of life in January 2025. Magento 1 got there back in June 2020. And yet, if you do client work for small businesses, you will keep running into both: a hotel site built a decade ago, a little shop that "still works", a cultural association whose original developer moved on years ago.

A lot of my time goes into maintaining websites for small businesses in the Cyclades, and "please look at our old site" is one of the most common requests I get. The owner usually wants two things at once: don't break anything and make it safe. Here's the plan I follow. It's deliberately boring, because boring is what you want when the codebase is older than some of your dependencies.

Step 0: Don't touch production. Get a copy.

Before any upgrade discussion, get a full, reproducible copy of the site running locally or on a staging subdomain.

# Files (exclude caches to keep the archive small)
tar --exclude='sites/default/files/css' --exclude='sites/default/files/js' \
    -czf site-files-$(date +%F).tar.gz public_html/

# Database
mysqldump --single-transaction --routines --triggers \
    -u dbuser -p dbname | gzip > db-$(date +%F).sql.gz

On cheap shared hosting you may not have SSH. In that case the control panel's backup tool plus phpMyAdmin export will do, but check the dump actually restores. A backup you've never restored is just a hope.

Keep at least one copy off the server. When an old site gets compromised, the backups on the same account often go with it.

Step 1: Audit what's actually there

Old sites accumulate modules, extensions and "temporary" fixes. Before planning anything, list them.

For Drupal 7 with drush available:

drush pm-list --type=module --status=enabled --no-core
drush up --security-only -n    # what security updates were never applied?
drush core-status

For Magento 1, look at app/etc/modules/*.xml for enabled modules and at app/code/local and app/code/community for custom and third-party code. Also check app/design/frontend/ for theme overrides; that's where most "small changes" from past years live.

Write down three lists:

1. Features the business really uses (contact form, booking enquiry, product catalogue, multilingual content).
2. Things nobody uses (old modules, abandoned blog, test pages).
3. Custom code that will need rewriting rather than migrating.

The second list is usually long, and it's good news: everything on it is something you don't have to migrate.

Step 2: Harden it while you plan

Migration takes weeks. The site needs to survive in the meantime.

PHP version. Many of these sites run on whatever PHP the host gave them in 2015. Check what your codebase supports and move to the newest version that works on staging first. Running an unsupported PHP version on top of an unsupported CMS doubles the risk.

Lock down sensitive paths in .htaccess (Apache):

# Block Drupal 7 install/update scripts and the core text files that reveal
# the version (robots.txt stays reachable). Unblock update.php while updating.
<FilesMatch "^(install|update|cron|xmlrpc)\.php$|^(CHANGELOG|COPYRIGHT|INSTALL.*|LICENSE|MAINTAINERS|README|UPGRADE)\.txt$">
  Require all denied
</FilesMatch>

# Basic security headers
<IfModule mod_headers.c>
  Header always set X-Content-Type-Options "nosniff"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

If you block cron.php, run cron from the server's crontab with drush instead. For Magento 1, make sure app/etc/local.xml is not publicly readable and the admin URL isn't the default /admin.

Reduce the attack surface. Disable unused modules, delete unused admin accounts, force strong passwords, and remove any phpinfo.php or test.php files left by previous developers. You'll be surprised how often they're there.

Consider extended support or a maintained fork. For Drupal 7 there are commercial extended-support vendors listed on drupal.org; for Magento 1, the community-maintained OpenMage LTS project keeps patching the codebase. These buy time, not a future.

Step 3: Pick the destination honestly

Not every old site deserves a like-for-like migration.

• Content-heavy Drupal 7 site with real structure (content types, taxonomies, multilingual): migrate to current Drupal using the core Migrate API (migrate_drupal, plus the contrib migrate_upgrade and migrate_plus modules). Content and users usually move well; custom modules and themes get rebuilt.
• Magento 1 shop with a small catalogue: a full Adobe Commerce / Magento Open Source 2 project can be overkill for a business selling a few dozen products. Evaluate lighter options honestly.
• Brochure site with five pages and a contact form: often the right answer is a fresh, lightweight build. You copy the content, set up redirects, and you're done in a fraction of the time.

On Drupal, the migration itself looks like this once the source database is connected:

drush migrate:upgrade --legacy-db-key=drupal7 --configure-only
drush migrate:status
drush migrate:import --group=migrate_drupal_7

Run it, check, roll back, adjust, repeat. Expect several passes.

Step 4: Protect the SEO you already have

An old site often has years of backlinks and indexed URLs. Losing them is the most common migration regret.

Export the URL list from the old sitemap or crawl it, then map every old URL to a new one:

RewriteEngine On
RewriteRule ^node/42$ /en/rooms [R=301,L]
RewriteRule ^catalog/product/view/id/(\d+)$ /products [R=301,L]

Keep titles and meta descriptions for pages that rank, check hreflang on multilingual sites, and submit the new sitemap in Google Search Console and Bing Webmaster Tools on launch day.

Step 5: Leave it maintainable

The reason the site got stuck on Drupal 7 or Magento 1 in the first place is usually that nobody owned updates. Before handing over:

• Use Composer for the new codebase and commit composer.lock.
• Automate backups (files and database), stored off-server.
• Write a one-page README: where it's hosted, how to deploy, how to restore.
• Agree who applies security updates, and how often.

Wrapping up

Legacy CMS work isn't glamorous, but for small businesses it's often the most valuable thing a developer can do: their site keeps working, gets safer, and ends up on a platform someone can maintain for the next ten years. If you're dealing with something similar for a local business in Greece, you'll find more about how I work at tinosweb.gr.

---

About the author

Panagiotis Papoutsis is a full-stack web developer with 10+ years of experience in PHP, Drupal, Magento and custom builds, plus SEO and web analytics. Based in Tinos, Greece, he runs Tinos Web, building and maintaining websites for small businesses and tourism brands across the Cyclades. More at tinosweb.gr.