InterWorx is poised to be a game changer for cPanel users.
With good feature parity and a non-scaling license cost, SMB customers who do not use the edge case features of cPanel can potentially save money by switching to InterWorx.
Additionally, InterWorx has an import feature that will take backups from cPanel servers and restore them as valid InterWorx accounts, making migrations to the platform simpler.
This article will show you how to prepare for an easy migration, and final testing, to Interworx.
Even though the core features are similar, there are some potential blockers that could prevent clean import of cPanel accounts into InterWorx.
Firstly, wildcard subdomains are not natively supported in InterWorx. Applications that require wildcard subdomains may not work well, if at all, in InterWorx.
Additionally, because of a difference in mail software, single character mailboxes are not permitted (though single character aliases are).
Though the panel supports multiple concurrent PHP versions for different accounts and domains, the oldest available PHP version is 5.4, so sites utilizing older versions may need to upgrade their code in order to function well using InterWorx.
cPanel also does not permit this directly, but long MySQL users can be added through other workarounds, so you will need to ensure that MySQL usernames are 32 characters or less so that they can be imported into InterWorx properly.
Finally, there are no integrations for PostgreSQL in InterWorx, so any databases in cPanel on the PostgreSQL engine cannot be imported.
Differences in Panels
Beyond these potential blockers, there are other items you need to take into consideration when moving to InterWorx from cPanel:
- InterWorx’s mail program does not support SMTP on port 465. If you use port 465, you will need to update your mail clients to connect on 587 instead.
- InterWorx’s mail program will only serve SSL/TLS connections with certificates signed for the server’s hostname. If you are used to connecting to your mail subdomain (mail.domain.com), you will need to update your mail clients to use your new server’s hostname instead.
- InterWorx has strict document root folder structures, where each add-on domain is isolated to its own folder. Therefore, sites which depend on a nested or relative path structure may not function the same way on InterWorx as they do on cPanel. You should test your sites carefully to ensure they work the way you expect if this condition applies to you.
Packaging Your cPanel Accounts
Once any potential restoration conflicts have been taken care of, cPanel accounts can be packaged for transfer. This is best accomplished through the command line pkgacct tool, by passing the username of the account you wish to copy. These packages are full backups of individual cPanel accounts, and you should make sure you have enough free disk space to store such a backup for each account you will be copying.
In our example, we will package the user ‘maria’:
/scripts/pkgacct maria /home/
This should place a file called cpmove-maria.tar.gz into your /home/ directory on the cPanel server. Repeat this procedure for each account on your server you wish to migrate to InterWorx.
Once you have all of the packages you need, they can be copied to your InterWorx server. Log into the InterWorx machine as root and run this command to copy the packaged accounts from your cPanel server (assuming IP address 22.214.171.124):
scp 126.96.36.199:/home/cpmove-*.tar.gz /home/
This will log into the cPanel machine, grab all of the cpmove files we made before, and put them in /home/ on the new server.
Restoring Your cPanel Accounts
Now that we have all of the cPanel data in packages on the new machine, we will start restoring them to create hosting accounts in InterWorx.
Here is how the command will look:
/usr/local/interworx/bin/import.pex --control-panel cpanel --ipv4 188.8.131.52 --archive /home/cpmove-maria.tar.gz | tee -a /home/maria.import.log
It’s a bit of a longer command, so let’s break it down.
First, there is the command itself, which is import.pex.
This is the InterWorx account import script, which will actually accept backups from a few different control panel types. This is why we have to declare the control panel source in the next flag, which in this case is cPanel.
Next, the script has to know what IP we want to restore the domains to, which is 184.108.40.206 in our example. This should be a shared IP on the InterWorx server if you are restoring multiple accounts.
Finally, we want to give the restore script the path to our cPanel backup file, which is /home/cpmove-maria.tar.gz for the ‘maria’ user.
After all of that, there is a ‘pipe’, which puts the output of the import.pex command into another command we can use to create a log file. In this case, the command is ‘tee’, which will duplicate the output, put one of the copies onto your screen, and another copy into /home/maria.import.log. This way, once the restore is done, you can still reference the output at that file, in case you need to review any errors.
The full command will extract the file that we passed, use its cPanel logic to restore all of the domains, email accounts, SSLs, databases, database users, and so on contained within, and then start hosting that (those) domain(s) on the IP address we specified.
Testing Your Sites
After the import command completes, you’ll be able to test the sites on the new server using your favorite testing method. Mine is hosts file editing, which you can read about more at our Knowledge Base article. This is a much more accurate method than most other available options.
Generally, you would create a line like this for each of your domains:
220.127.116.11 marias-website.com www.marias-website.com
…and then add that line to the end of the hosts file on your workstation or computer.
Then, you should be able to test the site by browsing to it, without having to affect public DNS or use a less accurate proxy service.
Check out the link above for more detailed instructions for your OS.
While testing the new server, generally you want to be sure that sites load and aren’t missing any elements or giving any errors.
If you do find some errors, the global apache and php logs are located at /etc/httpd/logs/, which can give you more details on what the problem might be. There are separate logs for https traffic (ssl_error_log) and non-https traffic (error_log).
Additionally, every domain can write to its own local error log. These are stored at /home/maria/var/marias-website.com/logs/error.log for our sample account. These logs are combined for https and non-https traffic.
You are also free to reach out to our support team with any issues or questions you might have, 24/7.
To shift traffic from the old cPanel server to your new InterWorx server, all that is needed is a DNS update of all of the records that are referencing the old machine.
In most cases, there is a single A record that points to the IP address of the source server (18.104.22.168 in our example) which will need to be altered to the new IP (22.214.171.124).
Before we can change any records, you will need to discover where your DNS is hosted. There are many possibilities, but I’ll highlight a few of the common ones.
First, you might use Liquid Web’s shared nameservers, in which case you can update DNS through manage.liquidweb.com under the Domains > DNS tab. You might also use some 3rd party nameservers, such as at your registrar or at CloudFlare. In that case, you would do the same thing, except through their interface: log in, locate the DNS zonefile for the domain, and then change all of the IPs to the new one.
The final common possibility is that you have DNS hosted on the source cPanel server itself, with custom nameservers. While the main process of logging into WHM and changing the zonefile is similar, you will also need to affect the Nameserver Glue records at your nameserver’s main domain’s registrar. Otherwise, DNS will continue to be hosted by the cPanel server even after the new server goes live, and terminating the old server would cause your sites to go down. The process varies depending on where you registered your nameservers, but every registrar should be able to help you make glue record changes, so that the InterWorx server can start hosting DNS for you.
And, that’s it! After A records are updated, traffic should start flowing to the new server, completing your migration.