Resizing is usually safe and usually boring, which is why the two steps that are not automatic get missed. Take a snapshot first regardless - resizing is one of the few operations that touches the disk layout.

CPU and memory

Change the plan, reboot, done. The kernel sees the new size at boot and nothing inside the machine needs touching.

nproc\nfree -h

Disk needs two more steps

A larger disk in the provider panel is not a larger filesystem. The partition has to grow into the space, and then the filesystem has to grow into the partition. Until both, df shows the old size and nothing has gone wrong.
lsblk\ngrowpart /dev/sda 1\nresize2fs /dev/sda1        # ext4\n# or\nxfs_growfs /                # xfs

growpart moves the partition boundary; resize2fs or xfs_growfs tells the filesystem to use it. Both can be done on a mounted, running filesystem.

Then the software that was sized for the old machine

  • PHP-FPM max_children - set from the old memory, so the extra RAM is not used.
  • innodb_buffer_pool_size - the same.
  • Worker counts in anything else you run.

Doubling the machine and changing nothing inside it usually produces no improvement at all, and that is where "the upgrade did nothing" comes from.

Downsizing

Most providers will not shrink a disk, and those that do require the filesystem to be shrunk first - offline, with a real risk. Assume a resize is one-way and size accordingly.
Snapshot before, and check that df, free and nproc all show what you paid for after. The panel showing the new plan is not the same as the machine using it.