migration
How to Move VPS to Another Provider Without Breaking Your Server
A plain-English migration plan for moving your server to another provider without losing files, domains, HTTPS, or your sanity.
You want a better provider, a cheaper bill, or a faster machine, but you are afraid one wrong step will make your site disappear.
Short version: to move a server to another provider, you copy the application, database, uploads, certificates, environment settings, firewall rules, and scheduled jobs to the new server before changing DNS. Then you test the new server, lower the chance of stale DNS records, switch the domain, and keep the old server running until you are sure traffic has moved. The safe move is not one big leap; it is more like opening the new shop before taking the sign off the old one.
What can break when you move a server?
A server is not just “the website files.” It is more like a small restaurant: the menu, the kitchen, the fridge, the door sign, the phone line, and the delivery schedule all matter.
When you change provider, the obvious thing to copy is the app code. The less obvious things are usually what cause pain: the database, uploaded images, background jobs, secret environment values, email settings, firewall rules, and HTTPS certificates.
The domain also has to point to the new server. That happens through DNS, the internet’s address book. If the DNS A record or AAAA record still points at the old server, visitors keep going there. If the web server, such as nginx, points to the wrong internal service, you may see the literal error string “502 Bad Gateway.” If the certificate is missing or for the wrong domain, the browser may show an HTTPS warning even though the app itself is fine.
So the move is not only “copy and paste.” It is copying the whole living setup.
What should you copy before you touch DNS?
Before you change the domain, make a list of what makes the current server work. This is where a migration becomes calm instead of dramatic.
If you do not already have a restorable backup, start there. A backup that has never been restored is a hopeful file, not a safety net. We covered this in more detail in how to back up your server.
| What to move | Why it matters | Common mistake |
|---|---|---|
| Application files | They run the site or app | Copying old code but missing generated files |
| Database | It holds posts, users, orders, settings | Exporting it too early while people keep changing data |
| Uploads and media | They hold images, documents, avatars | Moving the database but not the files it references |
| Environment settings | They hold secrets and service addresses | Forgetting payment, email, storage, or API keys |
| Scheduled jobs | They send emails, renew data, clear queues | Site loads, but background work silently stops |
Also check the firewall, which is the locked front door of the server. If the new server blocks web traffic, the site will not load. If it allows too much, you may expose services that should stay private.
How do you keep the website online during the move?
Treat the new server as a rehearsal room before it becomes the main stage.
First, prepare the new server while the old one is still serving visitors. Install or recreate the same app, copy the latest data, and test it away from the public domain if possible. You want to find missing files, wrong database passwords, broken uploads, and “502 Bad Gateway” on the new server before real visitors hit it.
Second, think about DNS TTL. TTL means “time to live,” or how long other systems are allowed to remember the old address. A lower TTL before the move can make the final switch settle faster. When you are ready, update the domain’s A record and, if you use IPv6, the AAAA record. If the domain part is fuzzy, read how to point a domain at your server.
Third, keep the old server running for a while. Some visitors, bots, or external services may still reach the old address during the changeover. If your site accepts orders, comments, bookings, or account changes, plan a short content freeze or a final database sync so updates do not split between two places.
Finally, check HTTPS. Let’s Encrypt certificates are tied to domain validation, so the new server must be able to prove it controls the domain. A correct app with a wrong or expired certificate still looks broken to a visitor. If you need the basics, see how to get free HTTPS on your own server.
How do you check the new server is really the same?
Do not only check the homepage. The homepage is the shop window; many failures hide in the stockroom.
Log in. Submit a form. Upload a file. Reset a password. Place a test order if you run a store. Check admin pages, private pages, webhooks, email sending, and scheduled jobs. If your app uses queues, make sure queued work is actually being processed.
Watch for differences that feel small but matter: wrong file permissions, missing image thumbnails, hardcoded old server addresses, a firewall blocking a payment provider callback, or an app trying to connect to the old database.
A clean move ends with the new server handling the full job, not just showing the first page.
FAQ
Can I move without downtime? Usually, yes, or close to it. The key is preparing the new server first, lowering DNS memory, and doing a final data sync before the domain switch.
Should I shut down the old server right away? No. Keep it for a short safety window so you can compare behavior, catch missed traffic, and recover anything you forgot.
What if my database changes during the move? Use a short content freeze, maintenance window, or final sync. Otherwise new comments, orders, or uploads may land on the old server after you copied the data.
Why does my site show an HTTPS warning after moving? The new server may not have the right certificate yet, or DNS may still point some visitors to the old address. Check the domain records and certificate status.
The shortcut
Server Manager helps by keeping the shape of your server understandable while you move. Instead of rediscovering months later which domain belongs to which project, which app needs HTTPS, and which setup detail was important, you have a clearer picture of what is running and where it points.
That matters during a provider switch because the common failures are practical: a domain still pointing at the old server, a wrong or expired certificate, one project breaking another, or a setup that no longer makes sense when you revisit it. The real benefit is that the move stays legible, so you can compare old and new without guessing.
You still own the decision and the server. The outcome is a quieter migration: fewer hidden pieces, fewer surprises, and a setup you can understand again after the move is over.
What does a clean provider switch feel like?
A good move is boring in the best way. Visitors keep reaching the site, HTTPS stays trusted, uploads still appear, emails still send, and the old server can be retired without panic.
You are not trying to be perfect. You are trying to move the whole working system, test it before the switch, and leave yourself a way back until the new server has proved itself.