Moving a website to a new VPS involves more than copying files and changing an IP address. A dynamic website can receive orders, uploads, bookings, and form submissions while the transfer is underway. Without a clear cutover plan, the old and new servers can end up holding different versions of that data.
This guide covers a hosting move that keeps the same public domain and page URLs. It explains how to prepare the destination, control writes, change routing, and recover if the launch fails. The goal is a predictable migration with a defined interruption window; zero downtime requires an architecture designed and tested for it.
Decide how live data will move
Before scheduling the migration, choose which system will accept writes at every stage. For a small application, a short maintenance window may be the most manageable approach: pause new writes, finish in-flight work, copy the final data, and reopen on the destination.
A larger system may use replication or a shared data service, but those approaches require application-specific testing. Database replication alone does not move uploaded files, queue state, or sessions. Write down how each changing component stays consistent.
- Identify the authoritative database during preparation and after launch.
- List local uploads, object storage, session storage, caches, and pending jobs.
- Decide what happens to incoming webhooks during maintenance.
- Assign a migration owner and a person who can approve rollback.
- Define success checks and the latest point at which a simple rollback is safe.
1. Inventory the application and its dependencies
Record runtime versions, extensions, database versions, web-server configuration, environment settings, scheduled tasks, worker services, and file permissions. Include outbound integrations, IP allowlists, and any software licenses tied to the server.
Check whether the domain also handles email. A website move does not automatically migrate mailboxes. Keep the existing mail routing unless moving email is an explicit part of the plan. For a broader source-platform inventory, read our cPanel migration planning guide.
Store configuration and credentials through your normal secure process. Keep database exports out of public web directories and avoid putting secrets into migration notes.
2. Build and test the destination before cutover
Prepare the new VPS with compatible application dependencies, sufficient capacity, and the required service configuration. Restore an initial copy of the database and files, then test application startup and connectivity.
Use an isolated test environment. Prevent test workers from processing real jobs or sending real customer messages, and avoid triggering live payments. Test login, permissions, file access, search, and a representative harmless workflow. Confirm that background services use the intended environment.
For deployment-specific preparation, see our guides to Laravel on Ubuntu, Node.js with Nginx and systemd, and Django with Gunicorn and Nginx.
3. Prepare DNS, HTTPS, and public routing
For DNS records that point directly to your origin, lower the TTL ahead of the move and allow the previous TTL to expire before cutover. Lowering it at the last minute does not invalidate records already cached under the older value. TTL controls cache lifetime; it does not make every visitor switch at the same instant. Check your provider's available settings; Cloudflare's TTL documentation also distinguishes proxied and DNS-only records.
Review both A and AAAA records. Leaving an old IPv6 destination in place can send some clients to the previous server. If a CDN or load balancer sits in front of the application, identify its origin-routing settings as well.
Verify that the destination can serve valid HTTPS for the public hostname before directing users to it. Test the correct hostname and certificate, rather than relying on an IP-only request. Avoid changing DNS providers or nameservers at the same time unless the migration requires it.
4. Take and verify a recovery backup
Create a backup that covers the application, database, uploads, and required configuration. Check that you can restore it in an isolated environment. Record its creation time and the data interval it represents.
Use the database engine's supported backup process. Copying live database storage files without an appropriate consistency procedure can produce an unusable backup. Our PostgreSQL restore testing guide covers related verification steps.
5. Run a controlled final synchronization
For a migration using a maintenance window, follow a sequence that prevents competing writes:
- Put the old application into the planned maintenance or read-only state.
- Pause write-producing scheduled tasks and workers, and account for in-flight requests and jobs.
- Take the final consistent database backup and synchronize changing files.
- Restore the final data on the destination and verify important records and uploaded files.
- Confirm that only the intended production workers and scheduled tasks will run.
- Change routing, verify the destination, and enable writes there.
A maintenance page alone may not stop API requests, admin updates, webhooks, or background workers. Check every write path. Document whether incoming events are buffered, retried by their sender, or need later reconciliation.
Keep the old server from accepting independent writes while cached routing still sends users to it. Depending on your setup, it can remain in maintenance mode or forward requests to the new application through a tested proxy configuration. Do not let two independent database copies accept production updates.
6. Verify the cutover with real evidence
Check the public domain from outside your network, then verify that the destination receives the requests. Validate the important customer workflows with safe test data. Look for missing assets, session problems, permission errors, failed email delivery, and integration allowlist failures.
Compare error rates and response times with the pre-migration baseline. Inspect job processing and scheduled-task completion too. Use our VPS monitoring checklist to organize these checks.
When URLs stay unchanged, preserve canonical tags, robots rules, sitemaps, and ownership verification. Remove temporary indexing restrictions from the production copy. Google's hosting-change guidance recommends monitoring both hosting environments and retiring the old one after traffic has moved successfully.
7. Plan rollback around new data
Rollback is easiest before the destination accepts production writes. Once it receives an order or upload, the old copy may be stale. Changing DNS back without reconciling that data can lose updates or cause duplicate processing.
Define two recovery paths: a pre-write rollback to the verified source, and a post-write recovery that preserves new records and files. For the second path, you may need to pause writes again, synchronize data back, or repair the destination instead of reversing routing. Test the chosen approach for your application.
Remember that a routing reversal also takes time to reach cached clients. Keep both endpoints in a controlled state while it settles, with one authoritative write destination.
After the migration
Confirm that backups now run on the new VPS and that monitoring points to the right services. Review worker ownership, scheduled tasks, notification delivery, and access permissions. Retain the old environment for the planned recovery period, restrict its access, and retire it when the evidence and recovery plan support doing so.
Frequently asked questions
Can I migrate a website without downtime?
Sometimes, but it depends on the application and data architecture. A live migration needs consistent data, controlled write ownership, and tested routing. A short announced maintenance window is often easier to manage for a small dynamic site.
Does changing DNS move my database?
No. DNS changes where traffic is directed. You must transfer or connect the database separately and verify that the destination application uses the intended data.
Should I immediately delete the old VPS?
Keep it until traffic, recovery readiness, and your retention plan justify retirement. Remove its ability to process independent production writes or duplicate jobs during that period.
Will a new server IP change my page URLs?
A hosting move can keep the domain and page paths unchanged. A domain or URL-structure change is a separate migration task and requires its own redirect and search-engine plan.
Make the cutover repeatable
A reliable VPS migration has a tested destination, a consistent final data copy, one write authority, and a rollback process that protects new updates. Keep those decisions in a short runbook before changing routing. Explore Core Panel and our hosting guides for more production deployment and operations advice.
