With unlimited site hosting per license and solid core features, SMB customers who don’t use any cPanel-specific features could save big money by switching to InterWorx<\/a>. There could also be cases, though, where migrating from InterWorx to cPanel is mandatory to consolidate services, add a cPanel-specific feature, or integrate two businesses using different panels.<\/p>\n<\/div>\n While InterWorx has an import feature that can take backups from cPanel servers and restore them as valid InterWorx accounts, making migrations to the platform simpler, the reverse just isn’t true. Migrations from InterWorx to cPanel will should be performed manually.<\/p>\n<\/div>\n With the appropriate general knowledge and specific details about your server usage, this sort of migration may be executed in a number of hours for a small number of web sites.<\/p>\n<\/div>\n While there are a number of blockers in moving from cPanel to InterWorx<\/a>, these particular blockers are only in a single direction. As an example, InterWorx requires database prefixing in all cases to map databases to their owners, but cPanel doesn’t. So, there mustn’t be a case where a database name will cause an import to fail.<\/p>\n<\/div>\n One vital thing to recollect about cPanel is its licensing costs. InterWorx allows for an infinite variety of SiteWorx accounts per server, but cPanel costs will change depending on what number of cPanel accounts you might want to create.\u00a0<\/p>\n<\/div>\n Things you will have to think about before moving from InterWorx to cPanel:<\/p>\n<\/div>\n One other consideration is server clustering. Out of the box, InterWorx can support multiple web nodes working in unison to balance traffic. cPanel doesn’t support this by default, and extra products can be needed in the event you use this feature.\u00a0<\/p>\n<\/div>\n So far as general server migration<\/a> considerations go, it’s best to have a very good understanding of where the DNS on your domains is hosted (your nameservers). On the conclusion of your migration, you will have to make changes to the DNS to make the brand new server live, and ensuring access to your nameservers early in the method makes the ultimate turnaround faster.<\/p>\n<\/div>\n If possible, lower the TTL values in your records now in order that once we take the brand new server live, propagation will occur quickly.<\/p>\n<\/div>\n Moreover, pay attention to the features that you just use in your server. In the event you host mail, be sure your mail accounts, together with their passwords and mailbox contents, are copied in the course of the migration and that any in-use mail ports are opened and arrange on the brand new server. In the event you use Redis, Memcache, or every other third party applications, be sure those are arrange on the cPanel machine ahead of time as well.<\/p>\n<\/div>\n There just isn’t much to be done in InterWorx, specifically to prepare on your migration. Usually, you’ll want to make sure that updates to your sites (latest posts, product releases, etc.) are temporarily suspended to lower the probabilities of lost data and that your sites are on up-to-date core software, comparable to PHP 7 or greater.<\/p>\n<\/div>\n Now, we are able to finally get to work on migrating! First, assemble a listing of the entire SiteWorx accounts in your server that you just want to migrate. As root on the InterWorx server, you should use this command to accomplish that:<\/p>\n<\/div>\n You’ll be able to relate these to hosted domains using this command, also run on the InterWorx machine:<\/p>\n<\/div>\n This could print out the domain name, username, whether it’s a primary or secondary domain, its PHP version, and the situation of the document root for the location.<\/p>\n<\/div>\n cPanel accounts may be created through the WHM interface or as root from the command line on the cPanel server:<\/p>\n<\/div>\n In the event you occur to know the passwords for your whole SiteWorx users, you would enter them above. Random passwords will work here in the event that they are suitably secure, and users can reset them after the migration is complete. You can too copy the password hashes directly from \/etc\/shadow into the brand new server in the event you are comfortable doing so.<\/p>\n<\/div>\n Note:<\/p>\n No matter the way you migrate your passwords, it’s highly beneficial that users change their password after the migration is complete<\/strong>. Passwords which are typed plaintext into the command line can be saved in bash history and might be exposed by root level users. Even in the event you import hashes directly, it’s a very good security practice to alter your passwords every few months.<\/p>\n<\/div>\n<\/div>\n With the accounts, it’s best to also create mailboxes that belong to every account. This will, again, be done through the cPanel web GUI or from the command line.<\/p>\n<\/div>\n Run this command on the cPanel server so as to add a mailbox:<\/p>\n<\/div>\n Note:<\/p>\n There are some special characters like , |, or !, that can cause odd behavior within the command line when utilized in a password. In the event you get odd output from the createacct or addpop commands, try using a unique random password.<\/p>\n<\/div>\n<\/div>\n The passwords for mailboxes may be entered, if known, or updated later in \/home\/youruser\/etc\/yourdomain.com\/shadow<\/em> files on the cPanel server. The unique mailbox password hashes may be pulled using this command on InterWorx:<\/p>\n<\/div>\n Above, you’ll replace the user<\/em> and yourdomain.com<\/em> near the tip of the command with the actual mailbox and domain name to get the hash for that user. Again, it’s best to only do that in the event you are comfortable with editing the shadow files on your mailboxes; otherwise, it is simpler to easily let the users reset their mail passwords once the migration is complete.<\/p>\n<\/div>\n Going off of a listing of databases from the source server, which you’ll get from listing the \/var\/lib\/mysql<\/em> directory and on the lookout for user-prefixed folders, generate databases individually using this command on the cPanel server:<\/p>\n<\/div>\n After creating the databases, you will have so as to add users as well. This command, run on the InterWorx server, gets the database users which have access to the database you specify and makes a grant command that you may paste into your cPanel machine\u2019s terminal. Make sure to change youruser_dbname<\/em> initially of the command to the database you might be working on whenever you run this on the InterWorx server:<\/p>\n<\/div>\n Paste the output into your cPanel server to grant access.\u00a0<\/p>\n<\/div>\n Finally, we’d like to map the database and latest user in order that it might probably be controlled from the appropriate account. Use this command on cPanel, replacing the entire yourxxxx<\/em> portions as needed:<\/p>\n<\/div>\n Now that we now have a spot on the cPanel server for all of our site files, emails, and databases to land, we are able to begin copying them over. The entire sample commands below are run on the cPanel server and can should be updated with the suitable IP address of the InterWorx machine. This step is greatly simplified in the event you add an SSH key<\/a> from the cPanel server into the InterWorx server for passwordless root-level SSH access.<\/p>\n<\/div>\n Note:<\/p>\n In case your InterWorx server just isn’t using port 22 for SSH, you will have so as to add the next bit (with the right SSH port) to your rsync commands together with the remainder of the flags: -e \u2018ssh -p9898\u2019<\/strong><\/p>\n<\/div>\n<\/div>\n The person domain information we discovered initially of the migration process can be very handy here. Match up logically the entire accounts you created to the accounts in InterWorx. For our examples, we are going to assume that the cPanel username is similar because the InterWorx username and that each account only controls one domain.<\/p>\n<\/div>\n This command to repeat a primary domain document root from InterWorx to cPanel is run on the cPanel server:<\/p>\n<\/div>\n Make sure to watch the trailing slashes! This command copies public_html<\/em> and its contents from the distant InterWorx machine into the \/home\/youruser\/<\/em> folder on the local cPanel machine.<\/p>\n<\/div>\n If there are additional document roots to repeat into additional separate folders, you should use similar commands with the correct goal folder.<\/p>\n<\/div>\n Emails are copied using an rsync command as well since they’re stored in the same folder-based format on each systems. Here is the command for the sample email address we created earlier, which can be run from the cPanel server:<\/p>\n<\/div>\n There are plenty of unique items that should be altered throughout this command based on the account, mail user, and domain you might be syncing data for, including youruser<\/em> (the cPanel\/InterWorx account name), yourdomain.com<\/em>, and user<\/em> (the mailbox name).<\/p>\n<\/div>\n Databases may be streamed from the InterWorx server over to the cPanel server directly using a straightforward pipeline. This avoids having to generate a file-based dump after which copying and reading that file. Our same sample database is copied here, and this command is run on the cPanel machine:<\/p>\n<\/div>\n There are a number of miscellaneous files that may also be copied to create a more complete clone of the InterWorx accounts. Specifically, the crontab may be read from \/var\/spool\/cron\/youruser<\/em> and its contents inserted into the identical file on the cPanel server. Just make sure that you aren’t going to prematurely run any crons that would double-bill your eCommerce sites or duplicate other functions which are still being performed by your old machine.<\/p>\n<\/div>\n This can be a fantastic time to double-check and arrange any programs from the source machine that you prefer to to proceed using like ElasticSearch, NGINX<\/a>, ImageMagick, and so forth, in the event you didn’t accomplish that before starting the transfer. It is best to also set any configuration limits that you just modified to permit your sites and server to work together higher comparable to those in PHP\/Apache or CSF; nevertheless, a brand new server can be cause for a latest tuning session<\/a>.<\/p>\n<\/div>\n If you finish the entire above steps, you\u2019ll give you the chance to check the sites on the brand new server. Start by changing the hosts file<\/a>. Hosts file editing is a far more accurate method than every other available option. Start by making a line of text like this one with the IP of the brand new server then a listing of domains and subdomains you should test, separated by spaces:<\/p>\n<\/div>\n Add that line to the tip of the hosts file in your workstation (not either server). You’ll be able to then test the location by visiting it in your browser normally, without having to alter public DNS or use a less accurate proxy service.\u00a0<\/p>\n<\/div>\n While testing the brand new server, you generally wish to make sure that sites aren\u2019t missing any images or CSS files or giving every other glaring errors. Troubleshoot as needed to correct these before going live.<\/p>\n<\/div>\n To shift traffic from the old server to your latest one, the one remaining step is a DNS update of the entire records which are referencing the old IP. There is generally a single A record that points to the IP address of the source server (123.45.67.89 in our example), which can should be modified to the brand new IP.<\/p>\n<\/div>\n There are numerous options for where your DNS is controlled. You would possibly currently use Liquid Web\u2019s shared nameservers, by which case, you may change your DNS at My LiquidWeb<\/a> or by sending us a support ticket.\u00a0<\/p>\n<\/div>\n You may additionally have DNS at your registrar or at CloudFlare. In that case, you’ll do the identical IP address change but at the suitable control panel for that nameserver.<\/p>\n<\/div>\n The opposite possibility is that you just control DNS on InterWorx itself with custom nameservers. The menu you wish may be accessed from NodeWorx \u2006> \u2006\u2006System Services \u2006> \u2006\u2006DNS Server \u2006> \u2006\u2006Zones<\/strong>.<\/p>\n<\/div>\n Note:<\/p>\n Changing the IP addresses will make your latest server live, and your migration is now complete.\u00a0<\/p>\n<\/div>\n Traffic should start flowing to the brand new server because the TTL value in your DNS slowly expires. This is the reason lowering the TTL value is essential to do initially of your migration.<\/p>\n<\/div>\n If this guide sounds a bit too intense, don\u2019t worry. We have now a dedicated Migrations Team available to assist all of our Fully Managed customers, with many years of experience successfully migrating web sites into cPanel environments. Reach out to the Support Team 24\/7 through My LiquidWeb<\/a> to get more information today.<\/p>\n<\/div>\nConsiderations Before Starting<\/h2>\n
\n
1. Creating cPanel Accounts<\/h2>\n
nodeworx -u -c Users --action listUsers -n<\/code><\/p>\n nodeworx -u -c Siteworx -a listDomainAccounts -n |tr \"t\" \"|\" |awk -F\"|\" '{print $10,$2,$11,$19,$22}' |column -t<\/code><\/p>\nMake Users<\/h3>\n
\/scripts\/createacct yourdomain.com youruser EB-al2pK)*o=<\/code><\/p>\nMake Mailboxes<\/h3>\n
\/scripts\/addpop user@yourdomain.com \/tQ7biFJ]24%<\/code><\/p>\n mysql -Ns -u iworx_vpopmail -p$(grep mysqli:\/\/iworx_vpopmail: \/home\/interworx\/iworx.ini | cut -d: -f3 | cut -d@ -f1) -S \/usr\/local\/interworx\/mysql\/iworx-db.sock iworx_vpopmail -e \"select pw_passwd from vpopmail where pw_name='user' and pw_domain='yourdomain.com'\"<\/code><\/p>\nMake Databases<\/h3>\n
mysqladmin create youruser_dbname<\/code><\/p>\n mydb=youruser_dbname; mysql -BNe \"select user from mysql.db where db='\"$mydb\"' and host='localhost'\" | while read i; do pwhash=$(mysql -BNe \"select Password from mysql.user where Host='localhost' and User='\"$i\"';\"); echo \"mysql -e 'grant all privileges on $mydb.* to $i@localhost identified by password \"$pwhash\"'\"; done<\/code><\/p>\n \/usr\/local\/cpanel\/bin\/dbmaptool youruser --type mysql --dbs 'youruser_dbname' --dbusers 'youruser_dbuser'<\/code><\/p>\n<\/p>\n2. Copying Files<\/h2>\n
Document Roots<\/h3>\n
rsync -avHP 123.45.67.89:\/home\/youruser\/public_html \/home\/youruser\/<\/code><\/p>\nEmails<\/h3>\n
rsync -avHP 123.45.67.89:\/home\/youruser\/var\/yourdomain.com\/mail\/user\/Maildir\/ \/home\/youruser\/mail\/yourdomain.com\/user\/<\/code><\/p>\nDatabases<\/h3>\n
ssh 123.45.67.89 \"mysqldump youruser_dbname\" | mysql youruser_dbname<\/code><\/p>\n<\/p>\nAdditional Items<\/h3>\n
3. Testing Migrated Sites<\/h2>\n
11.22.33.44 yourdomain.com www.yourdomain.com<\/code><\/p>\n4. Going Live<\/h2>\n
Liquid Web Knows Migrations<\/h2>\n
![\"Datasheet](\"https:\/\/res.cloudinary.com\/lwgatsby\/f_auto\/www\/uploads\/2020\/03\/Datasheet-Migration-Checklist.png\")
<\/a><\/figure>\n<\/div>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"