DirectAdmin Legacy License ends July 2026: what's changing, the MariaDB 10.6 EOL trap, and your migration options

If you still run a DirectAdmin Legacy license, July 2026 is the point where "we will deal with it later" stops being a serious plan. The real problem is not the license label by itself. It is that MariaDB 10.6 reaches end of life on July 6, 2026, while Legacy environments are effectively blocked from moving to MariaDB 10.11 and newer through the normal CustomBuild path. For many production hosting environments, that makes Legacy operationally end-of-life even if the panel binary itself still runs.

This matters most if you sell hosting, run reseller infrastructure, host multiple customer sites, or keep an older DirectAdmin server alive because it has been stable for years. Stable is not the same as supportable. Once your supported database path ends, you no longer have a routine maintenance issue. You have a migration decision.

What is actually changing

DirectAdmin stopped selling legacy licenses in 2023. That was the commercial change. The 2026 issue is the technical wall that follows from it.

DirectAdmin's own licensing documentation says Legacy continues with limited maintenance and that you should not assume changelog items exist in the Legacy codebase. The newer license documentation also lists current platform support and newer MariaDB branches as part of the current model. In practice, that means Legacy is not just an old billing tier. It is a frozen lane with shrinking upgrade options.

The forum discussion from late 2025 made the operational consequence explicit: Legacy should now be treated as effectively hard EOL, MariaDB 10.11 and newer will not be made available on Legacy via CustomBuild, and more technical walls are expected over time. Whether you agree with DirectAdmin's product strategy is irrelevant. The practical result is clear enough.

The MariaDB 10.6 EOL trap

This is the part people underestimate. Many older DirectAdmin servers were left on MariaDB 10.6 because it was the last realistic CustomBuild-managed branch available to Legacy. That looked manageable while 10.6 was still within support. It stops looking manageable on July 6, 2026.

After that date, the question is not whether your server will immediately stop booting. It will not. The question is whether you want websites, mail services, billing tools, and customer databases sitting on a panel stack where the normal supported database path has ended. For hobby use, some people will accept that risk. For commercial hosting, most should not.

This is also why calling it a routine update is misleading. It is not. You are dealing with a platform change involving licensing, database versioning, application compatibility, backups, rollback planning, and often an OS decision at the same time. If that distinction is fuzzy in your team, read Server Update vs. Upgrade: What's the Difference and Why It Matters before you touch a production box.

Who is affected first

• Hosting providers still running customer accounts on DirectAdmin Legacy servers
• Agencies that inherited old reseller or VPS environments and never rebuilt them
• Server owners with older DirectAdmin stacks that rely on CustomBuild for database lifecycle management
• Operators who need supported software for compliance, security policy, or client contracts

If you only have one small low-risk site and could move it to standard managed hosting tomorrow, this is annoying but not catastrophic. If you run dozens or hundreds of sites, customer mail, or reseller accounts on the same stack, this is a real migration project and you should treat it like one now.

How to confirm whether a server is in the danger zone

You do not need a week-long audit to identify the obvious cases. Start with the current database version and the CustomBuild settings.

grep -E '^(mysql_inst|mysql|mariadb)=' /usr/local/directadmin/custombuild/options.conf
mysql --version
/usr/local/directadmin/custombuild/build versions | grep -i -E 'mariadb|mysql|directadmin'

If that system is pinned to MariaDB 10.6 and is expected to remain in production beyond July 2026, it needs a decision, not another reminder ticket. If it is also tied to an older OS, custom PHP builds, hand-edited service configs, or fragile mail routing, your real issue is broader than MariaDB.

Your migration options

Option 1: Move to a current DirectAdmin license and keep the panel

This is the cleanest option if you still want DirectAdmin, your staff already knows it, and your customers depend on that workflow. You preserve the panel, keep the general operating model, and stop building future risk around a dead licensing lane.

This makes sense when the panel itself is not the problem. The problem is that you stayed on Legacy too long. If your environment is otherwise healthy, relicensing and planning a controlled database and stack upgrade is usually cheaper than trying to engineer around Legacy restrictions forever.

Who should avoid this option: anyone using Legacy as an excuse to avoid fixing a much older problem. If the OS is outdated, the stack is messy, and the server has years of undocumented changes, paying for a new license alone does not solve the underlying risk.

Option 2: Rebuild on a fresh server and migrate accounts deliberately

If the box is old, the OS is drifting out of support, the PHP matrix is ugly, or the server has too many unknown manual edits, a fresh target server is usually safer than forcing an in-place rescue. This is the right option for providers who want a supported DirectAdmin environment without dragging a decade of residue into the next cycle.

A rebuild also gives you cleaner rollback. You can stage backups, restore test accounts, validate mail flow, compare database behavior, and move accounts in batches instead of gambling everything on one maintenance window. That is slower up front, but it is usually how you avoid the expensive outage.

Option 3: Move simple workloads to managed web hosting

Not every legacy workload deserves another VPS. If part of your footprint is just small business sites, brochure sites, basic WordPress installs, or low-complexity customer projects, moving those to ServerSpan Web Hosting can be the lowest-risk exit. You remove the panel maintenance burden, stop carrying the database lifecycle yourself, and simplify the estate before handling the more complex accounts.

This is especially sensible if the customer does not need root access, custom daemon work, unusual mail routing, or full reseller-style control. Shared or managed web hosting is enough for many sites. Pretending every small website needs its own inherited control panel server is how hosting stacks become wasteful and brittle.

Option 4: Replatform the infrastructure instead of only fixing the panel problem

If you run multiple nodes, mixed virtualization, or several aging service VMs around the hosting stack, this may be the right time to replatform properly rather than only buying a new DirectAdmin license. Consolidation, cleaner VM boundaries, backup redesign, and staged cutovers often make more sense than preserving a pile of historical decisions.

That is where ServerSpan Proxmox Management becomes relevant. It is not a control-panel substitute. It is a fit for providers who need help planning and operating the virtualization layer that the migration runs on. If your real challenge is cluster hygiene, VM placement, snapshots, backups, and controlled movement of service nodes, solve that layer properly instead of treating the DirectAdmin license as the only variable.

What not to do

• Do not assume you can leave MariaDB 10.6 in place indefinitely just because the server still works.
• Do not treat this as a one-command update if you host customer workloads.
• Do not upgrade blind without restore testing, application checks, and mail verification.
• Do not spend money on a new license if the smarter move is to retire the whole server class.
• Do not keep complex customer estates on an obsolete stack just because migration is inconvenient.

Which option fits which situation

Choose a current DirectAdmin license if the panel still fits your business, your environment is otherwise sound, and you want the least disruptive commercial path.

Choose a fresh rebuild if the server is old, the OS is questionable, or the stack has too much drift to trust in place.

Choose managed web hosting if many of the affected sites are simple and do not justify their own aging panel infrastructure.

Choose infrastructure replatforming if the licensing issue only exposed a broader virtualization and operations problem.

Choose neither ServerSpan service if you need hyperscaler-native architecture, deep internal platform engineering, or full in-house self-management with custom automation. In those cases, you likely need an internal rebuild program, not a managed hosting provider.

Best-fit recommendation

For most DirectAdmin Legacy users, the honest answer is this: stop treating Legacy as something you can stretch one more year. If the server matters, relicense and rebuild on a supported path. If the workloads are simple, move them off the old server class entirely. If the hosting environment is part of a larger virtualization mess, fix the platform, not just the panel invoice.

If you are still deciding whether DirectAdmin remains the right panel after all this, read DirectAdmin vs cPanel: Choosing the Right Hosting Control Panel. If you stay on DirectAdmin, also review newer platform changes like the DirectAdmin 1.695 private_html to public_html merge so your migration does not inherit fresh template-level surprises.

Do not wait!

If your DirectAdmin Legacy server is still expected to carry production workloads beyond July 2026, now is the right time to plan the exit. Use ServerSpan's contact page if you want help sorting which accounts should move to managed web hosting, which systems need a clean rebuild, and whether your broader virtualization layer needs Proxmox-level cleanup before migration. The bad move is waiting until MariaDB 10.6 is already behind you and then pretending it is still a routine maintenance job.