2026 Debian 11 Website Migration: Upgrade In Place or Move to a New Server?

Debian 11 LTS support ended on August 31, 2026, and the Debian project says it no longer provides security updates for that release from September onward (Debian’s lifecycle announcement). If your production site has multiple applications, unclear dependencies, or an uncertain rollback path, rebuild on a supported environment and migrate in stages. If the site is simple, well-documented, and recoverable from a tested backup, you can consider an in-place upgrade using Debian’s documented route.

This guide is for site owners maintaining Debian 11 storefronts or company websites who need to check the system’s support status and application dependencies.
It also helps teams running WooCommerce or several export sites compare a parallel migration with an in-place upgrade.
If you are moving from a VPS or shared hosting to a dedicated server, use the steps below to plan testing and the cutover.

Last updated October 23, 2026. Debian support and upgrade details were checked against the Debian 11 lifecycle announcement, the Debian 12 release notes, and Debian’s Debian 13 upgrade documentation.

Start by choosing for the team and site you actually run

An operating-system upgrade is not just a package change when a website depends on a control panel, third-party repositories, custom PHP settings, a database, scheduled jobs, and external services. The right route depends on whether you can identify and test those dependencies, and whether you can restore service safely if the change fails.

Use these decision branches before scheduling work:

• Choose a new environment and staged migration if you manage multiple sites, run different PHP versions, rely on a panel or third-party packages, or cannot confidently explain the current system’s configuration. A parallel environment lets you test sites separately and keep the old system available while you verify the new one.
• Consider an in-place upgrade if the site has few dependencies, its repositories and services are documented, the applications support the target release, and you have tested both restoration and rollback. Follow Debian’s documented upgrade path; do not treat the process as risk-free or assume it will avoid downtime.
• Do not make a direct Debian 11-to-Debian 13 upgrade your default plan. Debian’s documented Debian 12 route covers upgrading from Debian 11. Debian 13’s upgrade documentation describes its own supported starting point and steps; check the applicable release notes rather than skipping a release based on assumption.
• Pause either route if you cannot restore a working copy of the site, cannot identify where critical data is stored, or have not confirmed that your panel and applications support the target system.

This is a qualitative decision framework, not a promise about migration time, performance gains, or fixed costs. The Debian documentation describes supported system procedures; your website’s compatibility still needs separate verification.

Check whether Debian 11 can keep serving the website after support ends

A Debian 11 server may continue running after the LTS end date. That does not mean it remains a suitable production platform: the Debian project says security updates for Debian 11 ended with LTS on August 31, 2026 (lifecycle announcement). Treat the distinction between “the site still responds” and “the operating system still receives security updates” as a maintenance decision, not a reason to postpone planning indefinitely.

For a public-facing store or business site, continued operation on an unsupported release leaves you without Debian-provided security updates for that version. You may also find that application vendors, control-panel maintainers, or third-party repositories have their own support limits. Those are separate compatibility questions: a working web server does not prove that every installed component remains supported.

Before choosing a path, record the current system state:

• [ ] List the enabled Debian repositories and any third-party package sources.
• [ ] Record the web server, database, PHP versions, installed extensions, and control-panel version.
• [ ] Identify each site’s document root, database, uploaded files, certificates, and scheduled tasks.
• [ ] Note integrations that receive or send data, including payment callbacks, forms, and external APIs.
• [ ] Confirm who can access the server, where backups are stored, and how restoration will be tested.

If you cannot complete that inventory, do not start with an in-place upgrade on the production machine. Resolve the unknowns first or build a separate target environment where you can test the applications without replacing the only working copy.

Use an in-place upgrade only when the system is understood

For a single site with a small, known dependency set, an in-place upgrade may avoid transferring every application to a separate machine. It also concentrates risk: if a package conflict, configuration change, or service failure occurs, the affected system is the one currently hosting the site.

Debian’s official Debian 12 upgrade instructions document the route from Debian 11. Read the notes that match your system architecture and configuration before changing package sources. Debian’s upgrade-related release information also covers issues to consider during the transition. Neither document can confirm that your site-specific code, panel, or third-party packages will work afterward.

Use this sequence:

1. Inventory the machine. Record repositories, packages, web-server configuration, PHP extensions, database settings, scheduled tasks, firewall rules, and any local scripts. Save the output and configuration files somewhere outside the server.
2. Check compatibility. Confirm that your panel, application, plugins, database version, and required PHP extensions support the target Debian release. Resolve unsupported repositories or packages before beginning.
3. Create and test recovery material. Back up the site files, databases, certificates, and relevant configuration. Restore the backup to a test environment and confirm that the restored application can start. A backup that has never been restored is not a verified rollback plan.
4. Set a maintenance window and service interruption plan. Debian’s release guidance requires preparation for service interruption and restart during an upgrade. Tell the people responsible for the site when changes will occur and how you will display a maintenance state if needed.
5. Follow the official upgrade instructions. Do not improvise a shortcut by changing release names and hoping the package manager resolves every dependency. Review warnings and package changes during the process.
6. After the upgrade, verify each service. Check the web server, database, PHP handlers, certificates, scheduled tasks, logs, and application-specific workflows. Confirm that changes survive a reboot before treating the machine as recovered.

If a repository or application’s support status is unclear, treat that as a blocker rather than silently assuming compatibility. Debian can document its operating-system upgrade; it cannot certify a third-party panel’s behavior or your application’s custom configuration.

Prefer a parallel move when several sites share uncertain dependencies

A new environment is usually easier to inspect when several sites share a machine but have different runtime requirements. You can prepare a supported operating system, install the required services, migrate one site, and validate its behavior before changing the next. This does not make the migration automatic or guarantee a short cutover. It gives you a separate place to test and a clearer option to return to the old environment if a check fails.

For each site, create a migration record with:

• Files and databases: document the source location, database name, database version, export method, and any writable upload or cache directories.
• Runtime and configuration: record PHP versions and extensions, web-server rules, environment variables, scheduled jobs, and application-specific settings.
• Certificates and DNS: list certificates, renewal arrangements, DNS records, and the person authorized to make changes.
• External connections: note payment callbacks, API allowlists, license checks, webhooks, and any integration that depends on the server’s address.
• Access and ownership: identify administrator accounts, file permissions, application users, and which team member will verify each site.

Move a low-risk site first. Use it to confirm that your copy process, file permissions, database import, TLS setup, and DNS plan work as expected. Then migrate sites with more business impact, scheduling each separately where possible. For a store, include a controlled check of login, product browsing, cart behavior, checkout, payment callback handling, order recording, and notification workflows. Do not assume that a homepage load proves a successful migration.

For several websites, isolation matters as much as the transfer itself. Keep site files and credentials under appropriately restricted accounts, avoid giving every application write access to every other site, and plan separate PHP execution contexts where your hosting design supports them. Maintain off-server backups and put a web application firewall or CDN in front of public services if your security plan requires one; do not treat either as a substitute for patching or access control.

Can you upgrade Debian 11 directly to Debian 13?

Do not assume so. Debian’s Debian 12 documentation provides the upgrade route from Debian 11, while the Debian 13 upgrade notes describe the route into Debian 13. The safer planning approach is to follow the applicable official release path and verify each transition, rather than skipping a release because the destination looks newer.

For a new server, choose a system release that is available for that server and currently supported for your application stack. Debian 12 or Debian 13 may be appropriate depending on application, panel, and package compatibility. Check the target release’s known issues before deploying; Debian publishes Debian 13 release issues. The newest release is not automatically the right one if a required panel or application has not been validated on it.

If you move to Debian 12 first and later plan another release transition, treat that as a separate change with its own review, backup, and tests. Do not combine a system transition with unrelated application, database, or panel upgrades unless you have a strong reason and have rehearsed the complete sequence. Keeping changes separable makes it easier to identify what caused a failure.

Reduce cutover risk for multiple websites with staged verification

For a parallel migration, the main risk is often not copying files; it is missing a dependency or allowing data to diverge between the old and new systems. Define how you will keep content and transactions consistent before changing DNS or routing traffic.

Use this sequence for each site:

• Prepare a test copy. Import the files and database into the new environment. Use a private test route or another controlled method so visitors do not accidentally use an incomplete copy.
• Validate real workflows. Test sign-in, form submission, order creation, payment callbacks, scheduled jobs, and data writes. Review application and service logs for failures.
• Set a final data synchronization point. Decide when you will stop or limit writes, copy the last changes, and confirm that the destination contains the expected data. For a transactional store, identify who checks the final orders and records.
• Switch traffic deliberately. Use the planned DNS or application-routing change only after the destination passes the agreed checks. Record the previous values and the person responsible for restoring them.
• Monitor and define rollback triggers. Watch error logs, application health, successful transactions, and data consistency. If a critical workflow fails or new data is not being recorded correctly, follow the rollback plan rather than continuing to send traffic into an unverified system.

DNS changes can take time to be reflected by clients and resolvers, so a DNS switch should not be treated as an instant, universal cutover. Keep the old environment available for the period your team has planned, but prevent uncontrolled writes to both systems. Otherwise, rolling back traffic can leave orders or submissions split across two databases.

Use a new-environment check card before choosing a server

If your inventory shows that parallel migration is the more manageable path, verify the target server’s system, storage, access method, and billing terms before committing. The OVN Cloud product information lists an AMD EPYC 7543P bare-metal server with 32 cores and 64 threads, memory options of 128 GB or 256 GB, and two directly attached 1 TB NVMe drives. It does not include hardware RAID; the product notes describe direct-attached disks, so plan your own redundancy and off-server backup rather than assuming mirrored storage. Check the current server configuration details before selecting an option.

• [ ] System: confirm the available Debian 12 or Debian 13 option against your application and panel requirements. Do not select an older release for a new production deployment just because the existing server uses it.
• [ ] Storage: decide how your team will handle redundancy and off-server backups. Review disk options and limits in the current product listing.
• [ ] Access: Linux access is through SSH. Confirm that the staff responsible for setup can reach the server and have a secure account and key-management plan.
• [ ] Location: the server location listed for this service is Tokyo, Japan. Assess it against your users and application needs; do not infer a guaranteed latency to any particular network.
• [ ] Billing: check the available billing periods and the current price in the product listing. Do not base the migration budget on an assumed discount or an unverified amount.

OVN Cloud’s SSH and RDP access guide covers the stated remote access methods. The machine provides an independent environment, but your team remains responsible for application setup, migration validation, and backup planning. Confirm current product details before ordering; server specifications and prices should be read from the live product information, not carried over from an old plan.

Turn the decision into a site-by-site migration plan

Before choosing the route, list each website, its owner, dependencies, data stores, business impact, and recovery method. Then assign a path rather than making one system-wide decision for every site. A small static company site may be suitable for a straightforward in-place upgrade, while a multi-store environment with different PHP requirements may be easier to test through staged migration.

Use this action list to keep the work controlled:

• [ ] Confirm the Debian 11 support status and identify every machine still running it.
• [ ] Complete a dependency and ownership inventory for each site.
• [ ] Choose an in-place upgrade only where the system is understood, target compatibility is checked, and restoration has been tested.
• [ ] Choose a parallel move where dependencies are numerous, undocumented, or easier to validate site by site.
• [ ] Rehearse the chosen path with a non-critical site or test copy.
• [ ] Set the maintenance window, data synchronization point, monitoring signals, and rollback trigger.
• [ ] After the change, confirm that the new system receives security updates and that application workflows continue to work.

The Debian release notes define the operating-system path; they do not replace checks for your panel, plugins, custom packages, or business integrations. If those checks reveal a dependency you cannot safely support on the existing machine, planning a new environment is more defensible than making an unverified production change.

A shared host or VPS can still be the better fit if you have a light workload, need only a short-lived environment, or value managed platform features more than control over the machine. But shared CPU contention can make performance less predictable, and provider limits may constrain disk or system customization; bandwidth metering and included transfer also vary by plan. If those limits are affecting a long-running multi-site operation, an OVN Cloud dedicated AMD server in Tokyo gives you an entire physical machine rather than a shared VPS allocation. Review the available configurations only after you have confirmed that the target operating system and migration plan fit your sites.