Shared hosting makes sense when you are launching: the price is low, the provider handles the server, and you only worry about your files. But the model has hard limits. Your site shares CPU, memory and disk with other tenants, you cannot install the software or PHP extensions you need, and a busy neighbour can slow your pages down. When you need predictable resources, a dedicated IPv4 address and full control over the environment, a VPS is the natural next step.
Moving servers sounds like a risky operation, but it does not have to be. The trick is to prepare the new environment while the old one keeps running, then switch only when everything is tested. This article gives you a step-by-step plan that works for typical shared-hosting setups: an application, a database, scheduled tasks, uploads and DNS records.
Open Vista offers NVMe VPS plans billed in US dollars with no contract, from $9.99 per month for the VPS-1G up to $49.99 for the VPS-5G. Every plan includes a dedicated IPv4 address, a management panel, automatic backups and 24/7 support in English and French, and a server is deployed in under 15 minutes. That speed matters here: you can have your target environment ready and tested before you announce any change.
Step 1: Inventory Everything Before You Touch Anything
Most failed migrations are not caused by missing files; they are caused by items that were never written down. Before ordering anything, produce a complete inventory of what your site depends on:
- Web files, uploads and media directories, including exact paths.
- Databases: engine, names, users and sizes.
- Scheduled tasks (cron jobs) and the commands they run.
- Rewrite rules — `.htaccess` on Apache-style hosts, or equivalent nginx rules.
- Environment variables and secrets stored in configuration files.
- SSL certificates and the domains they cover.
- DNS records: the full zone, including A, CNAME, MX and TXT records such as SPF and DKIM.
- Mailboxes, if email is hosted on the same shared account.
Export a copy of the DNS zone before you start. Note which items depend on the old host's internal paths, because those are the ones that break during a move. This list also helps you decide what stays behind: many teams keep mail on the old host while the website moves, and migrate mailboxes later.
Step 2: Prepare and Test the New VPS Environment
Order the VPS plan that matches the workload. For most sites leaving shared hosting, the VPS-2G (1 vCPU, 2 GB RAM, 40 GB NVMe) is a comfortable starting point; if you run several applications or expect fast growth, look at the VPS-3G (2 vCPU, 3 GB RAM, 50 GB NVMe), the most popular plan. Compare the full lineup at openvista.ma/en/vps and order at my.openvista.ma.
Once the server is deployed, prepare it calmly:
- Connect over SSH and create a non-root user with sudo rights.
- Configure key-based authentication; keep password login disabled or restricted.
- Apply all operating-system updates before installing anything else.
- Install your stack — web server, PHP or your runtime, database — and match the versions used on the old host as closely as possible. Version gaps are a frequent source of migration surprises.
- Configure the firewall to allow only SSH, HTTP and HTTPS at first.
- Confirm that automatic backups are enabled on the new plan and secure access to the management panel.
Do all of this before migration day. You want a known-good base you can test against, not a server you configure while your site is supposed to be switching over.
Step 3: Move the Data in Three Passes
Pass 1 — Files. Use rsync over SSH. It preserves permissions and can be resumed if interrupted:
```bash
rsync -avz --progress /path/to/public_html/ user@new-server:/var/www/your-site/
```
Run it several times during preparation, then one final sync just before cutover. For very large archives, a compressed tar transferred once also works.
Pass 2 — Database. Export the database with `mysqldump` (or the equivalent for your engine), transfer the dump and import it on the new server. Create a dedicated application user with the least privileges needed, then verify row counts on key tables.
Pass 3 — Configuration. Update paths, domain values and secrets in the application configuration so they point to the new environment. Compare PHP settings such as `memory_limit` and `upload_max_filesize`. Watch for hardcoded absolute URLs stored in the database — plan a careful search-and-replace. Test the application against the new database before the DNS switch, using a local hosts entry or a temporary subdomain.
Document every manual change you make along the way, so the process stays repeatable — and use `--delete` in rsync only when you are certain the source is the reference copy.
Step 4: Switch DNS and Go Live
- Lower the TTL of the records you will change at least 24 to 48 hours in advance, so the new values propagate quickly.
- Make sure an SSL certificate is already issued and working on the new server; HTTPS should be live from the first moment of the switch.
- On cutover day, point the A record at your new dedicated IPv4 address.
- Watch the application logs, web-server error logs and database connections during the first hours.
- Keep the old hosting active for the overlap period — typically two to four weeks — and keep a rollback note: if something is wrong, pointing DNS back restores the previous setup quickly.
- Only change MX, SPF and DKIM records if email moved with you. If mail stays on the old host, leave those records untouched.
Post-Migration Checklist
- [ ] All pages load over HTTPS on the new server.
- [ ] Forms and transactional emails work; SPF and DKIM verified if mail moved.
- [ ] Cron jobs run and logs show successful executions.
- [ ] Automatic backups confirmed active on the new VPS.
- [ ] Hardcoded URLs replaced and tested.
- [ ] Old hosting still available for rollback.
- [ ] Rollback note written and stored with DNS credentials.
- [ ] Monitoring and regular log review scheduled.
FAQ
How long does a migration from shared hosting to a VPS take? For a typical website — a few gigabytes of files and one database — the transfer takes from minutes to a couple of hours depending on bandwidth. Plan a maintenance window, but because the new server is ready before the DNS switch, most of the work happens with no impact on visitors.
Will my site have downtime? Not from the migration itself. DNS propagation can briefly route some visitors to the old host and others to the new one; keeping both live during the overlap makes that harmless. Propagation speed depends on resolvers and the TTL you set.
Do I have to move email at the same time? No. If your mailboxes stay on the shared host temporarily, leave the MX records unchanged and migrate mail later. Only the web-facing records change on day one.
What if something breaks after the switch? The old hosting is still running, so you can point DNS back and troubleshoot from a stable position. Because automatic backups exist on the new VPS, you can also restore and retry without pressure.
Migration is a one-time project, but the hosting you land on is a long-term decision. Open Vista's NVMe VPS plans are billed in US dollars with no contract, and every plan comes with a dedicated IPv4 address, a management panel, automatic backups and 24/7 support in English and French. See the full lineup at https://openvista.ma/en/vps and order your server in minutes at my.openvista.ma.