Moving from shared hosting to a VPS is two changes at once: a migration, and a transfer of responsibility. The migration is a day's work. The responsibility is permanent, and it is the part worth deciding deliberately.
Make sure you are moving for the right reason
Three reasons are genuine.
You have hit the ceiling: caching is working, no plugin is misbehaving, and the site still queues during ordinary traffic.
You need something shared hosting cannot give. A specific service, root access, a background worker, an unusual runtime.
You want isolation from other accounts, for resource or compliance reasons.
What is not a reason: a slow site with no caching, or one expensive plugin. Both follow you, and a bigger machine makes them cheaper to ignore rather than fixed. How to Speed Up a Website in the Right Order sets out checking before you move.
Decide managed or unmanaged first
This decides how much of the rest applies to you.
Unmanaged means the operating system, the web server, PHP, the database, security updates, firewall, backups and recovery are yours. Nobody is watching it but you.
Managed, or a VPS with a control panel licence, keeps most of that familiar, and costs more.
Cost the unmanaged option honestly: the price difference plus the hours you will spend, arriving at inconvenient times. For many small businesses a managed VPS or a better shared plan is the better answer, and that is a legitimate conclusion. How to Compare Shared, VPS and Dedicated Hosting walks through the trade.
What you have to do yourself now
On shared hosting these were somebody else's job. On an unmanaged VPS they are yours, and skipping any of them is how a VPS becomes a compromised VPS.
Security updates, applied on a schedule rather than when you remember. For automating them, see How to Set Up Automatic Security Updates.
A firewall, default deny, with a verified way back in before you touch it.
Backups that leave the machine. A snapshot on the same platform is not a backup.
Monitoring from outside, alerting somewhere that does not depend on this server.
Log rotation, or the disk fills and everything stops at once.
Set all five up in the first week, while nothing is urgent.
Size it from measurement
Look at your current usage during the busiest hour rather than guessing.
Memory is the one to be generous with: CPU pressure makes things slower, while running out of memory makes the kernel kill your database, and make sure swap exists so the failure is slowness instead of an outage. There is more in How to Configure Swap and Memory on a VPS.
Start smaller than you expect and resize. Most providers make adding memory a reboot, and paying for capacity you do not use is a monthly cost in place of a one-off.
Migrate with the site still live
Build the new server while the old one keeps serving. Then test through your hosts file, so you see the new server while everyone else still reaches the old one.
Load real pages, submit a form, log in to the admin, and complete a purchase if it is a shop. That is your only private rehearsal.
Lower the DNS TTL a day or two beforehand, so the cutover is minutes rather than hours. The old value must expire before the new one applies. Understanding DNS Propagation walks through why doing it on the day accomplishes nothing.
Mail is the part that goes wrong
Shared hosting handled mail invisibly. A VPS does not unless you make it, and running a mail server properly is a project in itself: reverse DNS, authentication, spam filtering, reputation.
For most people the right answer is not to: keep mail with an external provider and point the MX records there. The website moves, the mail does not, and one of the hardest parts of running a server disappears. How to Use an External Mail Provider with Your Domain goes into the records.
Match the environment before you move
The PHP version and its extensions, the database version, and any module the application needs.
A site moved onto a newer PHP version than it was tested against fails on one page instead of the homepage, which is the sort of thing found by a customer. For the extension trap, see MultiPHP Manager and Choosing a PHP Version.
Keep the shared account for a fortnight
Not as a fallback for the website, running both splits your data. Keep it so late mail is not bounced and so anything that landed there during the changeover can be retrieved.
Problems from a migration surface days later: a cron job with a hardcoded path, a form that stopped emailing, an upload directory that came across empty.
The first week on the new server
Watch the error log rather than only checking that pages load. Confirm the backups ran and restore one to a test location. Reboot deliberately, so boot problems surface while you are watching rather than during an unplanned restart in six months.
Then write down what you configured and why. On shared hosting the configuration was implicit; on a VPS it is yours, and the note is what makes it maintainable by anyone including you next year.
The transfer itself is best done with a tool that resumes and copies only differences. There is more on the commands and the trailing slash that decides where files land in How to Use rsync for Transfers and Backups.