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.
Most importantly, database prefixing is required in InterWorx, as this is the mechanism used to map databases to accounts inside of the control panel. Most cPanel databases should already have username prefixing, but some may not, depending on when they were created.
Additionally, because of a difference in mail software, single character mailboxes are not permitted (though single character aliases are).
Further, though the panel supports multiple concurrent PHP versions for different accounts and domains, the oldest available PHP version is currently 5.4, so sites utilizing older versions may need to upgrade their code in order to function well using InterWorx.
Preparing Your cPanel Accounts
In order to restore cleanly into InterWorx, any issues discovered as listed above will need to be addressed.
The database naming will be one of the most important, and can be accomplished using WHM’s ‘Manage Databases’ and ‘Manage Database Users’ features (found under ‘SQL Services’).
Databases and their users can be renamed here, but any configuration files that connect to these databases will need to be altered to use the new names.
For instance, let’s say we have an account called ‘maria’ which uses WordPress. Because database prefixing is disabled in our WHM install, it’s database is ‘wp29’ and the user is ‘wpuser’. Using the Manage Databases tool, the database will need to be renamed to ‘maria_wp29’, and using Manage Database Users, the user will need to change to ‘maria_wpuser’. Then, in the wp-config.php file for maria, which would be at /home/maria/public_html/wp-config.php, the DB_NAME and DB_USER will need to be updated to the proper new values.
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 126.96.36.199):
scp 188.8.131.52:/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 184.108.40.206 --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 220.127.116.11 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:
18.104.22.168 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 (22.214.171.124 in our example) which will need to be altered to the new IP (126.96.36.199).
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.