There are many reasons why you could want to transfer a WHM cPanel environment from one server to another server, whether you are migrating to a new web hosting company or simply upgrading the operating systems to the latest version. There are situations whereby certain Linux operating systems aren’t able to upgrade between major versions such as CentOS 6 to CentOS 7 just as one example. In this situation you have to spin up a brand new server or virtual machine running CentOS 7 with WHM cPanel then transfer everything over from the old CentOS 6 server running WHM cPanel.
We have previously covered off other topics such as How to Migrate a Web Server Seamlessly with Zero Downtime and How to Migrate an eCommerce Website Between Servers with Zero Downtime which are also worth reading through for some handy information. This blog post covers similar information but goes into a lot more detail around the steps involved with this when the migration is specific to cPanel and WHM.
This requires a little planning, good communication and a structured approach to the process to ensure there is no interruption to the websites and services that are being migrated – or as minimal as possible.
Step 1 – Spin up a New Virtual Machine
This step is highly likely to be managed by your web hosting company, so you probably don’t need to worry a great deal about this step. If you are doing this step yourself and you are reading this blog post, you could probably do with a chat with us to help guide you through the process.
Step 2 – Install WHM cPanel on New Server
This step is a bit of a pain since cPanel is a licenced piece of software, meaning you’ll need to have duplicate licence costs for a small amount of time throughout this process. Again, this step is highly likely to be managed by your web hosting company.
Step 3 – Use WHM Transfer Tool to Transfer Individual cPanel Accounts
This is where things get a little more nuanced. In theory, this should just work. In practice, it’s highly likely that you’ll have a few niggles along the way, so I’d recommend approaching this with caution and planning properly.
A WHM cPanel environment could have hundreds if not thousands of individual cPanel accounts that are being managed within that WHM environment. So there is no simple solution to getting this all migrated at the click of a button. You’ve also got to be very mindful of the applications/websites/systems that are running on the individual cPanel accounts that are being migrated as there is highly likely integrations running on those systems which may have whitelisted IP addresses.
Since the IP address will likely change on this migration from one virtual machine to another virtual machine, the IP address will change, so you will need to be very conscious that that this can be a disruptive migration for the individual cPanel accounts that are being migrated.
All that being said, let’s jump into the details of some of the hands on elements.
Step 4 – Create a Migration Template Tracker
You need a process to control the flow of the migration so you know where you are up to. Something basic in a spreadsheet is more than sufficient for this process. You need to define the steps you need to do for each cPanel account so you can be confident that the migration can be classified as successful both from a technical standpoint and also that of the client. Even better, get a dummy cPanel account created so you can iron out any critical issues before you start to look at the migration of any Live cPanel accounts.
Some considerations / steps you may like to consider as part of this process;
- cPanel Account
- What websites are hosted – We all know you shouldn’t host multiple websites under a single cPanel account for security reasons, but we all know that people do…
- Where is the DNS managed – Can you edit directly or do you need the client to do this, or their development partner?
- Checkbox to say if you have migrated the website to the new server
- Checkbox to say if you have migrated the A Record in the DNS to point to the new server
- Checkbox to say if you have regenerated or installed any SSL certificates on the new server
- Checkbox to say if the site is loading correctly over SSL
- Checkbox to say if you have contacted the client to confirm they are happy with the migration
The reality is, the above checklist if hugely dependent on the type of websites/systems hosted on the cPanel accounts and your understanding of what is on there. If you are a hands-off type of setup then you are going to need to treat this process significantly different. You may also need to take specific action for unresponsive owners of cPanel accounts such as providing cut-off dates for when the old server will be switched off to ensure people have enough time to act on the migration.
Step 5 – Understand the Process for WHM cPanel to WHM cPanel Migration
The process of migrating an entire WHM cPanel environment to another server can be challenging. So you need to understand the intricacies of how this works.
From a purely technical standpoint, the process is usually relatively straight forward to migrate cPanel accounts between servers as can be seen in the diagram below;
Once you’ve understood the steps involved in a migration, you need to see this in practice within your environment to see how this works. Below are a selection of screenshots of the process in action so you can see the types of things that happen when you are using the WHM cPanel Migration Tool.
Step 6 – On New Server, Connect to Old Server via WHM cPanel Transfer Tool
As you can see in the image below, the way this works it that you pull the cPanel account into your new environment, rather than the old environment pushing the cPanel account to your new environment.
Once you click the button at the bottom of the page, you’ll notice a session starts to get created;
Step 7 – Review Source and Destination Configurations
This is where things can start to get “fun” in the sense that when the versions are significantly different this can cause problems. It’s always advisable to keep any kind of migrations relatively close together. Incremental migrations are significantly easier to manage than major version migrations.
Once you’ve connected the session, WHM cPanel will prompt you about some of the differences between your source and target virtual machines to help you assess the risk involved.
Step 6 – Select an Account to Migrate
I say account, because you are in a significantly better position to do this on a cPanel account by cPanel account basis rather than just transferring everything over.
What you will notice in the right hand column is that there is an Overwrite section. In the scenario whereby you have to do multiple migrations for a single cPanel account to the new server such as when the initial migration fails, you have the option to overwrite the changes. In my experience though, this rarely works well. I’ve found it best to delete the cPanel account from the new server, then do a fresh migration of that cPanel account.
Step 7 – Select Packages to Transfer
Packages in this sense are for when you have created the type of bronze – silver – gold type packages which allow different cPanel users to access different sets of features based on the price point they are subscribed to. You may or may not use this method, but if you do, then make sure to transfer them across.
Step 8 – Select Service Configurations to Migrate
There are things that you have installed on WHM cPanel to manage your environment better. You may like to keep these types of tools and configurations migrated over to you new server to avoid having to re-create them.
Step 9 – Migrate a Single cPanel Account
As you can see in the screenshot below, the process once you’ve selected a single cPanel account to be migrated you see a real time transfer process so you can be confident things are happening.
As the process is running along you’ll notice the progress;
Then once it’s transferred successfully you’ll notice it starts to restore fully;
Step 10 – Review PHP Versions
This is more just a point to note, if you are also upgrading the PHP versions at the same time, you may be testing how more recent PHP versions are compatible with your migration. You will likely come across issues related to PHP versions not being compatible with more recent versions. This is beyond the scope of this blog post, but it is being mentioned as a common reason for upgrading systems is to ensure new technology is being supported and there are a lot of considerations throughout the process. I’ll do another blog post on PHP versioning and WordPress as this is a complex topic.
The screenshot below shows you just the kind of errors you can get when you are upgrading PHP versions on a WordPress website.
Step 11 – Update DNS A Records to Point to new Server
This is very much website specific for where you need to this so I’m skipping over this point.
Step 12 – Confirm Migration is Successful
Once you’ve migrated the website and updated the DNS records, you need to validate that this has worked. Naturally there are a lot of nuances with this such as web browser caches, DNS TTL (Time to Live), application level caches, WordPress caches and more. You need to understand the tech stack you’re working with to ensure a successful migration. As always, if in doubt, try on a different browser, try on a different device, try on a different network etc.
Hopefully this has been a handy guide on how to transfer WHM cPanel accounts from one server to another server along with some of the common pitfalls along the way. While there is an official guide on how to do this, it doesn’t really go into the level of detail that is helpful when you’re actually doing this.
If you’ve been testing XenServer or have been working with the free version for a while, you’ll soon realise that it is little limited in places due to the commercial licences required from Citrix to use some of the features that I would class as fairly basic features, things such as VLANs, automatic updates, SR-IOV and GPU virtualisation to name just a few of the feature limitations. Thankfully Citrix handed XenServer to the open source world which is where XCP-NG Server comes in, this is the open source full featured version of the Xen technology. Awesome.
So below talks you through how to upgrade your XenServer setup to XCP-NG Server.
Download XCP-NG Server
Firstly download the ISO for the latest XCP-NG Server from here, https://xcp-ng.org/#easy-to-install
Create a Bootable USB Containing the ISO
If you are unsure how to do this, follow our guide on how to create a bootable USB using Rufus.
It kind of goes without saying, but I’ll say it anyhow. Make sure you take a full backup of your XenServer via Xen Centre to ensure you can recover if the upgrade fails for whatever reason.
Boot Server from USB containing XCP-NG ISO
Plug the bootable USB drive into your physical server and make sure your BIOS settings are configured so you can boot from the device. Then you can start the upgrade process which it outlined below.
Upgrade XCP-NG Server via Installer
Install XCP-NG Centre
You can continue to use Xen Centre if you prefer, but personally I’d always make sure you’re keeping Xen Server paired with Xen Centre and XCP-NG Server paired with XCP-NG Centre to avoid any compatibility issues as XCP-NG Centre will always be ahead in terms of features and functionality when working with XCP-NG Server. The team supporting XCP-NG Centre are making upstream commits to the Xen Centre software project, but these aren’t guaranteed to be accepted by Citrix and released as a new version.
You can download the latest version of XCP-NG Centre from here, https://github.com/xcp-ng/xenadmin/releases/tag/v20.04.00.32 (at the time of writing), you can see the .msi Windows installer at the bottom of the page.
If in doubt, download this one, then if there is an update waiting you should see a notification in the Notifications part of XCP-NG Centre once you open it up. They don’t make it easy to find these download links and it’s made more confusing when XCP-NG Centre is also referred to as xenadmin on GitHub.
Oh, the joys of networking… A topic that very few people like and/or fully understand. So thought it was about time we covered some of these topics to help clarify common misunderstandings and to help people easily understand networking in general. For simplicity, I’m going to stick with IPv4 IP addresses for now and completely ignore IPv6 IP addresses. I’m also going to completely ignore the concept of CIDR blocks and address ranges within this blog posts to just purely focus on the core concepts.
What are Public and Private IP Addresses
Simply put, there is nothing really different, they are just an IP address, right? Well, kind of yes and no. It all comes down to routing, i.e. how your request from A ultimately reaches B. In simple terms, anything starting with any of the following numbers are classified as ‘Private’ IP addresses;
- 10.0.0.0/8 (10.x.x.x)
- 172.16.0.0/12 (172.16.x.x)
- 192.168.0.0/16 (192.168.x.x)
So thinking through the routing concept again of how you get from A to B. This depends on where A and B ultimately live. Remember, every IP address ultimately routes through to a physical server (i.e. computer) which lives somewhere in the real world – whether that is in your back bedroom or in an Amazon data centre somewhere in the world.
How does Routing Work for Private Address Ranges
So now we understand that an IP address starting with, 10., 172. Or 192. Is classified as a private address – what does this actually mean? As mentioned, ultimately an IP address routes through to a physical piece of computer equipment, so why do we care if an IP address is a public IP address (i.e. not starting with these numbers) or a private IP address? Well, it all comes down to routing, i.e. how the message gets from A to B.
For the purpose of this example, let’s keep things super simple. In the scenario whereby you have a personal home laptop or computer. You likely have a home router+modem that has been provided to you from your internet service provider (ISP), the people who provide the internet connection to your home.
To visualise this, if you open the web browser on your home computer and type the following into the address bar of your favourite browser (Chrome, right?), 126.96.36.199 – you’ll likely be presented with the administrator console for your router+modem that has been provided from your ISP. This allows you to login (likely with a super-secure username/password of admin/admin…) so you can then see all of the devices that are connected to your local network, aka. private network. You’ll likely see your laptops, computers, tablets, mobile phones, smart TVs and IoT devices all connected to your local network either via wired or wireless connections. Cool right?
Ok, so back to the point about routing and private VS public IP addresses.
Simply put, whenever a device that is on your local network attempts to connect to another device, your router decides where to … route … the connection to. For example, if you are on your local network and you are trying to access another device on the local network, the route that the connection from A to B (which often has many steps involved, not just the one) never actually leaves your premises to go the internet for help. Whereas if you were accessing a public IP address (aka. an IP address starting with anything other than the three mentioned) then your request would go out into the internet to find the physical computer hardware that is at this address.
The reality is for public IP addresses is that these are often a single IP address that can have thousands of virtual and/or physical machines sitting behind them, which is where NAT comes in – but we’ll ignore that for the purpose of simplicity. We’ll cover that another time. For the purpose of this blog post, we’ll assume that we’re just accessing different systems based purely on IP addresses and not friendly names such as server-x.contradodigital.com.
What About Modern Routing?
The reality is that with most modern routing this isn’t based on IP address alone, it’s often based on a combination of IP Address and Hostname (aka. the name you type into the browser). What this means is that whenever you type in a hostname into the browser, this ultimately resolves to an IP address that knows how to handle your request and ultimately get you to the destination physical/virtual computer that can serve you the information you need. Thankfully, you never need to worry about that as a user. But from a configuration perspective this is hugely important as if you are designing this setup, you need to be able to configure how to handle incoming requests. That is outside of the scope of this blog post though as this gets into the world of NAT, proxies and reverse-proxies.
Size of Private Networks
Things are a little more nuanced by the three core private IP ranges as they each support a different number of devices connected to that network. Remember, these rules were designed before IPv6 when there were much harder limits placed on networks.
- 10.0.0.0 – 10.255.255.255 supports a total of 16,777,216 addresses and is classed as a single class A network.
- 172.16.0.0 – 172.31.255.255 supports a total of 1,048,576 addresses and is classed as a 16 contiguous class Bs network.
- 192.168.0.0 – 192.168.255.255 supports a total of 65,536 addresses and is classed as a 256 contiguous class Cs.
In simple terms;
- Use 192 IP ranges whenever you have a small number of devices connected, i.e. a home environment
- Use 172 IP ranges whenever you have a medium number of devices connected, i.e. a small business and/or cloud environment that is regionalised. Notice how AWS uses the 172 ranges in EC2 instance hostnames
- Use 10 IP ranges whenever you want maximum control for how the maximum number of devices such as on private networks.
This helps you to determine which of the IP address ranges you are best to use. There are also considerations around network sizes and subnets but again, we’ll cover this in other blog posts.
We’ve already done a long write up about debugging email deliverability issues so I’m not going to go over similar topics here. On the other side of the fence, once you’ve ruled out issues with emails being delivered you’re going to want to focus on the quality of the delivery to ensure your emails don’t get triggered as spam by spam filters. Thankfully there are a lot of technical things you can do to ensure your emails get delivered successfully. All of which I’m not going to go into the details here about what they all mean and how they work. In essence all you need to do is use the handy tool Mail Tester and that will talk you through everything you need to do. It is a seriously awesome tool to give you the knowledge and actionable steps you need to take to increase the quality of your emails to ensure your emails get straight through to your users priority inbox and not their spam box.
At some point in time you’re going to need to migrate a WordPress website from one web server to another web server. Whether that is because you’re moving your own website to another web server, or if you are moving your WordPress website from WordPress.com over to your own self-hosted WordPress setup on your web server.
Thankfully there is a really handy plugin available which allows you to easily migrate your WordPress website with relative ease, and that plugin is called All-in-One WP Migration. But, the WordPress migration with astra theme review is just one part of the process and you need to make sure you’ve got your activities in line to avoid any disruption to your website. We’ve already covered topics such as How to Migrate a Web Server Seamlessly with Zero Downtime and How to Migrate an Ecommerce Website between Servers with Zero Downtime previously, so to avoid repeating a lot of the other considerations you need to take into account we’ll be omitting them from this blog post. So we’ll be purely focusing on how to use the All-in-One WP Migration plugin.
Step 1 – Download your Website
Firstly, download and install the All-in-One WP Migration plugin via the usual route on the website you are looking to migrate elsewhere. Once installed go to, WordPress Admin > All-in-One WP Migration > Export and select where you would like to export the website to. I’d recommend exporting to File as this will download the website to the computer you are doing this work on. Exporting to File will make your life a little easier in the next step which is to import the website into a new installation.
This option will download your entire website including files and database content.
Step 2 – Install WordPress on the New Web Server
Now you need to prepare the new web server. Ideally you’d do this before so you have time to iron out any kinks. You need to install WordPress via the usual mechanism you do this. This can vary between servers and web hosts or using the famous WordPress one-click-install option.
Once you’ve installed WordPress on the new web server you’ll need to install the All-in-One WP Migration plugin again.
Step 3 – Upload your Backup File
Now it’s time to upload the backup file from Step 1 to your WordPress installation on the new web server as outlined in Step 2. Important to note that many web servers out of the box limit the file upload size to around 2mb, so it’s likely you’ll need to temporarily increase the max_file_size and max_post_size settings within your php.ini file to make sure it is large enough to handle the upload.
To import your backup file simple navigate to, WordPress Admin > All-in-One WP Migration > Import, and you can import your backup file easily;
Once this has complete you’ll need to login to the website again as the default username and password you created in Step 2 will have been overwritten by the username and password that you used on the website when it was hosted on the old web server.
And it really is that simple to migrate a WordPress website between web servers or from WordPress.com over to a self-hosted version of WordPress. Naturally there are a lot of nuances along the way when working with web servers, DNS and file transfers so if you haven’t done this before make sure you give this a go on a test website initially. For low traffic websites the risk is extremely low. But for high traffic websites, ecommerce websites or heavily integrated websites then you need to plan these activities in a lot more detail to ensure its clear what the steps are to complete this successfully in the first run. There are often a lot more things to think about along the way, for example you may have a Mail Server or FTP server or non-WordPress databases also running on the old web server – you need to consider how you’re going to migrate these things as part of the process too if you’re using those. Some setups are simpler than others, but always consider as much as you can to minimise any issues during a migration.
If you can remember all the cryptic commands within the Vi text editor on Linux then you are some kind of genius. For us mere mortals, the quickest way to edit files on Linux is to bin off Vi and move over to Nano. There, I said it, get over it. Nano is better than Vi hands down.
But in the unfortunate event you need to do a bit of Vi work before you can move over to Nano, for example to configure a network configuration file or to configure a Yum repositories configuration file for example, then you need to know how to work with Vi so you can get through that painful process as quick as possible.
Here are some handy Vi commands;
- Open a file: vi filename.txt
- Edit the file – aka. go into ‘insert mode’: Press the letter ‘i’ once you have opened the file
- Change what ever you need to do as usual
- Exit from Insert Mode: Press ESC
- Prepare to exit the file: Press colon :
- Now save and exit the file: Press, wq, then enter
- Whoops I messed up: Within Vi there are so many commands that seem to just utterly break the editor unless you know what they do that is can be difficult to exit out of the thing. If in doubt press ESC or CTRL + Q or CTRL + C and you should get back to where you need. Then exit the file without saving by pressing, :, q!, enter
I mean, simple, right?!?! Anyhow, that’s how you quickly edit the files you need and recover from when Vi has gone a bit crazy.