Moving from shared hosting to a virtual private server can improve performance, flexibility and control—but only if the migration is carefully planned. Files, databases, DNS, SSL certificates, scheduled tasks and email settings must all reach the new environment without losing recent data or interrupting visitors.
The safest approach is to build and test the VPS while the existing site remains live, synchronize the data in stages, and change DNS only when the new server is ready. This blueprint explains how to complete each phase while preserving a practical rollback path.
Introduction to VPS and Shared Hosting#
Shared hosting places multiple customers on the same server environment. The provider handles most system administration, making it convenient for new websites and users who do not want to manage an operating system, firewall or web server.
A VPS also runs on shared physical infrastructure, but virtualization provides an isolated environment with an allocated share of CPU, memory and storage. Depending on the service, you may receive administrative or root access and responsibility for configuring the server.
Attribute | Shared hosting | VPS hosting |
|---|---|---|
Resources | Shared across accounts | Allocated to the VPS |
Server control | Limited | Administrative access |
Software choices | Provider-controlled | Configurable |
Maintenance | Mostly provider-managed | Managed or self-managed |
Scaling | Plan-dependent | More flexible |
Best suited to | Small, simpler sites | Growing or custom workloads |
A VPS offers greater control, but that control creates more operational responsibility. You must know who will handle security updates, monitoring, backups and troubleshooting before migrating.
Common signals that a site has outgrown shared hosting include slow responses during busy periods, recurring resource-limit errors, background processes being terminated and an inability to install required runtime versions or extensions. A VPS may also be appropriate when an application needs custom firewall rules, workers or server-level caching.
Benefits of Moving to VPS#
The main benefit of a VPS is a more predictable environment. Another shared-hosting account is less likely to consume the CPU, memory or disk capacity assigned to your server. This can make performance more consistent during traffic spikes, although application design and correct server sizing still matter.
A VPS can also provide:
- Stack control: Select the web server, database engine, PHP or application runtime, extensions and caching services.
- Security flexibility: Define firewall rules, restrict SSH access and apply an update policy suitable for the application.
- Resource visibility: Monitor CPU, memory, disk usage, load and individual processes.
- Application support: Run queues, workers, custom services and scheduled jobs that shared hosting may restrict.
- Scalability: Increase resources when traffic or database requirements grow.
These advantages do not automatically make a website faster. An undersized or poorly configured VPS can perform worse than a well-managed shared platform. Measure current usage, allow capacity for peak demand and decide whether you need a managed service or have the expertise for server administration.
Preparing for Migration: Key Considerations#
Begin with an inventory. Record every domain and subdomain, document root, database, runtime version, extension, cron job and email account. Export the complete DNS zone, including A, AAAA, CNAME, MX and TXT records used for SPF, DKIM, DMARC or service verification.
Inspect the application for absolute paths, hard-coded IP addresses and environment-specific URLs. Record the current PHP or runtime version, database engine and character set. Version mismatches and missing extensions frequently produce failures that are not immediately obvious, such as broken redirects, empty forms or unavailable administrative features.
Create an off-server backup of files and databases, then verify it. A backup should not be considered usable until its archive integrity or restore process has been tested. Keep the old hosting account active for at least one to two weeks after cutover so it remains available as a rollback option.
Plan the migration timeline around the website’s activity. Preparation and initial synchronization may take one or two days, while final synchronization, DNS cutover and validation can require several hours. Busy stores, membership sites and forums need a short write freeze or maintenance window so orders, comments and account updates are not split across two databases.
Lower the TTL on the site’s A and AAAA records to approximately 300 seconds at least 24 hours before cutover—ideally 48 hours. Existing resolvers must first allow the previous, longer TTL to expire, so changing it five minutes before migration will not accelerate those cached responses.
Step-by-Step Migration Guide#
1. Provision and secure the VPS. Install a supported operating system and the required web server, runtime and database engine. Match the old environment where compatibility is uncertain; upgrades can be performed separately after the migration is stable.
Create a non-root administrative user, use SSH keys, restrict exposed ports, enable security updates and configure log rotation. Before copying production data, confirm there is enough storage for the site, database, logs and temporary migration files.
For an Ubuntu-based server, these commands create an administrative user and enable a basic firewall. Adapt them to the VPS operating system and access policy.
adduser deploy
usermod -aG sudo deploy
ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enableKeep the active SSH session open while testing a second connection. This reduces the risk of locking yourself out after changing firewall or SSH settings.
2. Configure the web stack. Create the virtual host, document root and database credentials. Install the same required extensions used by the old site, then set suitable file ownership and permissions. Do not blindly copy permissions such as 777; grant only the access the web process needs.
3. Perform the initial file transfer. Use a secure transfer method that preserves timestamps and permissions where appropriate. An initial rsync pass can move most data while the existing website remains available.
This command synchronizes a site directory over SSH:
rsync -aH --delete -e ssh ./public_html/ deploy@203.0.113.10:/var/www/example.com/Use --delete only after confirming that the destination path is correct because it removes destination files that are absent from the source.
4. Export and import the database. Use the database engine’s native tools, preserve character encoding and avoid editing the dump unless necessary. For MySQL or MariaDB, create a consistent export and transfer it securely.
These commands export, copy and import the database:
mysqldump --single-transaction --routines --triggers example_db > example_db.sql
scp example_db.sql deploy@203.0.113.10:/tmp/example_db.sql
mysql example_db < /tmp/example_db.sqlRun the final import on the new VPS using an account with the required database permissions. Remove temporary dumps after verification because they may contain private user or application data.
5. Update application configuration. Set the new database host, credentials, cache endpoints and file paths. Keep secrets outside the public document root. If URLs have changed, use an application-aware migration tool; unrestricted search-and-replace can corrupt serialized data.
6. Configure HTTPS and supporting services. Install a valid certificate for every hostname, configure redirects deliberately and verify the full certificate chain. Recreate cron jobs, workers and queues, but avoid enabling tasks that could send duplicate messages or process the same jobs while the old server is still active.
7. Run a final synchronization. At cutover, pause writes or place the old site in maintenance mode. Repeat the file synchronization, export the latest database and import it into the VPS. Then change the relevant DNS records to the new IP address.
If email is staying with the current provider, preserve its MX and related TXT records. If it is moving, migrate mailboxes and verify SPF, DKIM and DMARC before directing mail to the new service.
Testing Your New VPS Setup#
Test privately before changing public DNS. Add a temporary hosts-file entry on your computer so example.com resolves to the VPS only for that device.
Add this line to the system’s hosts file:
203.0.113.10 example.com www.example.comClear the local DNS cache or restart the browser if necessary. Then test both anonymous and authenticated workflows, including:
- Homepage, internal pages and assets
- Login, logout and password reset
- Forms and transactional email
- Search, checkout or other dynamic functions
- File uploads and generated downloads
- Administrative actions and scheduled jobs
- HTTP-to-HTTPS and canonical redirects
- Mobile layouts and third-party integrations
Watch the web server, application and database logs while testing. A page returning 200 does not prove that background jobs, email delivery or write operations work.
Check the public response after DNS cutover with these commands:
dig +short example.com
curl -I https://example.com
curl -I https://www.example.comConfirm that the returned IP is the VPS and that expected redirects do not form a loop. Test from another network as well, since different resolvers may retain old DNS answers for different periods.
Common Pitfalls and How to Avoid Them#
Migration failures often come from overlooked dependencies rather than the main file transfer.
Pitfall | Likely symptom | Prevention |
|---|---|---|
Runtime mismatch | Errors or blank pages | Match versions and extensions |
Incomplete database copy | Missing recent records | Freeze writes and perform final export |
Wrong permissions | Upload or cache failures | Set ownership deliberately |
Missing DNS records | Broken mail or verification | Copy and compare the full zone |
Hard-coded IPs or paths | Partial feature failures | Audit code and configuration |
Duplicate cron jobs | Repeated emails or tasks | Enable jobs on only one server |
Premature cancellation | No rollback route | Retain old hosting temporarily |
Email deserves special attention. Changing nameservers without reproducing every MX, SPF, DKIM and DMARC record can interrupt delivery even when the website works perfectly.
Avoid combining migration with major application, operating-system and database upgrades. Each extra change makes diagnosis harder. First reproduce a compatible environment, migrate and stabilize it; optimize and upgrade afterward with separate backups and testing.
Ensuring Minimal Downtime#
Minimal downtime depends on doing nearly all work before the DNS switch. Keep the shared-hosting site live while provisioning the VPS, completing the first file transfer, importing a database copy and running private tests.
At the agreed cutover time:
- Stop or temporarily restrict writes on the old site.
- Run the final file and database synchronization.
- Verify configuration, HTTPS and essential services.
- Update the
AandAAAArecords. - Monitor both environments until traffic shifts.
A migration survey reported that approximately 26.5% of organizations could not afford any downtime during cutover. For sites with that requirement, DNS alone is not a complete zero-downtime mechanism because cached records can send users to either server. You may need temporary replication, a reverse proxy or another architecture that keeps writes consistent across both locations.
Do not alter content independently on both servers. If some visitors still reach the old IP, either keep that site read-only or forward it to the new infrastructure where practical.
Post-Migration Checklist and Optimization#
Monitor the VPS closely for the first several days. Review CPU, memory, swap, disk capacity, disk I/O and database activity during both normal and peak traffic. Investigate sustained limits rather than immediately adding resources; inefficient queries, runaway workers and aggressive bots can consume any server size.
Verify that backups run automatically to a separate location. Include databases, application files, configuration and any user-generated content, then perform a test restoration. A successful backup job notification does not guarantee recoverability.
Complete the transition by:
- Checking error, access, application and authentication logs
- Confirming forms, mail delivery and mailbox access
- Verifying cron jobs, queues, webhooks and external APIs
- Scanning for malware and applying pending security updates
- Enabling uptime and resource alerts
- Confirming canonical URLs, redirects and HTTPS behavior
- Searching configuration and DNS for references to the old IP
- Restoring DNS TTL values after traffic has stabilized
Keep the previous server available until logs and DNS checks show that meaningful traffic has stopped reaching it. Before cancellation, take one final archive and store the former server configuration securely. Remove temporary database dumps, migration users, test hostnames and firewall exceptions from the VPS.
Performance tuning should come last. Establish a baseline, then adjust caching, database settings, compression or worker limits one change at a time. This makes it possible to measure the effect and reverse harmful changes.
Conclusion#
A successful shared-hosting-to-VPS migration is not a single copy operation. It is a controlled sequence: inventory the existing environment, build a compatible and secure VPS, synchronize data in stages, test privately, freeze writes briefly, update DNS and monitor both servers.
The old hosting account provides your safety net, while verified backups protect against data loss. When you are ready to gain more control over your hosting environment, explore your next steps with Ruachost.
