Managed Hosting Cutover Checklist for Agency Clients

When a managed hosting cutover needs to be boring

If you run client sites, the best cutover is the one nobody notices. A managed hosting cutover checklist gives you a controlled way to move a live account, keep mail and DNS aligned, and roll back quickly if something breaks. This tutorial is built for agency handovers on Hostperl managed VPS hosting, where support response time, clean migration notes, and launch-day accountability matter.

We will build a safe cutover path on Ubuntu Server 24.04. You will create a non-root admin, prepare SSH access, verify services, stage the destination server, lower DNS TTLs, move the site, test it, and switch traffic only after checks pass. If you need a broader operational backdrop, Hostperl's Hostperl VPS hosting is a good fit for agency workflows that need repeatable migrations and clear support boundaries.

For readers who also need a migration playbook for nearby control-panel work, the existing guides cPanel account operations for clean hosting migrations and regional hosting support that agencies can actually rely on are useful companions. This tutorial stays focused on the cutover itself.

What you are protecting during the cutover

A managed hosting handover usually fails in one of four places: stale DNS, missing files, broken database credentials, or a bad TLS setup. The checklist below avoids all four. It also gives you a rollback path, which matters when a client has a launch window and will not accept a long outage.

• Goal: move a live site from an old server to a new managed VPS with minimal downtime.
• Assumption: you have root access on the new server and access to the old server for data export.
• Target OS: Ubuntu Server 24.04.
• Services in scope: SSH, Nginx, PHP-FPM or an app runtime, firewall rules, DNS, and TLS.

Step 1: Connect to the new server and confirm the OS

On your local computer, open an SSH session to the new server.

ssh root@203.0.113.10

Replace 203.0.113.10 with the public IP assigned to your server. This example uses a reserved documentation address.

On the VPS as root, confirm the platform before you change anything.

cat /etc/os-release

You should see Ubuntu 24.04 fields in the output. If you do not, stop here and adapt package names before continuing.

Step 2: Create the deployment user and keep root as fallback

Do not disable root yet. Keep the original session open until the new user proves it can connect and use sudo.

On the VPS as root, create the non-root admin account and add it to sudo.

adduser deploy

Choose a strong password when prompted. Then grant sudo access.

usermod -aG sudo deploy

Now prepare SSH access.

mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

If you do not already have root key-based access, add the public key manually to /home/deploy/.ssh/authorized_keys using your preferred editor. Keep permissions strict. Loose permissions will cause SSH to reject the key.

On your local computer, open a second terminal and test the new account before you touch SSH policy.

ssh deploy@203.0.113.10

Then test sudo on the server.

sudo -v

If that succeeds, you have a safe fallback. Leave the root session open until the cutover is complete.

Step 3: Update packages and set baseline tools

On the VPS as the non-root sudo user, refresh package metadata and install the tools used later in the cutover.

sudo apt update
sudo apt -y upgrade
sudo apt -y install nginx ufw rsync curl unzip ca-certificates

This gives you the web server, firewall, file sync, and test tools you need. On Ubuntu, keep package work in the same session so you can see any held-back packages or errors immediately.

Check the service status now so you know the host booted cleanly.

systemctl status nginx --no-pager

If Nginx is not yet enabled, that is fine. You are checking that systemd is healthy and the package installed without conflict.

Step 4: Build the firewall before exposing the site

Open SSH first, then web ports. That order prevents a lockout.

On the VPS as the non-root sudo user, allow SSH and the web ports with UFW.

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

You should see OpenSSH, 80/tcp, and 443/tcp allowed. If you use a custom SSH port, open that port before you close the current one.

Step 5: Prepare the target web root and a safe Nginx vhost

For a client handover, keep the application files in a clear path. Here we will use /opt/myapp as the example site directory.

On the VPS as the non-root sudo user, create the site structure.

sudo mkdir -p /opt/myapp/public /opt/myapp/logs
sudo chown -R deploy:deploy /opt/myapp

Now write a minimal Nginx server block that will serve a maintenance page until the live data is copied.

sudo nano /etc/nginx/sites-available/myapp

Use this file content:

server {
    listen 80;
    server_name example.com www.example.com;
    root /opt/myapp/public;
    index index.html;

    access_log /var/log/nginx/myapp-access.log;
    error_log /var/log/nginx/myapp-error.log;

    location / {
        try_files $uri $uri/ =404;
    }
}

Save and exit the editor, then enable the site.

sudo ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/myapp
sudo nginx -t
sudo systemctl reload nginx

The syntax test must pass before reload. If it does, Nginx will serve the empty site without breaking the host.

Step 6: Lower DNS TTL before the move

A cutover is easier when DNS changes propagate quickly. If your DNS provider supports it, reduce the A and AAAA record TTL to 300 seconds at least a few hours before the switch. If you manage DNS through a registrar or a separate DNS host, change the records there now, not during the final window.

This step is administrative rather than shell-based, but it is part of the cutover checklist because it directly affects downtime. Keep the old server alive until propagation is complete.

Step 7: Sync the site from the old server

Choose a transfer method that preserves ownership and timestamps. For most agency handovers, rsync is simpler than a tarball.

On the VPS as the non-root sudo user, pull the site files from the old server.

rsync -aHAX --delete deploy@198.51.100.20:/var/www/client-site/ /opt/myapp/public/

Replace 198.51.100.20 and the source path with the old server's real values. This example is a placeholder for the previous host. The --delete flag removes files that no longer belong in the new site, so use it only when the source is authoritative.

After the copy, confirm the files are there.

ls -la /opt/myapp/public | head

Step 8: Move the database and test credentials

If the site uses a database, export it from the old host and import it to the new one. A typical migration flow is dump, transfer, import, then application config update. The exact commands depend on the database engine, but the sequence stays the same.

For a MySQL or MariaDB-backed site, validate the dump on the source first, then import it on the target. If the app uses environment files, update only the DB host, username, password, and socket or port values. Do not change application secrets during a routine cutover unless you are intentionally rotating them.

After the import, run the application's own health check or at minimum log in to the database and confirm the expected schema exists.

Step 9: Add TLS after the site responds on HTTP

Do not request a certificate until the hostname resolves to the new server. Otherwise, Let's Encrypt validation can fail and waste time during the launch window.

On the VPS as the non-root sudo user, install Certbot and request the certificate once DNS points correctly.

sudo apt -y install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

The installer should detect the Nginx site and add HTTPS support. Confirm renewal configuration after it finishes.

sudo certbot renew --dry-run

If the dry run passes, the certificate can renew automatically before it expires.

Step 10: Run the smoke tests before you switch traffic

Test both the server and the application. A handover is not complete until you prove the site responds on the new IP.

On the VPS as the non-root sudo user, check the local web response and logs.

curl -I http://localhost
sudo tail -n 50 /var/log/nginx/myapp-error.log

Now test from your local computer against the public address.

curl -I http://203.0.113.10

You should see a valid HTTP response from the new host. If the site is using HTTPS already, test the certificate and redirect path after DNS propagation.

Step 11: Switch DNS and watch for issues

Update the live A and AAAA records to the new server. Keep the old host online for at least one TTL window, and longer if email or external integrations still point to it. During that window, check access logs on both servers so you can tell whether traffic is still arriving at the old endpoint.

If you need a practical reminder of how launch-day support gets messy, the guide on systemd service troubleshooting on Linux servers is useful when an app starts under load but fails after the move.

Step 12: Lock in the new baseline and keep rollback ready

Once the site is stable, tighten the server policy. You can now consider disabling password login, removing root SSH access, or narrowing firewall rules, but do that only after you have a second verified login path and a documented recovery method.

Rollback plan: if the new server fails, point DNS back to the old server, keep the old data unchanged, and reverse any database writes made after the switch window. This is why you do not wipe the source host until the client confirms the cutover is good.

Verification checklist

• SSH works for the new deploy user.
• sudo works without prompting for a missing rule.
• UFW allows SSH, HTTP, and HTTPS.
• Nginx passes nginx -t.
• The site answers on localhost and on the public IP.
• The certificate dry run succeeds.
• DNS points to the new server and remains stable for at least one TTL cycle.
• The old server still exists long enough to roll back if needed.

Troubleshooting the most likely failures

Problem: SSH key login fails. Run:

ls -ld /home/deploy /home/deploy/.ssh /home/deploy/.ssh/authorized_keys

Expected clue: permissions should be 755 or tighter on the home directory, 700 on .ssh, and 600 on authorized_keys. If not, fix them with:

sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys

Problem: Nginx reload fails. Run:

sudo nginx -t

Expected clue: the error line will usually name the file and line number. Correct the config, then reload again.

Problem: the site works on localhost but not publicly. Run:

sudo ufw status verbose
ss -ltnp | grep -E ':80|:443'

Expected clue: the firewall or listener is missing. Open the port or fix the service binding, then retest from your local computer.

Problem: TLS issuance fails. Run:

dig +short example.com
sudo certbot certificates

Expected clue: DNS may still point to the old server, or the webroot is not reachable. Wait for propagation or correct the Nginx vhost before retrying.

FAQ

Should I disable the old server immediately after DNS changes?
Not yet. Keep it online until you have at least one TTL window of clean traffic and no missed writes.

Do I need to lower TTL for every record?
Lower the records that control web traffic at minimum. If mail or API endpoints also move, include those too.

Can I cut over without TLS first?
Yes, but only briefly. Move the site, confirm it serves on HTTP, then issue the certificate as soon as DNS is stable.

What is the safest rollback action?
Point DNS back to the old server and preserve the old data. Do not destroy the source until the client confirms the new host is correct.