How I Fixed a 15-Year-Old WordPress Blog After Migrating to PHP 8.2

I recently migrated a 15-year-old WordPress blog to a new server. The old server was running PHP 5.6. The site itself had not been updated for more than 12 years. That combination worked fine on the old setup. It completely broke on the new one.

Right after migration, the site showed a simple message:

HTTP ERROR 500

No details. No clues. Just a blank failure.

Here is how I diagnosed the issue step by step and brought the site back to life on PHP 8.2.

Step 1: Turn on error reporting

A 500 error tells you nothing. The first goal was to expose the real problem.

I edited the wp-config.php file and enabled debugging:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', true);

This immediately changed everything. Instead of a blank page, I started seeing actual PHP errors.

That is the turning point in any broken WordPress migration.

Step 2: Database connection failure

The first major error was not even about PHP compatibility. It was a database issue.

The error looked like this:

php_network_getaddresses: getaddrinfo failed
Error establishing a database connection

The site was trying to connect to an old AWS RDS endpoint. That endpoint was no longer accessible from the new server.

Fix

I updated the database host in wp-config.php:

define('DB_HOST', 'localhost');

Then I imported the database into the new hosting environment and updated:

define('DB_NAME', 'new_db');
define('DB_USER', 'new_user');
define('DB_PASSWORD', 'new_password');

Once the database connected, the site moved past the connection error.

Step 3: Fatal error from outdated plugins

After fixing the database, I hit the next blocker:

Fatal error: Call to undefined function create_function()

This came from an old plugin: related-posts-thumbnails.

Why this happened

The function create_function() was removed in PHP 8.0. Any plugin using it will crash immediately.

Fix

I disabled the plugin via FTP:

/wp-content/plugins/related-posts-thumbnails
→ related-posts-thumbnails-disabled

The site moved forward again.

Step 4: Another fatal error

Next error:

Cannot redeclare get_options()

This came from another outdated plugin: wp-subscriber-form.

Cause

The plugin declared a function that already existed in WordPress core. Older PHP versions allowed this loosely. PHP 8 does not.

Fix

Again, I disabled the plugin:

/wp-content/plugins/wp-subscriber-form
→ wp-subscriber-form-disabled

This removed the fatal error.

Step 5: Cleaning legacy files

Even after removing plugins, I kept seeing warnings:

Only variables should be assigned by reference

These came from two files:

/wp-content/db.php
/wp-content/object-cache.php

These are old “drop-in” files used by legacy caching or database layers.

Fix

I renamed both:

db.php → db_old.php
object-cache.php → object-cache_old.php

These files are not required for WordPress to function. Removing them cleared the warnings.

Step 6: More plugin issues

Next, I saw warnings from:

• subscribe-to-comments plugin
• old SEO plugin

Errors included:

_load_textdomain_just_in_time was called incorrectly

and

Using ${var} in strings is deprecated

Fix

I removed outdated plugins completely and replaced them with modern versions.

For example:

• Removed old SEO plugin
• Installed latest version again

This is much faster than patching old code.

Step 7: Theme-level deprecated code

Another warning appeared:

WP_Dependencies->add_data() deprecated

This usually comes from themes using old Internet Explorer conditional logic.

Fix

I searched the theme files for:

$wp_styles->add_data

and removed those lines.

Modern browsers do not need IE-specific conditions.

Step 8: Disable all plugins and rebuild clean

At this stage, I decided not to fight plugin issues one by one.

Instead, I reset everything.

Action

I disabled all plugins:

/wp-content/plugins → plugins_disabled

Then I confirmed:

• Frontend loads
• Admin panel works

After that, I re-enabled plugins one by one.

Rule I followed

• If plugin is outdated → delete
• If maintained → keep
• If unsure → replace

This avoided future issues.

Step 9: Update WordPress core

The site was running a very old version of WordPress.

I updated it step by step until I reached the latest version.

This ensured compatibility with PHP 8.2.

Step 10: Final cleanup

Once everything worked:

Disabled debug mode

define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);

Security steps

• Changed all passwords
• Removed unused themes
• Removed unused plugins

Performance improvements

• Installed caching plugin
• Optimized images
• Enabled compression

What actually caused the problem

This was not a single issue.

It was a combination of:

• 12-year-old WordPress core
• Outdated plugins
• Deprecated PHP functions
• Legacy database configuration
• Old caching files

The migration exposed all of them at once.

Key lessons from this migration

1. Always enable debug first

Without debug logs, you are guessing. With logs, you are solving.

2. Do not try to “fix” old plugins

Replacing is faster than repairing.

3. PHP upgrades break old code aggressively

Jumping from PHP 5.6 to 8.2 skips multiple breaking changes.

Expect failures.

4. Disable everything, then rebuild

This approach saves hours of debugging.

5. Keep WordPress updated regularly

The real issue was not the migration. It was 12 years of no updates.

Final result

After all fixes:

• Site runs on PHP 8.2
• No fatal errors
• No database issues
• Clean plugin stack
• Updated WordPress core

The blog is now stable, faster, and secure.

Closing thought

This migration looked like a simple server move. It turned into a full system recovery.

But the process is predictable:

1. Fix database
2. Remove fatal plugin errors
3. Clean legacy files
4. Update core
5. Rebuild plugins

Follow this order and even a 15-year-old WordPress site can run smoothly on modern PHP.

If you maintain old WordPress projects, do not wait this long again. Small updates over time are easier than one massive recovery.