Plan the release upgrade
Plan an Ubuntu release upgrade around compatible dependencies, a tested recovery route and an explicit go or no-go decision.
Routine package updates differ from a release upgrade, which can replace packages, defaults and application dependencies. A fresh-image reinstall may erase the disk. Neither should begin solely because an update notice appears.
For a Novasean-managed VPS, ask the operator to plan the guest-OS change under the actual service agreement. The application owner or agency must identify its compatibility requirements and run acceptance tests. If you administer your own guest under an existing service arrangement, confirm that this responsibility and the required panel controls are available before following an Ubuntu command. A current vendor support matrix does not establish that your installed control-panel version and application stack are ready.
Check the release path and application dependencies
Record the current release with cat /etc/os-release and check Ubuntu’s supported path to the intended release. LTS versions normally advance to the next sequential LTS; do not skip an intermediate release or use the development-release flag on a production VPS to force an offer. Ubuntu enabled the 24.04 LTS to 26.04.1 LTS route in September 2026, but availability does not replace a service-specific compatibility decision. Read the target release notes before scheduling the change.
Inventory the web server, PHP and database versions, control panel, third-party APT repositories, application runtime, cron jobs, mail service, agents and external integrations. Check with each maintainer that the target OS is supported. Ubuntu notes that third-party repositories can be disabled during a release upgrade and may cause conflicts. Check free disk space and package health; leave enough capacity for downloads and recovery logs. If a required component is unsupported, its owner is unknown or the installed panel cannot be safely upgraded, stop and plan a separately tested migration instead.
A supported Ubuntu target and control-panel support listing do not establish compatibility of this VPS's installed versions, extensions or application.
Prove you can recover before touching the guest
Identify a current backup outside the VPS that includes the data and configuration needed to restore service. Check the actual backup entitlement and retention: a Virtualizor backup button or snapshot must not be assumed to exist for every account. Have the authorised operator test restoration in an isolated destination where available. A successful backup job is not a restore test, and an on-VM copy will not survive every disk or reinstall failure.
Confirm console access from the VPS management panel while the machine is healthy; keep an authorised recovery route if SSH stops after reboot. Record current IP settings, SSH access method, boot and firewall configuration, DNS, application endpoints and the services that should be running. Agree a maintenance window, expected interruption and a go or no-go decision with the application owner. Keep the previous environment or a tested rebuild plan available until the new release is accepted. The VPS console guide and application-consistent backup guide explain those separate checks.
Illustrative stop: if the backup job completed but no isolated restore or alternative recovery route has been verified, postpone the release upgrade until recovery can be demonstrated.
Run the upgrade only inside the approved window
For a customer-administered Ubuntu Server guest with a verified recovery path, follow Canonical’s current server upgrade instructions for the exact source and target releases. Fully update the current release first, review packages proposed for removal and the target release notes, and allow time for interactive configuration questions. Ubuntu recommends sudo do-release-upgrade for Server and cloud images. Do not blindly accept a replacement for a locally changed configuration file; record the choice and its application impact. For VM Start with Managed OS, agree the guest-OS upgrade with Novasean under the accepted schedule; customer root access does not remove the need to coordinate OS work.
Keep the console route available throughout the process. An SSH session may disconnect or services may restart; a second connection attempt does not prove that the upgrade failed or finished. Use the console and the upgrader’s recorded state to decide what happened. If preflight finds insufficient space, an unsupported path or an unresolved package conflict, do not start the upgrade. Once package changes have begun, do not kill the upgrader or rerun it blindly; respond to its prompts using the approved operator and recovery plan, preserving the reported state if it fails.
Verify the service before declaring success
After the required reboot, confirm the expected Ubuntu release, SSH and console access, network configuration and critical services. Review failed systemd units and application logs. The application owner should test a real database-backed page or transaction, an uploaded asset, sign-in through a designated test account, scheduled work, outbound mail and integrations as relevant. Compare the results with the pre-upgrade checklist; a working homepage is insufficient proof.
If the guest does not boot or a critical application fails, preserve console and log evidence and use the agreed restore or fresh-instance migration path. Do not assume that an in-place downgrade is supported or that another release-upgrade run will recover missing data. For a Novasean-managed VPS, report the incident and the failed acceptance check through the agreed support route; responsibilities for guest recovery and application repair follow the actual service schedule.
Common questions
Can this be done with no downtime? An in-place release upgrade can restart services and the guest. Plan an interruption; a separate-instance migration may reduce it, but requires its own data-sync and cutover plan.
Is the Virtualizor Re-Install OS button the same thing? No. It creates a fresh installation and is destructive to the reinstalled disk. Use the reinstall preflight only when a fresh image is the approved route.
Does DirectAdmin support the newest Ubuntu release? Current DirectAdmin documentation lists Ubuntu 26.04 LTS, but compatibility of the installed panel release, CustomBuild components and customer applications still needs a specific review before this VPS changes.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.