Migrate an InterWorx server from RHEL to AlmaLinux

Plenty of InterWorx servers were built on RHEL when it was the default enterprise choice, and the subscription now costs more than the panel licence sitting on top of it. AlmaLinux is binary-compatible, free, and a supported InterWorx base OS on both EL8 and EL9, so the move is worth making.

There are two ways to do it: build a fresh AlmaLinux server and import every SiteWorx account across, or convert the existing box in place. This guide covers both, with the licence handling that catches people out during the overlap.

Pick a route

Take the new-server route unless you can't change IPs. The InterWorx importer is the supported path, the old server stays live as a fallback, and you get a clean OS with none of the drift from years of manual changes. In-place conversion makes sense when the IPs are hard to move — customer-pinned dedicated IPs, allow-listed mail relays — and you have a hypervisor snapshot to roll back to.

Route 1: new AlmaLinux server and import

Build and licence the target

Install InterWorx on a fresh AlmaLinux 9 server following the InterWorx install walkthrough. Use the same InterWorx major version as the source, or newer — never older.

The target needs its own licence key while both servers run. InterWorx keys are IP-locked, so you can't activate the source's key on the new box without taking the old panel offline. Order a second InterWorx licence for the overlap and cancel whichever one you don't keep once the move is done. Monthly billing is prorated, so a two-week overlap costs half a month, not a full one — see how prorated licence billing works.

Prepare the source

The importer logs in to the source over SSH as root with a password. Check three things on the RHEL box:

grep -Ei '^(PermitRootLogin|PasswordAuthentication)' /etc/ssh/sshd_config
df -h /home
~iworx/bin/backup.pex -h | head -20

Root password login must be allowed for the duration of the move. Lock it down again afterwards. The InterWorx docs also note that existing passwordless key-based SSH between the two servers causes Invalid Password errors at import time. Remove the target's key from the source's authorized_keys before you start.

Lower the TTL on every hosted zone to 300 seconds at least 24 hours before cutover, so the IP change propagates in minutes.

Run the Mass Import

On the AlmaLinux target, go to NodeWorx → SiteWorx → Import → Import Mass Transfer. Enter the source hostname (append :port if SSH isn't on 22), the root user, and the password, then click Query Accounts.

For each account you choose:

• IPv4 Address — the new server's shared IP, or a dedicated IP you've already added
• Reseller — imports the source reseller if it doesn't exist locally
• Type — Full for normal accounts, Structure-Only for the large ones (see below)

The Advanced Options dropdowns set a value for every listed account at once, which saves a lot of clicking on a 200-account server. Tick the accounts, click Import, and watch the status column move from Pending to Success or Failure. The job keeps running if you close the page.

InterWorx 8.1 and later also ship a Migration Tool (still marked beta) under the same Import menu. It can re-sync an account after the first pass, which helps with a final delta before cutover. Use Mass Import for the bulk and the Migration Tool for the stragglers.

Large accounts: split the import

Big mailboxes are where Mass Import times out. Move those accounts in pieces. On the RHEL source, back up the structure first:

~iworx/bin/backup.pex --domains bigclient.example.com --structure-only --output-dir /root/migrate
~iworx/bin/backup.pex --domains bigclient.example.com --backup-options web db --output-dir /root/migrate
rsync -a /root/migrate/ root@new-server.example.com:/root/migrate/

On the target, list /root/migrate/ for the exact archive names. Import the structure backup first, then the partial with --preserve-siteworx-account so it lands in the account you just created:

~iworx/bin/import.pex --archive=/root/migrate/<structure-backup-file> --control-panel=siteworx --ip-address=203.0.113.10
~iworx/bin/import.pex --archive=/root/migrate/<partial-backup-file> --control-panel=siteworx --ip-address=203.0.113.10 --preserve-siteworx-account

Then rsync the mail directories across with ownership and permissions intact. The structure import has already created the mailboxes, so only the message files need to move.

Route 2: convert in place with almalinux-deploy

AlmaLinux's almalinux-deploy script converts RHEL 8 and 9 to AlmaLinux without a reinstall. Its README lists cPanel, Plesk, and DirectAdmin as tested panels. InterWorx isn't on that list, so treat this as unsupported and have a working rollback before you try it.

1. Take a hypervisor snapshot, or a full image backup on bare metal.
2. Run the conversion as root inside screen or tmux, or from an out-of-band console:

dnf install -y dnf-plugins-core
curl -O https://raw.githubusercontent.com/AlmaLinux/almalinux-deploy/master/almalinux-deploy.sh
bash almalinux-deploy.sh
reboot

After the reboot, confirm the OS and licence, then click through NodeWorx and a few SiteWorx accounts before calling it done:

cat /etc/almalinux-release
~iworx/cron/license.pex --sync

The IP doesn't change, so the licence binding stays valid. If the panel throws a licence error anyway, work through the InterWorx licence error checklist.

Cutover and clean-up

For the new-server route:

1. Delta sync. Re-sync accounts that changed during the migration window, using the Migration Tool or a fresh --preserve-siteworx-account import.
2. Point DNS. If InterWorx hosts DNS, update the glue records for your nameserver hostnames at the registrar to the new IPs. Otherwise, update the A records wherever the zones live.
3. Reissue SSL. Let's Encrypt certificates are not part of SiteWorx backups, so every site needs a new certificate once DNS resolves to the new server. The InterWorx Let's Encrypt setup guide covers the bulk options.
4. Recreate server-level config. The importer moves accounts, not the server. Custom Apache includes, /etc/cron.d jobs, firewall rules, and PHP defaults have to be redone by hand on the target.
5. Retire the source. Keep it powered on but firewalled for a week in case something was missed, then cancel the licence you're not keeping.

Next steps

• Compare what each SKU caps before ordering the overlap key: InterWorx license tiers explained.
• Coming from cPanel instead? Migrate cPanel accounts to InterWorx.
• Running several nodes after the move? Read the InterWorx clustering setup guide.