VPS Tutorials
Will a VPS upgrade lose data? (2026): downtime, IP changes and downgrade limits to check before paying
Before upgrading an undersized VPS, check data, downtime, IP and renewal pricing. Compare an in-place resize, disk expansion and a new server, with a support template and acceptance checklist explaining why returning to the old plan may be impossible.
Upgrading a VPS is not the same as reinstalling it, but it does not guarantee safe data, uninterrupted service or a downgrade whenever you want. Before paying, find out whether you are changing CPU and RAM, expanding the system disk or effectively moving to another server.
If your plan is no longer sufficient, this guide compares an in-place upgrade with a new server and explains what to ask the provider before submitting changes. It does not teach disk commands or require server-administration knowledge first.
Upgrade, Resize and Rescale commonly refer to resources. Rebuild and Reinstall often mean reinstalling the operating system. Names are clues; read the confirmation page's explanation of data handling.
| Planned action | What it means for existing content | Main question before submitting |
|---|---|---|
| Increase CPU and RAM on the existing instance | Usually aims to keep the existing environment | Required downtime and available target plans |
| Expand the existing instance's system disk too | Adds storage and changes the disk | Whether it can shrink later and whether the system recognizes the space automatically |
| Buy another plan and have the provider or maintainer migrate | Old and new servers coexist; content needs migration | Who moves and validates it, and when old-server billing ends |
| Reinstall or rebuild | May overwrite the system disk | Whether data is erased; do not confuse it with adding resources |
For example, Hetzner's official server FAQ treats Rescale and Rebuild separately and explicitly warns that rebuilding loses stored data. “Just click in the panel” is not a reason to skip confirmation.
If the provider says data is retained, ask which data: system disk, separately purchased data disks, website files, databases, panel and application configuration.
DigitalOcean's official resizing guidance recommends snapshots and backups before changes, because resizing can involve moving the underlying host and failures can still cause data loss. Keeping the existing environment does not remove the need for backups.
At minimum, know when the backup was made, where it is stored and who restores it if the change fails. An Automatic Backup switch alone does not establish a recovery path.
Coordinate backup timing for sites receiving orders or continuous uploads. A maintainer can pause writes at a suitable time and create a recoverable backup so files and business records reflect the same point in time. Keep important backups somewhere beyond the VPS being changed.
If the differences are unclear, read VPS snapshots, backups and images.
Submitting an order online does not guarantee continuous application availability. Resource changes may require a clean shutdown and restart. Moving to a new server can also require switching the website entry point. Downtime depends on the selected procedure and actual processing.
Ask how long this operation is expected to interrupt service, when it starts and who checks completion, rather than only how long the upgrade takes. Without a zero-downtime commitment, schedule for quieter traffic and allow validation time.
Confirm IP retention separately. Resizing, changing locations and migrating to another server are different operations. A previous upgrade retaining its address does not guarantee this one will.
If the IP changes, list settings requiring updates, such as domain records, third-party allowlists and remote connection details. Have the maintainer confirm the switch plan before the upgrade, rather than searching for someone to fix settings after the website fails.
CPU, RAM and disks may follow different resizing rules. Hetzner's official disk downgrade guidance says a disk cannot simply shrink even when little space is used. Keeping disk capacity during an upgrade may preserve options to return to a compatible smaller plan.
Suppose you move from 2 cores, 4GB RAM and a 40GB disk to 4 cores, 8GB RAM and an 80GB disk. Storing only 10GB does not mean you can directly return to a 40GB-disk plan. These numbers illustrate the issue, not actual offered specifications or prices.
For a short event needing more compute, ask whether CPU and RAM can increase while retaining the disk and whether the target plan permits it. Even then, verify product family, availability and provider downgrade rules. Retained disk size is not a guarantee.
If in-place downgrade is unavailable, you may need a new smaller plan and migration, adding transfer work, validation and temporary overlap in billing.
The upgrade page may show only the adjustment for the current billing period. Check today's payment, next renewal amount, any expiry-date change and whether existing discounts remain.
You can send these questions together:
I want to change this service from its current plan to the target plan. Please confirm whether this is an in-place change, whether system and data are retained, expected downtime, IP changes, whether disk capacity can stay unchanged and which plans I can downgrade to later. Also confirm the amount due now, next renewal price and retained discounts, plus recovery arrangements and fees if the change fails.
Ask separately about snapshots, extra disks, licences and manual migration. Confirm unspecified charges before paying. A small current adjustment does not establish the size of ongoing cost increases.
If location and networking are satisfactory, the application is stable, only CPU or RAM is insufficient and the provider supports preserving the environment, consider an in-place upgrade first. It usually avoids a migration handover but still needs backup and validation.
More RAM may not solve poor routing, an unsuitable location or support problems. If you need another platform or unsupported specifications, creating and validating a new server before switching is a better match.
For an active website, assign someone to check recent content, login, uploads and important business flows on the new instance. Arrange cancellation of the old server after validation and the switching plan are clear. A maintainer can use the VPS migration and downtime reduction guide.
Check administrative access, website and application operation, important files and recent records, and whether specifications and invoices match the agreement.
If the panel shows a larger disk but usable system space has not changed, ask the provider or maintainer to investigate. Do not click Reinstall to refresh capacity. For making expanded space available inside the system, see using new space after VPS disk expansion.
Keep the previous configuration, backup records and support replies. Once the application is stable, remove temporary resources as agreed. These records help distinguish reversible future upgrades or downgrades from changes requiring another migration.