You generally cannot turn a production Debian VPS into Ubuntu with a single command. The dependable method is a rebuild-and-restore migration: document the Debian server, create and test backups outside the VPS, confirm console or rescue access, install a supported Ubuntu Server image, reinstall services, restore reviewed data, test everything, and cut traffic over with the Debian system still available for rollback.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
Ubuntu’s do-release-upgrade handles upgrades between Ubuntu releases; it is not a Debian-to-Ubuntu conversion tool. Treat the distribution change as a new operating-system deployment, not as an in-place package swap.
As an Amazon Associate I earn from qualifying purchases.
Can you switch Debian to Ubuntu without reinstalling?
There is no supported, low-risk command that replaces a running Debian root system with Ubuntu while preserving a working production installation. Debian and Ubuntu both use APT, but they differ in package versions, patches, dependencies, repository metadata, defaults, and release tooling. Replacing Debian repository definitions with Ubuntu repositories can leave a mixed system that is difficult to update or repair.
A clean reinstall is especially important when the Debian VPS contains many third-party repositories, manually installed packages, vendor agents, or software whose origin is unclear. Debian migration guidance treats a complete reinstall as the more reliable compatibility choice in that situation. Preserve the data and configuration you need, then reconstruct the operating system and services on Ubuntu.
#1 Best Overall
The supported Ubuntu command do-release-upgrade is for moving an existing Ubuntu Server or Ubuntu cloud image from one Ubuntu release to another. It does not convert Debian into Ubuntu.
Choose a migration method before touching the VPS
Your provider may offer an operating-system reinstall button, a rescue environment, or the ability to create a second VPS. Select the method that gives you a tested rollback and the least risky downtime.
Free tools Windows power users keep installed
One-click scans. No signup required.
| Method | How it works | Rollback strength | Best use |
|---|---|---|---|
| Parallel replacement VPS | Create a second VPS with Ubuntu, restore the application, test it, then move traffic or attach the production address where supported. | Strongest: the Debian VPS remains intact while Ubuntu is built. | Production services, complex stacks, or uncertain compatibility. |
| Provider-side reinstall | Back up the Debian instance, use the provider console to reinstall the same VPS with an Ubuntu image, then restore data. | Depends on an independent backup and provider recovery tools; the original root disk is normally overwritten. | Small systems where a replacement instance is unavailable and downtime is acceptable. |
| In-place conversion experiment | Attempt to change repositories and packages on the running Debian root filesystem. | Weak. A failed dependency or boot change can make the VPS inaccessible. | Disposable test machines only, never a production migration. |
Compare the options against rollback simplicity, expected downtime, console or rescue access, backup confidence, repository compatibility, preservation of public IP addresses and attached volumes, IPv4 and IPv6 behavior, firewall rules, and the support lifecycle of the Ubuntu release your provider offers. For a production workload, a parallel replacement normally gives the clearest recovery path.
Inventory the Debian VPS completely
Write the inventory to a file stored outside the VPS. Do not rely on memory or on files that will disappear during reinstallation.
Record identity, access, and network details
- Current Debian release and kernel, captured with commands such as
cat /etc/os-releaseanduname -a. - Provider, region, instance size, disk and volume identifiers, mount points, filesystem types, and available capacity.
- Public IPv4 and IPv6 addresses, reverse-DNS settings, DNS records, load-balancer targets, and any reserved-address assignment.
- Administrative users, groups, sudo rules, SSH public keys, SSH port, host-key handling, and any automation account.
- Firewall policy, including host rules, provider security-group rules, allowed management addresses, and exposed service ports.
- TLS certificate locations, renewal jobs, private keys, and the process used to issue or renew certificates.
List every workload and scheduled task
- Web servers, reverse proxies, application runtimes, workers, queues, caches, databases, container engines, and monitoring agents.
- Systemd services and timers, cron entries for every user, boot-time scripts, and provider startup hooks.
- Mounted data volumes, bind mounts, NFS or object-storage mounts, and application directories under
/srv,/var/www,/opt, or custom paths. - Outbound dependencies such as SMTP relays, payment or API endpoints, DNS resolvers, and allow-listed source addresses.
- Software installed outside Debian repositories, including vendor repositories, downloaded binaries, language-version managers, and custom-compiled components.
Audit package sources and origins
Review every file under /etc/apt/sources.list and /etc/apt/sources.list.d/, then identify packages whose origin is not a Debian repository. Record repository signing keys and vendor installation instructions where a service must be recreated. Unknown or numerous third-party sources increase the chance that an in-place conversion will fail and strengthen the case for a clean rebuild.
Back up data in formats you can restore
Installation and partitioning can destroy data. The rollback copy must be outside the VPS, preferably in a separate account, region, or storage system. A provider snapshot can be useful for a quick recovery point, but it should not be your only backup because it may share the same account, storage system, or failure domain as the VPS.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Capture system and service configuration
| Item | What to preserve | How to use it after reinstall |
|---|---|---|
/etc |
Service configuration, users and groups, SSH settings, firewall definitions, DNS resolver settings, and scheduled-task configuration. | Compare each file with Ubuntu’s package defaults and restore only the settings required by that service; do not copy the entire directory over Ubuntu. |
/usr/local and /opt |
Locally installed applications, scripts, binaries, and vendor configuration. | Reinstall or verify the software first, then restore compatible application files. |
| Package state | Installed package selections, manually installed package lists, and APT state such as /var/lib/dpkg and /var/lib/apt/extended_states. |
Use the lists as a reconstruction reference. Do not feed Debian package selections blindly into Ubuntu. |
| Secrets and certificates | Application secrets, environment files, private keys, certificate chains, and renewal-account material. | Transfer through your approved secret-management process, set restrictive ownership and permissions, and test renewal. |
Export databases with their own tools
Use each database’s documented logical-export format rather than copying its live data directory between distributions. Examples include SQL dumps for relational databases and LDIF for directory services. Record the database version, character-set or collation settings, extensions, users, grants, and any replication or recovery configuration. A dump that exists but cannot be imported is not a usable backup.
Copy application data and persistent volumes
Back up uploads, user-generated files, website content, queue data that must survive, container volumes, and any data stored outside the main database. Preserve ownership, group ownership, permissions, symbolic links, extended attributes, and file timestamps when those properties affect the application. Document the source and destination path for each volume so that a restore does not accidentally place data in a directory Ubuntu does not use.
Verify the backup before reinstalling
- Check that the copy is stored outside the VPS and that access credentials are available from a clean machine.
- Calculate or otherwise verify file integrity for the backup set.
- Perform a test restore of representative configuration files, application files, and at least one database export.
- Start the restored database in an isolated environment and run an application-level read test.
- Document the exact restore commands, required software versions, credentials, and expected ownership and permissions.
A sound backup plan states what is backed up, where it is stored, how often it is created, and how restoration works. Keep more than one independent copy when the service’s recovery requirements justify it.
Keep remote access during the change
SSH may disappear when the operating system, network configuration, firewall, or bootloader changes. Before stopping or reinstalling the VPS, log in to the provider’s web console and verify that it works. Confirm the availability of rescue mode, a serial terminal, virtual keyboard, or equivalent out-of-band channel, and learn how to mount the disk and reset networking from that environment.
Recommended Free Tools
- Keep a second administrative session open while making changes.
- Confirm that your SSH key and an emergency administrative account are available after the rebuild.
- Record the provider’s console URL, instance identifier, rescue instructions, and support contact in your migration notes.
- Do not close the console session until Ubuntu accepts SSH connections and you have confirmed firewall behavior.
Provision Ubuntu cleanly
Select a supported Ubuntu Server release or cloud image that the provider currently offers. If the provider can create a replacement VPS, use that option so the Debian machine remains untouched. If you must reinstall the existing VPS, verify the backup and console access one more time before confirming the destructive operation.
- Choose the Ubuntu image and region, instance size, disk layout, and networking model. Match or exceed the Debian system’s CPU, memory, and storage requirements.
- Attach existing data volumes only when you understand their filesystem and mount behavior. Do not format a volume that contains the backup or application data you intend to restore.
- Set the initial administrator, SSH key, hostname, and provider firewall rules. Allow only the ports required for administration and the application.
- Complete the first boot, update the package index and installed packages, set the correct time zone, and enable time synchronization.
- Apply operating-system hardening: least-privilege users, sudo policy, SSH restrictions, automatic security updates where appropriate, and a host firewall consistent with the documented network policy.
Ubuntu’s installation guidance warns that installation and partitioning can lose data, which is why an external, tested backup is a prerequisite rather than an optional precaution.
Rebuild services instead of cloning the old root filesystem
Install each production component from Ubuntu repositories or the software vendor’s current Ubuntu instructions. Ubuntu and Debian share many administration concepts, but package names, defaults, service units, file locations, and configuration syntax can differ.
Recreate the base operating environment
- Create the same application users and groups, checking numeric IDs when restored files depend on them.
- Create required directories with the intended ownership and permissions.
- Install the runtime versions, database servers, web servers, queue systems, container tools, and monitoring agents required by the inventory.
- Recreate systemd units, timers, cron jobs, log rotation, temporary-file cleanup, and mount definitions.
- Rebuild firewall rules and provider security-group rules from the documented policy rather than copying Debian-specific commands.
Restore web and application services selectively
Install the web server or reverse proxy, then compare Ubuntu’s default configuration with the saved Debian configuration. Restore virtual hosts, upstream definitions, headers, timeouts, and access controls one service at a time. Recreate application environment variables and secrets through the approved secret process. Copy static files and uploads only after the target directories exist with the correct owner.
Restore databases through import procedures
Install the required database version, create users and permissions, initialize the schema if the application expects it, and import the logical dump. Check extensions, collation, time zone behavior, stored procedures, scheduled jobs, and connection limits. For large databases, measure import time and disk space before scheduling the final cutover.
Rank #4
Recreate containers and persistent storage
Install the container engine and restore compose files, image references, environment files, network definitions, and persistent-volume mappings. Pull or load the intended image versions, then attach restored volumes only after checking their ownership and schema compatibility. Do not assume a container that ran on Debian will use identical host paths or kernel defaults on Ubuntu.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Validate Ubuntu before moving traffic
Start services individually so that a failure is attributable to one component. Keep a written record of each check and its result.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →- Confirm the hostname, time, disk capacity, memory, CPU allocation, and all expected mount points.
- Check listening sockets with a tool such as
ss -lntupand verify that only intended services are exposed. - Read service status and logs, including failures caused by permissions, missing environment variables, or changed configuration paths.
- Exercise local health endpoints and perform a real read/write transaction against the restored database.
- Test outbound mail, DNS resolution, external APIs, package updates, and any allow-listed destination.
- Test both IPv4 and IPv6 if the VPS has both, including DNS records and firewall rules for each protocol.
- Run a backup job on Ubuntu and confirm that the resulting files can be read from the external storage location.
- Verify monitoring, alerting, log shipping, certificate renewal, cron jobs, and systemd timers.
- Perform an external smoke test from a separate network before changing DNS or load-balancer targets.
Cut over traffic with a rollback window
- Lower DNS TTL ahead of the migration when practical, while recognizing that resolvers may cache records longer than the requested TTL.
- Freeze writes or place the application in maintenance mode for the final data export if the workload cannot tolerate divergent changes.
- Take a final database export and synchronize files changed since the initial restore.
- Apply the final network, DNS, or load-balancer change only after the external smoke test passes.
- Monitor HTTP errors, application logs, latency, CPU, memory, disk, queue depth, database errors, mail delivery, and authentication failures.
- Keep the Debian VPS powered off or isolated, but recoverable, until the agreed rollback window expires and the Ubuntu backup has been verified.
If validation fails, stop the cutover, direct traffic back to Debian, and diagnose Ubuntu without changing the known-good instance. Do not delete the old VPS until restoration and application checks are complete.
Common mistakes and their fixes
Replacing Debian sources with Ubuntu sources
This can produce dependency conflicts, overwritten packages, broken maintainer scripts, and an unbootable system. Rebuild on Ubuntu instead, using the inventory to reinstall software and restore only compatible configuration.
Copying all of /etc
Ubuntu packages may expect different defaults and paths. Compare files service by service, preserve only deliberate settings, and let Ubuntu generate package-owned configuration where possible.
Best Value
Trusting a snapshot as the only backup
A snapshot may be inaccessible with the account, storage system, or provider failure affecting the VPS. Keep an independent copy, test a restore, and document the recovery procedure.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesRebooting without console access
A firewall typo, wrong interface name, or failed network service can remove SSH access. Confirm the provider console or rescue path before the first disruptive change.
Assuming an IP address or volume will survive
Some providers assign a new address or detach volumes during a reinstall. Record the provider’s behavior, reserve addresses where supported, and test attachment and mount procedures on the replacement system.
Changing DNS before testing
Early DNS changes send users to an unverified server and make diagnosis harder. Validate locally and externally first, then switch traffic while Debian remains available for rollback.
Quick Recap
Decision checklist
- Is the target Ubuntu release supported by the provider and suitable for the application’s runtime and vendor requirements?
- Is every production service, data store, scheduled task, secret, certificate, mount, and network rule recorded?
- Are database exports and file backups stored outside the VPS and proven restorable?
- Can you reach a web console, rescue mode, or serial terminal if SSH fails?
- Will the chosen method preserve or deliberately replace public IP addresses and attached volumes?
- Has Ubuntu been tested with representative application traffic before DNS or load-balancer cutover?
- Is the Debian instance retained until the rollback deadline and the first Ubuntu backup has succeeded?
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
