You open your site, you open the hosting panel, and you're stuck between two buttons: "Upgrade" and "Migrate." You know you need to change your plan because either your disk space is full, or the inode count has passed the limit, or every night at midnight the site goes to sleep because the plan's RAM can't keep up. The real question isn't which plan is better; the question is in what order to perform the hosting plan upgrade so that a user in the middle of a purchase doesn't see a white screen.
The first thing I do is pin down the cause with numbers, not with a feeling. If you suspect the problem is inodes, you can count them with a simple command:
find ~ -type f | wc -l
find ~ -type d | wc -lCompare the sum of these two numbers with your plan's limit. If you're close to the limit, an upgrade only buys you time; the real problem is usually old caches, backup copies sitting on the host itself, or stored session files. The details of counting and what consumes inodes are covered in inode limits on hosting and it's worth five minutes of reading, because without it you might buy a more expensive plan and hit the same limit again two weeks later.
Why a hosting plan upgrade on the same server is almost downtime-free
When the new plan is on the same server and the same partition, the migration is just a quota change and a rewrite of the web server config. Files don't move. DNS doesn't change. SSL isn't touched. In this case, actual downtime is usually under 60 seconds, and most of it is spent reloading PHP-FPM and the web server.
But if the new plan is on a different server, the story changes completely. Here you have a full migration: copying files, dumping and restoring the database, reconfiguring cron, and most importantly, waiting for the A record's TTL. This is where sites go down for hours and nobody figures out why.
First things first: lower the TTL, not after the migration
This is where people make a mistake. Most people do the migration first and then remember that the A record's TTL is set to 86400 seconds (24 hours). The result is that the new site is ready, but some users are still going to the old server for a full day. If you've shut down the old server, they see a connection error and you think DNS is the problem.
The correct order is: at least 24 to 48 hours before the migration, reduce the A record's TTL to 300 seconds (5 minutes). Wait for the old TTL to expire. Then perform the migration. After you're sure everything is stable, return the TTL to its previous value.
| Record | Before migration | During migration | After stabilization |
|---|---|---|---|
| A / AAAA | 300 | 300 | 3600 or 86400 |
| MX | Don't touch | Don't touch | Don't touch |
| CNAME (www) | 300 | 300 | 3600 |
Don't change the MX record during a hosting migration. If email is on the same domain, changing MX mid-migration causes emails to be lost for several hours and pile up in the queue. Migrate email separately, in a different window.
The exact order of operations in a low-traffic window
Choose your time window based on your own stats, not on habit. If your site's traffic is lowest between 3 and 5 AM Tehran time, take that window. If your site has an international audience, this window is wrong and you should choose 10 AM to 12 PM UTC. One look at the hourly visit report is enough.
- Take a full backup and keep it somewhere else. Not on the same host. Download the tar.gz file and the database dump and check their sizes. A backup whose size is zero isn't a backup.
- Note the PHP and MySQL versions on the new plan. If your site is on PHP 7.4 and the new plan defaults to 8.2, test compatibility before migrating. The list of available extensions and how to test them is explained in checking PHP extensions on hosting.
- Bring the site up on the destination, but don't change DNS yet. Test the new site by editing the hosts file on your own system or with a temporary subdomain. This is the step where 90% of errors are found.
- Dump and restore the database. Use
mysqldump --single-transaction --routines --triggersso InnoDB tables don't get locked mid-operation. - Change DNS. Now that the TTL is low, propagation happens within minutes.
- Keep the old server running for at least 72 hours. Just to be safe. Then shut it down.
Take step three seriously. If you change DNS without testing and then find out the imagick extension isn't installed on the new plan, you'll have to roll back, and this time with real users on the site.
A point I see a lot in real migrations
People forget the wp-config.php file or its equivalent. The site comes up, the homepage opens, but every page that needs the database gives an "Error establishing a database connection" error. The reason is that the database connection info in the config file still points to the old server, or the database username on the new plan differs from the previous one. You'll see this error in the error log too, but many people only look at the web server log and find nothing.
Second case: absolute paths. If the path /home/olduser/public_html is hardcoded in the config or in the database, everything breaks on the new plan where the username has changed. Find and fix it before the migration with a simple search in the database.
When an upgrade doesn't help and you need a dedicated server
There's a real limitation that's rarely mentioned: if your site's CPU usage is consistently above the plan's share, a hosting plan upgrade only raises the ceiling a bit and two months later you hit the same wall again. The sign is that in the resource report, CPU usage hits the ceiling during peak hours and the pattern repeats even after the upgrade.
In this case you have two options. Either optimize the architecture (page cache, object cache, moving heavy processes out of the user request path), or move to a dedicated server where you don't have a shared ceiling. My choice is: optimize first, because it costs less and the result stays with you on any plan. If you're still hitting the ceiling after optimization, then go for a dedicated server. The reverse means paying more money for the same problem.
If the site is WordPress and only traffic has gone up, usually a proper page cache cuts CPU usage in half. Test this before making any purchase decision.
What to check after the migration
The migration isn't done until you've checked these:
- The SSL certificate is valid on the main domain and
www, and the expiry date is correct. If the HTTPS redirect is looping, the guide installing SSL on hosting explains the problem precisely. - Cron jobs have been created on the new plan. This is often forgotten, and a week later people find out automatic backups haven't been running.
- Transactional emails (contact form, password reset) are actually being sent. Send a real test, not just looking at the settings.
- Return the TTL to its previous value.
To check DNS propagation from multiple points, the DNS and network lookup tool makes quick work of it; you don't need to manually run dig from several different cities. And if you want to gauge how plans behave with a test site before making a final decision, free webmaster tools are a good starting point.
One last note about timing: if you have an e-commerce site and you're in the middle of a campaign, postpone the migration. No low-traffic window is worth as much as an active campaign. A hosting plan upgrade is a technical task, but its timing is a business decision.
Frequently asked questions
How long does a hosting plan upgrade take and will the site go down?
If the new plan is on the same server, usually less than a minute and with no noticeable downtime. If it's on a different server, the actual time depends on the size of the files and database and can range from a few minutes to several hours; in this case you minimize downtime by lowering the TTL and testing on the destination before changing DNS.
Why does the site still go to the old server after the migration?
Because the A record's TTL wasn't lowered before the migration and users' and resolvers' DNS caches still hold the old value. Until the previous TTL expires, some traffic goes to the old destination. The solution is to set the TTL to 300 seconds 24 to 48 hours before the migration.
Should I also change MX during a hosting migration?
No. Don't touch the MX record during a hosting migration, especially if email is on the same domain. Changing MX mid-operation causes emails to sit in the queue for hours or bounce back. Migrate email in a separate time window and after the site has stabilized.
How do I tell whether the problem is the plan or the site's code?
Look at the resource report during peak hours. If CPU and RAM usage are hitting the ceiling and database response time has gone up at the same time, the plan is probably too tight. If resource usage is low but the site stays slow, the problem is usually in the code, heavy queries, or the lack of caching, and upgrading the plan only increases cost.