Migrate WooCommerce to openSUSE Leap with Zero Downtime

Why this migration method works for real stores

If you need to migrate WooCommerce to openSUSE Leap without disrupting checkout, the safest approach is straightforward: rehearse on staging, freeze writes briefly during the final sync, then switch traffic only after every payment and email path passes a smoke test. That fits agency handoffs, small stores with short maintenance windows, and Hostperl customers who cannot afford a long outage during a platform move.

This tutorial uses openSUSE Leap because it is a stable, production-ready Linux track with YaST, systemd, firewalld, and AppArmor. It is a solid match for a VPS from Hostperl VPS when you want controlled updates and predictable service behavior.

You will build a fresh openSUSE Leap server, install WordPress and WooCommerce, import the site, harden file permissions, enable TLS, and verify checkout behavior. The same pattern also helps when you compare a live move against the practices covered in WordPress staging and safe cutover for real stores and WordPress rollback on AlmaLinux and Rocky Linux VPS.

Scenario and migration plan

We will move a working WooCommerce store from an old server to a new openSUSE Leap VPS at 203.0.113.10. Replace that documentation IP with your server’s real public IP. The plan is:

1. Connect as root, detect the OS, and create a locked-down sudo user.
2. Install Nginx, PHP-FPM, MariaDB, and the tools needed for the migration.
3. Import the database and site files into /opt/myapp-style web paths.
4. Configure Nginx, PHP-FPM, AppArmor-aware permissions, and TLS.
5. Validate checkout, permalinks, email, and rollback readiness before cutover.

For businesses running a live store, the main risk is write drift: new orders, coupon changes, and customer accounts can be missed during the final copy. This tutorial avoids that with a short maintenance window and a second sync.

Connect, detect openSUSE Leap, and create a sudo user

On your local computer: start with the required root SSH session. This uses the documentation IP only as an example.

ssh root@203.0.113.10

Replace 203.0.113.10 with your real server IP. Keep this root session open until the new login works in a second terminal.

On the VPS as root: confirm the operating system before you change anything.

cat /etc/os-release

You should see openSUSE Leap details such as ID="opensuse-leap". If you do not, stop here and use the correct OS-specific guide.

Now create a non-root admin named deploy, add it to the administrative group, and prepare SSH access.

useradd -m -s /bin/bash deploy
passwd deploy
usermod -aG wheel deploy
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 creates the account, sets a password so you can recover access if keys fail, grants wheel sudo rights, and copies the root key to a safer login path. If your provider uses a different public key, paste it into /home/deploy/.ssh/authorized_keys instead of copying root’s key.

Open a second terminal and test the new account before you change any root-login settings.

On your local computer:

ssh deploy@203.0.113.10

Then test sudo:

sudo -v

If that succeeds, your non-root access is ready. Keep the original root session open for the rest of the setup.

Update packages, time sync, and base services

On the VPS as root: refresh the system first. openSUSE Leap uses zypper, not apt or dnf.

zypper refresh
zypper update -y
zypper install -y chrony firewalld nginx mariadb mariadb-tools php php-fpm php-mysql php-gd php-xml php-mbstring php-curl php-zip php-intl php-opcache unzip rsync tar curl wget certbot python3-certbot-nginx

That installs the web stack plus the migration tools you will need. If a package name differs on your exact Leap release, use zypper search before changing the procedure.

Enable time sync and the firewall now, before you expose the site.

systemctl enable --now chronyd
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

After the reload, SSH, HTTP, and HTTPS should remain reachable. This sequence keeps you from locking yourself out when you open the web ports.

Prepare MariaDB for the WooCommerce database

WooCommerce stores orders, customers, and product data in MySQL-compatible tables. On openSUSE Leap, MariaDB is the usual production choice for this move.

On the VPS as root: start and secure MariaDB.

systemctl enable --now mariadb
mysql_secure_installation

During the security script, set a strong root password, remove anonymous users, disallow remote root login, and remove the test database. The prompts vary slightly by version, but the safe answers are the same.

Create a dedicated database and user for the store.

mysql -u root -p

At the MariaDB prompt, run:

CREATE DATABASE wpstore CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'Use-A-Long-Unique-Password-Here';
GRANT ALL PRIVILEGES ON wpstore.* TO 'wpuser'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Replace the example password with a unique secret. Use the same database name only if it does not conflict with an existing site.

Set up the web root, PHP-FPM, and ownership

On the VPS as root: create a clean document root and make the ownership explicit. For this tutorial we will use /srv/www/woocommerce, which keeps the site easy to identify on a new server.

mkdir -p /srv/www/woocommerce
chown -R wwwrun:www /srv/www/woocommerce
chmod 750 /srv/www/woocommerce

Now enable PHP-FPM and check the service name before you write the Nginx config.

systemctl enable --now php-fpm
systemctl status php-fpm --no-pager

You should see an active state. If the service fails, inspect the logs before proceeding.

journalctl -u php-fpm -n 50 --no-pager

For PHP tuning, set sane production defaults in /etc/php7/fpm/php.ini or the versioned PHP path used by your Leap release. Check the exact file path first with php --ini. Then update values such as memory_limit, upload_max_filesize, and post_max_size to match your store’s imports and media library size.

Restore the WordPress files and database

If your old server is still online, do the final file and database export there first. If not, use the latest backup you have and compare timestamps before proceeding.

On the old server:

mysqldump -u root -p --single-transaction --routines --triggers wpstore > wpstore.sql
tar -czf wpstore-files.tar.gz /var/www/html/wp-content

Copy both files to the openSUSE Leap VPS using rsync or scp. Then import them on the new server.

On the VPS as root:

cd /srv/www/woocommerce
mysql -u wpuser -p wpstore < /root/wpstore.sql
tar -xzf /root/wpstore-files.tar.gz --strip-components=2

If your archive contains the full WordPress tree instead of only wp-content, adjust the extraction target so you do not overwrite the application core unexpectedly. Keep the database import separate from the file copy so you can roll back either one.

Update the site URL if the domain changes during migration. Use the old and new hostnames that apply to your move.

mysql -u wpuser -p -e "UPDATE wp_options SET option_value='https://example.com' WHERE option_name IN ('siteurl','home');" wpstore

Replace example.com with your real domain. If the site stays on the same domain, you usually do not need this step.

Configure Nginx for the WooCommerce site

On the VPS as root: create the server block file.

vi /etc/nginx/conf.d/woocommerce.conf

Paste this configuration, then save and exit:

server {
    listen 80;
    server_name example.com www.example.com;
    root /srv/www/woocommerce;
    index index.php index.html;

    access_log /var/log/nginx/woocommerce.access.log;
    error_log /var/log/nginx/woocommerce.error.log;

    client_max_body_size 64m;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php-fpm/www.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    location ~* /(wp-config\.php|readme\.html|license\.txt) {
        deny all;
    }
}

Replace the domain names with your own. The configuration keeps permalinks working and blocks direct access to a few sensitive files.

Test the Nginx syntax before reload.

nginx -t

A successful test ends with syntax is ok and test is successful. Then reload Nginx.

systemctl reload nginx

If Nginx refuses to start, check the log file mentioned in the test output and correct the config before trying again.

Install WordPress, set permissions, and harden the basics

If the WordPress core is not already present in /srv/www/woocommerce, download it now.

cd /srv/www/woocommerce
wget https://wordpress.org/latest.tar.gz
tar -xzf latest.tar.gz --strip-components=1
rm -f latest.tar.gz

Then create the WordPress configuration file from the sample and edit the database details.

cp wp-config-sample.php wp-config.php
vi wp-config.php

Set these values inside the file:

define('DB_NAME', 'wpstore');
define('DB_USER', 'wpuser');
define('DB_PASSWORD', 'Use-A-Long-Unique-Password-Here');
define('DB_HOST', 'localhost');

Also paste fresh unique salts from the WordPress secret-key service before you save. When done, make the file readable only by the web server and root.

chown -R wwwrun:www /srv/www/woocommerce
find /srv/www/woocommerce -type d -exec chmod 755 {} \;
find /srv/www/woocommerce -type f -exec chmod 644 {} \;
chmod 640 /srv/www/woocommerce/wp-config.php

On openSUSE Leap, AppArmor can shape access behavior. If you change the document root or use custom PHP paths later, review AppArmor profiles instead of forcing broad permission changes. The safest route is usually to stay with standard paths like /srv/www and the default PHP socket.

Issue Let’s Encrypt certificates and switch to HTTPS

On the VPS as root: request a certificate only after DNS for the domain already points at this new server.

certbot --nginx -d example.com -d www.example.com

Replace the example names with your live domain. Certbot will rewrite the Nginx server block for TLS and set up renewal hooks.

Check the renewal path immediately so you do not discover a broken certificate at the next expiry cycle.

certbot renew --dry-run

If renewal fails, inspect /var/log/letsencrypt/letsencrypt.log and confirm that port 80 still reaches the same server.

Run the post-migration checkout checks

Now test from the server and from a client browser. These checks matter more than a green admin dashboard.

On the VPS as root:

systemctl status nginx php-fpm mariadb --no-pager
ss -tulpn | grep -E ':80|:443|:3306'

You should see the services active and listening on the correct ports. Then confirm the site responds locally.

curl -I https://example.com
curl -I https://example.com/wp-login.php

Look for HTTP 200 or 301 responses, not 500 errors. If you see a PHP error, check the Nginx error log and PHP-FPM log together so you can trace the exact failure.

On your local computer: open the site in a browser and complete a real smoke test:

1. Log in to WordPress admin.
2. Confirm the WooCommerce product catalog loads.
3. Add a product to the cart.
4. Start checkout and stop before submitting any real payment if the gateway is in test mode.
5. Check that order confirmation email goes to the correct inbox or sandbox.

This mirrors the kind of launch validation Hostperl support teams ask customers to perform before a public switch.

Rollback and recovery path

Keep a clean rollback point until the new server has handled live traffic for a while. If the cutover exposes a problem, you can return to the old server by restoring DNS, re-enabling the old site, and importing only the final delta later.

On the VPS as root: keep a backup of the working state.

tar -czf /root/woocommerce-backup-$(date +%F).tar.gz /srv/www/woocommerce
mysqldump -u root -p wpstore > /root/wpstore-backup-$(date +%F).sql

If checkout breaks after launch, the fastest diagnostic loop is usually:

tail -n 50 /var/log/nginx/woocommerce.error.log
journalctl -u php-fpm -n 50 --no-pager
mysql -u wpuser -p -e "SHOW TABLES;" wpstore

Those commands tell you whether the failure is in Nginx, PHP-FPM, or the database. If the issue is a bad plugin or theme update, disable it by renaming the plugin directory and retest before you touch the database.

Troubleshooting the most common failures

502 Bad Gateway: PHP-FPM is down or the socket path is wrong. Run systemctl status php-fpm --no-pager and confirm the socket in nginx.conf matches the actual pool socket. Restart PHP-FPM only after you fix the path.

404 on permalinks: Nginx is not using the WordPress front controller rule. Recheck try_files $uri $uri/ /index.php?$args; and reload Nginx after nginx -t.

Mixed content after HTTPS: the site still stores an old HTTP URL in the database. Search and replace the domain with a WordPress-safe tool or a controlled SQL update, then clear caches and retest.

File permission errors: Nginx or PHP cannot write to uploads. Confirm ownership under /srv/www/woocommerce/wp-content/uploads and avoid world-writable permissions.

Final verification checklist

Before you call the migration done, confirm these states from the server and from a client:

• nginx, php-fpm, and mariadb are active after reboot.
• curl -I https://example.com returns a clean redirect or 200 response.
• WordPress admin logs in without PHP notices or timeout errors.
• WooCommerce cart, checkout, and order email all work as expected.
• certbot renew --dry-run succeeds.

That gives you a practical, supportable migration instead of a best-effort copy. If your store is growing, Hostperl’s managed VPS hosting is usually the better fit for this kind of controlled change because you can keep the server, logs, and recovery path in one place.