Managed Reseller Hosting Cutover Checklist for openSUSE Leap

When a reseller move needs a controlled cutover

This tutorial walks through a managed reseller hosting cutover on openSUSE Leap without losing account access, DNS control, or service continuity. The aim is straightforward: move the reseller setup to a new server, confirm the panel and customer accounts work, and switch traffic only after the new host is ready.

Because this run uses openSUSE Leap, the commands below use zypper, firewalld, and systemd. If your environment includes customer mail routing or DNS changes, review DNSSEC and email authentication guidance before you change nameservers. If you are planning the move as part of a larger agency workflow, managed handover planning for agencies is also worth reading.

For Hostperl customers, this kind of move is usually about more than copying files. You want to keep support tickets low, avoid password resets, preserve billing and client access, and make sure the first login on the new server behaves as expected. If you need a managed platform for the new environment, Hostperl VPS hosting is a practical place to start: Hostperl VPS hosting.

What you should have before you start

• An active openSUSE Leap server and shell access as root.
• A second terminal on your local computer for SSH testing.
• The reseller panel credentials or migration method you will use.
• DNS access for the domain or nameserver zone you will update.
• A rollback plan that keeps the old server untouched until the new server is validated.

This procedure assumes a fresh host at 203.0.113.10. That IP is only documentation shorthand. Replace it with the real public IP assigned to your server.

ssh root@203.0.113.10

Run that on your local computer first. Keep the original root session open until the new login and service checks succeed.

Confirm the operating system and update the server

Run the OS check immediately after login so you do not apply the wrong package commands. On openSUSE Leap, use the release file shown below.

cat /etc/os-release

You should see NAME="openSUSE Leap" in the output. If you do, continue with the update.

zypper refresh
zypper update -y

Run this on the VPS as root. A successful update finishes without held packages or repository errors. If the kernel updates, schedule a reboot after the cutover window, not before verification.

Create a non-root admin before changing anything else

Do not disable root until the new admin login works from a second terminal. openSUSE Leap uses the wheel group for sudo access.

useradd -m -G wheel -s /bin/bash deploy
passwd deploy

Run this on the VPS as root. Set a strong password for the temporary test. If your environment uses SSH keys only, you can lock the password after key login is confirmed.

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

This copies the current root key into the new account for a safe login test. If you prefer a separate key, replace the copy step with your own public key content.

Now open a second terminal on your local computer and test the new account.

ssh deploy@203.0.113.10

After login, confirm sudo works.

sudo -v
whoami
pwd

You should see deploy from whoami, and sudo should accept your password. Keep the root session open until this succeeds.

Prepare firewall access for panel and support traffic

Reseller environments usually need SSH plus panel and web ports. On openSUSE Leap, firewalld is the cleanest option for a managed cutover because it is easy to audit and adjust.

systemctl enable --now firewalld
firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reload
firewall-cmd --list-all

Run this on the VPS as root. If your panel uses additional ports, add them before you close the old server. Do not remove any older allow rule until the new path is confirmed.

Handle the migration in two phases

For reseller hosting, the safest cutover is phase-based. First copy the accounts, mail, databases, and panel configuration to the new server. Then validate logins, websites, and mail flow before you switch DNS or nameservers.

If your setup uses cPanel account operations, this Hostperl guide may help during the transfer path: cPanel account transfer with DNS cutover. If you are working inside WHM on the new system, the operational checklist in WHM account operations for clean hosting moves is a useful companion.

Use your panel's own transfer or restore tool if available. If you are restoring archives manually, keep this sequence: web files, database dumps, mail data, and then account-level permissions. That order prevents broken application logins and mail ownership issues.

Validate the new server before DNS changes

Use local host-file testing or a direct IP test to make sure the new server answers correctly. On the VPS as root, confirm the services you expect are active.

systemctl status sshd
systemctl status firewalld
ss -tulpn

You should see SSH listening and the web or panel ports bound on the expected interfaces. If a service is inactive, fix that before you continue.

From your local computer, test the web response directly if the new site is reachable over HTTP or HTTPS.

curl -I http://203.0.113.10
curl -kI https://203.0.113.10

The first command should return an HTTP status such as 200, 301, or 302. The second should only be used if TLS is already configured and you need a quick certificate-path check.

Update DNS or nameservers with a rollback window

Only switch DNS after the new server has passed login, service, and content checks. For reseller moves, lower the TTL ahead of time if you still control the old records.

dig +short NS example.com
dig +short A example.com

Run those from your local computer. Replace example.com with the customer domain or the reseller domain you are moving. If the domain still points to the old server after propagation, leave both servers live until the records settle.

If you manage DNSSEC or mail authentication as part of the cutover, the article DNSSEC for hosting buyers explains why mismatched records can break lookups even when the web server is healthy.

Lock down the old server only after the new one is proven

Do not change passwords, disable root SSH, or revoke the old server's access until the new login path works from a fresh session. This order matters when the migration is handled during business hours.

ssh deploy@203.0.113.10
sudo passwd -l root

Run the first command from your local computer only after you have already confirmed the new server works. The lock command should be used only when you no longer need direct root password access on the old machine.

If you need to harden the new server further, consider key-only SSH after a final login test. That change should wait until support staff have validated their own access path.

Verify the cutover from both sides

Server-side checks confirm the service state. Client-side checks confirm the customer experience. Use both.

systemctl is-enabled sshd
systemctl is-active firewalld
journalctl -u sshd -n 50 --no-pager

Run these on the VPS as root. You want enabled and active for the first two commands, and a clean log with no authentication errors that block access.

curl -I https://example.com
nslookup example.com
ssh -o BatchMode=yes deploy@203.0.113.10

Run these from your local computer. Successful output means the site resolves, HTTPS responds, and SSH works without a password prompt where keys are configured.

Rollback if something breaks

If the new server fails after DNS change, your safest rollback is to point the domain back to the old host and keep the old services online until propagation completes. If the failure is account-specific, restore the affected account from the last known-good backup instead of rebuilding the whole machine.

Common causes are broken ownership, missing PHP handlers, inactive services, or a firewall rule that blocks the panel. Use this diagnosis first:

systemctl --failed
journalctl -xe --no-pager
firewall-cmd --list-all

If SSH fails after a firewall change, recover through console access or provider out-of-band access. Hostperl customers on higher-end plans often prefer a managed or regional deployment path so support can assist during the maintenance window: dedicated server hosting is the right fit when the cutover must handle heavier account density or stricter performance requirements.

FAQ

Should I switch DNS before copying accounts?

No. Copy the accounts first, validate logins and services, then switch DNS. That sequence prevents customer downtime and makes rollback much simpler.

Why use openSUSE Leap for this workflow?

openSUSE Leap gives you stable systemd, zypper, and firewalld behavior. That makes it a good fit when you need predictable maintenance during a managed migration.

Can I disable root SSH right after the migration?

Only after the new non-root account has been tested from a separate terminal and sudo works. Keep the root session open until then.

What is the first thing to check if the site does not load after cutover?

Check DNS resolution, service status, and firewall rules in that order. In most cases, the problem is one of those three, not the application itself.