How I upgraded an aging production server, migrated MySQL 5.7 to 8.0, and kept 17 hosting accounts alive

The Warning That Started Everything

It all started with a warning in my DirectAdmin control panel:

This Linux distribution is no longer supported by DirectAdmin. New releases of DirectAdmin are no longer compatible with this system and will not be available.

My server was still running Debian 10 (Buster).

Everything appeared to be working. Websites were online, email was being delivered, databases were responding, and DirectAdmin itself was running.

But underneath it all, the operating system was outdated.

And an outdated operating system on a production hosting server is not something you want to ignore indefinitely.

+-------------------------------------------+
|           SERVER STATUS: BEFORE           |
+-------------------------------------------+
| OS          : Debian 10 (Buster)          |
| Kernel      : 4.19.0-27-amd64             |
| DirectAdmin : 1.668                       |
| Apache      : 2.4.63                      |
| PHP         : 8.3                         |
| MySQL       : 5.7.44                      |
| Status      : EOL / UNSUPPORTED           |
+-------------------------------------------+
                  |
                  v
          [ TIME TO UPGRADE ]

[PHOTO 1 — DirectAdmin Debian 10 end-of-life warning]

The Challenge: A Production VPS With Real Data

This wasn’t a fresh installation or an empty test server.

It was a KVM virtual private server hosting multiple websites, email accounts, databases, and DNS zones.

The server had been running for years, accumulating configurations, customer data, and software installed through DirectAdmin’s CustomBuild system.

Before touching anything, I made an inventory.

There was a lot to preserve.

                 MY PRODUCTION VPS
              +----------------------+
              |    Debian 10 VPS     |
              +----------------------+
                         |
         +---------------+---------------+
         |               |               |
         v               v               v
   +-----------+   +-----------+   +-----------+
   | WEBSITES  |   |   EMAIL   |   | DATABASES |
   |  8.6 GB   |   | ~15.4 GB  |   |  1.3 GB   |
   +-----------+   +-----------+   +-----------+
         |               |               |
         +---------------+---------------+
                         |
                         v
               [ MUST SURVIVE! ]

Losing a website would be inconvenient. Losing years of customer email or corrupting databases would be considerably worse.

So the most important decision was simple:

No blind upgrades. No unnecessary risks. And one command at a time.

Step 1: Backups, Snapshots, and a Recovery Plan

Before upgrading anything, I made sure I had multiple ways to recover the server.

First, I confirmed that DirectAdmin account backups existed and were stored outside the VPS.

Next, I created a full VPS snapshot through my hosting provider.

I also verified that I could access the VPS using the provider’s recovery console if SSH stopped working.

That last part was especially important because SSH was configured on a nonstandard port.

             BEFORE TOUCHING ANYTHING
             ========================

                  [ LIVE VPS ]
                       |
          +------------+------------+
          |            |            |
          v            v            v
      [SNAPSHOT]   [BACKUPS]    [CONSOLE]
          |            |            |
          v            v            v
      Full disk     Websites      Emergency
      recovery      Databases     access
                    Email
          |            |            |
          +------------+------------+
                       |
                       v
                [ READY TO GO ]

A snapshot is not a replacement for proper backups, but having both provides much better recovery options.

[PHOTO 2 — VPS snapshot in hosting provider’s control panel]

Step 2: Why I Didn’t Upgrade DirectAdmin First

One of the first things I discovered was that DirectAdmin was stuck on version 1.668.

Running the update checker returned:

/usr/local/directadmin/directadmin update --check

Result:

directadmin current v1.668 is already latest

That seemed strange, because a newer DirectAdmin version existed.

The explanation was that Debian 10 had reached its DirectAdmin support cutoff. The update channel was effectively frozen for that operating system.

The available release at the time was DirectAdmin 1.712, but the Debian 10 installation wasn’t offering it through the normal updater.

I inspected a newer DirectAdmin release archive and checked its executable and library requirements, but that alone wasn’t enough to establish official compatibility.

The sensible approach was to upgrade Debian first, then update DirectAdmin once the system was running on a supported distribution.

Step 3: Debian 10 to Debian 11

Skipping directly from Debian 10 to Debian 12 was not an option.

The upgrade needed to happen in stages.

+-------------+       +-------------+       +-------------+
|  DEBIAN 10  | ----> |  DEBIAN 11  | ----> |  DEBIAN 12  |
|   BUSTER    |       |  BULLSEYE   |       |  BOOKWORM   |
+-------------+       +-------------+       +-------------+
   OLD SERVER           FIRST STOP             FINAL GOAL

I started by backing up the APT repository configuration:

cp -a /etc/apt/sources.list /etc/apt/sources.list.pre-bullseye

Then I changed the package repositories to Debian 11.

The upgrade was performed in two stages:

apt-get update
apt-get upgrade --without-new-pkgs
apt-get full-upgrade

Before each real upgrade, I simulated the changes to see which packages would be installed or removed.

The First Surprise: HTTP 404 Errors

During the first attempt, APT couldn’t download several packages.

The errors looked like this:

E: Failed to fetch ...
404 Not Found

E: Unable to fetch some archives

Not exactly what you want to see halfway through a server upgrade.

The solution was to use the archived Debian 11 repositories, which still contained the required package versions.

After updating the repository configuration, the downloads completed successfully.

[PHOTO 3 — Terminal showing the Debian 11 upgrade]

Protecting SSH and DNS

During the upgrade, Debian asked whether to replace my modified SSH configuration.

I chose to keep the existing file.

This was essential because the server used SSH port 2121.

Later, during the Debian 12 upgrade, I made the same choice for the BIND DNS configuration.

My rule was straightforward:

If a configuration file contains custom hosting settings, don’t casually replace it with a package default.

After the Debian 11 upgrade, the server rebooted successfully into kernel 5.10.

All critical services came back online.

Step 4: DirectAdmin Finally Updated

Once Debian 11 was running, something interesting happened.

The DirectAdmin updater could finally see the newer release.

/usr/local/directadmin/directadmin update --check

Result:

directadmin current v1.712 is available

After the update, DirectAdmin reported:

version: 1.712
distro: debian11

That was an important milestone.

The operating system was now supported, DirectAdmin had been updated, and the websites and email services were still running.

But there was another major problem waiting.

Step 5: MySQL 5.7 Was Too Old

The server was still using MySQL 5.7.44.

When I checked the available CustomBuild updates, DirectAdmin reported:

Invalid MySQL release configured,
please change 'mysql' line in options.conf

The newer CustomBuild no longer accepted MySQL 5.7 as a configured installation target.

I needed to upgrade the database server before proceeding to Debian 12.

           MYSQL UPGRADE PATH
           ==================

         +----------------------+
         |    MySQL 5.7.44      |
         |    END OF LIFE       |
         +----------------------+
                    |
                    |
                    v
           [ BACKUP DATABASES ]
                    |
                    v
           [ COMPATIBILITY CHECK ]
                    |
                    v
         +----------------------+
         |    MySQL 8.0.46      |
         |    NEW DATABASE      |
         +----------------------+
                    |
                    v
            [ VERIFY ALL DATA ]

Checking the Databases

Before upgrading, I inspected the database storage engines.

The result surprised me.

There were significantly more MyISAM tables than InnoDB tables.

Fortunately, MySQL 8.0 still supports MyISAM for user tables, so I didn’t have to convert everything just to perform the upgrade.

I also checked database integrity, authentication plugins, triggers, stored procedures, and potentially incompatible table names.

One interesting finding was Roundcube’s system table.

Because SYSTEM is a reserved keyword in MySQL 8.0, I checked its structure. The table itself was valid and didn’t need to be renamed.

The database checks were encouraging, although no collection of manual checks can guarantee every application will be compatible.

Step 6: Upgrading MySQL to 8.0

After creating fresh SQL backups and another VPS snapshot, I changed the CustomBuild target version:

/usr/local/directadmin/custombuild/build set mysql 8.0

CustomBuild confirmed that MySQL 8.0.46 was available.

Then came the actual upgrade:

/usr/local/directadmin/custombuild/build mysql

CustomBuild dumped the databases, downloaded the MySQL 8.0 binaries, stopped the old server, installed the new version, and restarted MySQL.

The terminal eventually displayed:

Restarting MySQL.
Installation completed.

The moment of truth:

SELECT VERSION();

Result:

+-----------+
| VERSION() |
+-----------+
| 8.0.46    |
+-----------+

Success!

I then verified that all 38 databases were still present.

The 53 existing MySQL accounts were also retained, with one additional account using the newer caching_sha2_password authentication plugin.

PHP applications continued connecting through mysqli, mysqlnd, and pdo_mysql.

[PHOTO 4 — MySQL 8.0 version confirmation]

Step 7: Debian 11 to Debian 12

With DirectAdmin updated and MySQL running on version 8.0, I could finally move to Debian 12.

The process was similar to the first operating-system upgrade.

I backed up the APT source configuration, changed the repositories to Bookworm, downloaded the packages, and performed a staged upgrade.

apt-get update
apt-get upgrade --without-new-pkgs
apt-get full-upgrade

The final upgrade involved hundreds of packages, a newer version of glibc, and Linux kernel 6.1.

Once again, I preserved the custom SSH and BIND configurations when prompted.

After the upgrade completed, I rebooted the VPS.

Then I checked the kernel:

uname -r

Result:

6.1.0-54-amd64

Debian 12 was running!

And the most important part?

The hosting services came back online.

Step 8: Verifying the Server

After the final reboot, I checked the important services:

systemctl is-active directadmin httpd php-fpm83 mysqld exim dovecot ssh named

All eight returned:

active

I also checked for failed systemd units:

systemctl --failed --no-pager

Result:

0 loaded units listed.

Finally, DirectAdmin reported:

version: 1.712
distro: debian12
eol: 2028-09-01

The original Debian 10 end-of-life problem was resolved.

+------------------------------------------------+
|              SERVER STATUS: AFTER              |
+------------------------------------------------+
| Operating System : Debian 12 (Bookworm)        |
| Linux Kernel     : 6.1.0-54-amd64              |
| DirectAdmin      : 1.712                       |
| PHP              : 8.3                         |
| MySQL            : 8.0.46                      |
| Apache           : ACTIVE                      |
| Exim / Dovecot   : ACTIVE                      |
| BIND DNS         : ACTIVE                      |
| SSH              : ACTIVE                      |
| Failed Services  : 0                           |
+------------------------------------------------+
|                                                |
|               UPGRADE COMPLETE                 |
|                                                |
+------------------------------------------------+

[PHOTO 5 — DirectAdmin running on Debian 12]

Step 9: Cleaning Up the Old System

After upgrading through two Debian releases, the server still contained older packages, libraries, downloaded installation archives, and kernel images.

The first cleanup was the APT cache:

apt-get clean

That cleared approximately 632 MB of cached installation packages.

I also reviewed the automatically removable packages and checked which kernels remained installed.

Eventually, the installed kernel packages were reduced to:

linux-image-5.10.0-46-amd64
linux-image-6.1.0-54-amd64
linux-image-amd64

I kept the Debian 11 kernel temporarily as a fallback.

The disk usage at the end was:

Filesystem      Size  Used  Avail  Use%
/dev/vda1       146G   66G    73G   48%

At one point during the upgrade, disk usage had reached approximately 83 GB.

By the time cleanup was underway, usage had fallen to 66 GB.

That was a welcome improvement, although not all of the reduction can be attributed to any single cleanup action.

[PHOTO 6 — Final disk usage and system information]

What I Learned

This upgrade reinforced a few important lessons.

1. Backups are essential, but recovery options are just as important.

A VPS snapshot, external backups, and console access provide different forms of protection. Having all three made the process much less risky.

2. Upgrade operating systems sequentially.

Going from Debian 10 to 12 meant passing through Debian 11 first.

3. Hosting control panels have their own compatibility requirements.

DirectAdmin wasn’t just another Debian package. Its release availability depended on the operating system.

4. Database upgrades deserve special attention.

MySQL 5.7 to 8.0 was a major change. Backups, compatibility checks, and post-upgrade verification were essential.

5. Keep custom configuration files when appropriate.

Preserving the SSH configuration prevented the custom port from being overwritten. Preserving the BIND configuration protected the existing DNS setup.

6. Never blindly remove old packages.

Even packages marked as automatically removable can be useful to software installed outside Debian’s package manager.

7. One command at a time is a perfectly valid strategy.

It may be slower than running a giant upgrade script, but it gives you the opportunity to inspect unexpected results and respond before they become bigger problems.

The Final Result

       THE JOURNEY

  DEBIAN 10
  DirectAdmin 1.668
  MySQL 5.7
       |
       | OS upgrade
       v
  DEBIAN 11
       |
       | DirectAdmin update
       v
  DirectAdmin 1.712
       |
       | Database upgrade
       v
  MySQL 8.0
       |
       | OS upgrade
       v
  DEBIAN 12
  Kernel 6.1
       |
       v
  +----------------------+
  |  WEBSITES: WORKING   |
  |  DATABASES: PRESENT  |
  |  SERVICES: ACTIVE    |
  |  DIRECTADMIN: LATEST |
  +----------------------+
       |
       v
      DONE!

What started as a simple warning in DirectAdmin turned into a full operating-system, control-panel, and database upgrade.

The existing VPS was retained. All 38 databases were accounted for, the critical hosting services restarted successfully, and PHP database-backed websites were working afterward.

The process wasn’t entirely smooth. There were outdated repositories, missing packages, configuration prompts, and database compatibility questions along the way.

But taking it one command at a time made those issues manageable.

The biggest takeaway?

Don’t wait until an old server becomes impossible to maintain. Plan your upgrade, preserve your data, and always have a way back.

And perhaps most importantly:

+------------------------------------+
|                                    |
|  BACKUP FIRST.                     |
|  UPGRADE SECOND.                   |
|  VERIFY EVERYTHING.                |
|                                    |
+------------------------------------+

Note: This article documents my experience with one specific DirectAdmin VPS in October 2026. It is not a universal upgrade script. Always check the official Debian, DirectAdmin, and MySQL documentation before upgrading a production server.