DEV Community: Panagiotis Papoutsis

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

Panagiotis Papoutsis — Sat, 31 Oct 2026 17:19:19 +0000

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:

Features the business really uses (contact form, booking enquiry, product catalogue, multilingual content).
Things nobody uses (old modules, abandoned blog, test pages).
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.

A Technical SEO Checklist for Small Multilingual Business Websites

Panagiotis Papoutsis — Sat, 31 Oct 2026 16:38:42 +0000

Most of my work is building small-business websites in Tinos, Greece: guesthouses, local shops, professionals and seasonal tourism businesses. These sites are small, often a handful of pages, but they're almost always multilingual, because the visitors are Greek, German, French, Italian and more.

Small multilingual sites have a specific set of technical SEO problems. None of them are hard, but they are easy to get wrong. Here's the checklist I go through before launch.

1. One protocol, one host, one URL per page

Pick a single canonical origin (for example https://example.gr) and 301-redirect everything else to it:

http://example.gr → https://example.gr
http://www.example.gr → https://example.gr
https://www.example.gr → https://example.gr

Test all four variants with curl -I. A surprisingly common failure is that the HTTPS version works perfectly while plain HTTP returns an error, often because a CDN or proxy in front of the server isn't configured to redirect. Old links, printed flyers and some crawlers still hit http://.

Then add a self-referencing canonical on every page:

<link rel="canonical" href="https://example.gr/en/">

Also watch for duplicate entry points such as /index.php returning 200 instead of redirecting to /.

2. Use language subfolders and real hreflang

For small sites, subfolders (/, /en/, /de/, /fr/) are the simplest structure: one domain, one hosting setup, shared authority.

Every language version should list all alternates, including itself, plus an x-default:

<link rel="alternate" hreflang="el" href="https://example.gr/">
<link rel="alternate" hreflang="en" href="https://example.gr/en/">
<link rel="alternate" hreflang="de" href="https://example.gr/de/">
<link rel="alternate" hreflang="x-default" href="https://example.gr/">

Common mistakes:

Alternates that aren't reciprocal (EN points to DE but DE doesn't point back).
Wrong codes (gr is a country, the language is el).
Machine-translated pages with untranslated titles and meta descriptions.
Setting <html lang> incorrectly. Each version needs its own lang="el", lang="en" and so on.

3. Put hreflang in the sitemap too

It's optional if the tags are in the HTML, but adding them to the sitemap makes the relationships explicit:

<url>
  <loc>https://example.gr/en/</loc>
  <xhtml:link rel="alternate" hreflang="el" href="https://example.gr/"/>
  <xhtml:link rel="alternate" hreflang="en" href="https://example.gr/en/"/>
</url>

Reference the sitemap in robots.txt and submit it in Google Search Console and Bing Webmaster Tools.

4. Don't stop at a one-page site

A single long landing page is fine at launch, but it can only rank for so much. If you offer distinct services, give each one its own URL with its own title, H1 and meta description:

/services/web-design/
/services/local-seo/
/services/hosting/

Anchor links (/#services) are great for navigation, but search engines index URLs, not page sections. Separate pages also give you something specific to link to when you write articles or build profiles elsewhere.

5. Get LocalBusiness schema right

For a local business, JSON-LD structured data helps search engines connect your website with your physical presence:

{
  "@context": "https://schema.org",
  "@type": "ProfessionalService",
  "name": "Example Studio",
  "url": "https://example.gr/",
  "telephone": "+30...",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "Tinos",
    "addressCountry": "GR"
  },
  "sameAs": [
    "https://www.facebook.com/...",
    "https://github.com/..."
  ]
}

Tips:

Use one primary business entity rather than several overlapping ones, and give it an @id so other blocks can reference it.
Fill sameAs with your real profiles. An empty array is a missed opportunity.
Only mark up reviews that are genuinely about the entity you're marking up. Testimonials about something else, or reviews collected and displayed on your own site about yourself, are a common reason review rich results get ignored or flagged.
Validate with the Rich Results Test and the Schema.org validator.

6. Write titles and descriptions per language, per page

Titles should be written for humans in each language, not translated word for word. Keep the brand at the end, keep the separator consistent, and make sure the title tag matches your og:title closely enough that shares look intentional.

7. Treat mobile performance as a feature

Small business sites are usually built on themes that load several icon fonts, multiple Google Font families, carousels and animation libraries, often for features the page barely uses. Before launch:

Load only the font families and weights you actually use.
Drop unused CSS and JS bundles.
Serve images in modern formats at the displayed size, with width/height set and loading="lazy" below the fold.
Check server response time. A slow TTFB on shared hosting hurts every page.

Test with PageSpeed Insights on a mobile profile, and also on a real phone over mobile data.

8. Make the business verifiable off-site

Technical SEO doesn't end on your domain. For local businesses, the most valuable step is usually a verified Google Business Profile with the same name, phone and address as the website, plus Bing Places and the main local directories. Consistent NAP (name, address, phone) data across the web is one of the clearest local signals you can send.

Wrapping up

None of this is advanced, but together it's the difference between a site that quietly sits there and one that search engines can understand, trust and show to the right people in the right language. If you want to see how I approach this for local businesses in the Cyclades, my site is a good place to start.

About the author

Panagiotis Papoutsis is a full-stack web developer (PHP, Drupal, Magento, custom builds) with 10+ years of experience and a focus on SEO and web analytics. He runs Tinos Web, building websites and local SEO for small businesses in Tinos and the Cyclades. More at tinosweb.gr.