Upgrade on a server's page moves it to a larger plan without rebuilding it. Your data stays where it is.
Upgrades only
Every dimension has to stay the same or grow, and at least one has to grow. The disk is the hard limit rather than a policy: a virtual disk cannot be shrunk safely, so a plan with a smaller disk can never be applied.
You will be refused if the target plan has:
- less storage ("Storage cannot be shrunk")
- fewer vCPUs or less memory (downgrades are not available)
- a different compute family, or a different port speed
You cannot resize between General Compute and Network Optimized
The resize job rewrites cores, memory and disk. It never rewrites the network device, so a cross-family move would change your rate while leaving the server on its original port cap. To change port speed, deploy on the plan you want and migrate.
Two things happen at different times
Billing changes immediately. Metering prices every hour from the plan the server is on, so the open hour re-rates to the new plan. There is no prorated invoice, because there is no invoice for runtime at all.
Hardware changes on your next power-on. vCPU, RAM and disk are applied when the server next boots. That is deliberate: it means an upgrade does not force downtime at a moment you did not choose.
So to actually get the new resources, restart the server when it suits you.
Growing the filesystem
The virtual disk grows, but the partition and filesystem inside the guest may
not follow on their own. On most modern cloud images cloud-init grows the root
partition on boot. If it did not:
# Check what the guest can see
lsblk
df -h /
Cancelling
An upgrade that has been requested but not yet applied can be cancelled from the server's page, which puts the rate back.
When it is refused
Resize is refused while the account is suspended, while the credit balance is negative, while another job is running on the server, and while an upgrade is already scheduled.