Select Page

IT Project Delivery Achieving More by Doing Less

IT and project delivery rarely have a positive connection in peoples minds in companies both large and small. It’s almost the norm these days that IT projects always delivery late and over budget. But this doesn’t have to be the case. When you have the right people, processes and governance in place within your IT department, delivering projects becomes a breeze. One specific aspect we’re going to look at in this blog post is around achieving more by doing less. By that I mean how we can increase the throughput of delivery to deliver value to the business faster with the same amount of resource and the same amount of project demands.

Seems impossible, right? Well, no. It all comes down to process, communication and managing dependencies. Let’s dig into this a little more, firstly with an analogy for building a house.

Let’s say you are a housing developer and you have an estate of 100 houses to build. You know that you have 100 houses to build and you know the resources you have on your team for building those houses. Let’s say this breaks down as follows for 100x staff;

  • 1x Site Manager
  • 2x Quantity Surveyors
  • 2x Project Managers / Construction Managers
  • 15x Groundworks People
  • 50x Brick layers
  • 10x Electricians
  • 10x Plumbers
  • 5x Plasterers
  • 4x Roofers
  • 1x Carpet Fitters


So looking at that split, it sounds fairly sensible for a split of resources to enable delivery of 100x houses. For argument’s sake, let’s say that we have all materials on site at the start of the process to enable us to build the 100x houses without worrying around delivery timelines from suppliers. Before we set the team running ahead with building the units, we need to have a plan, and a plan isn’t purely to build the houses in the fastest time possible. A plan needs to understand resource dependencies, and in this case, this is people. The same as in IT.

Before jumping into the details of what this means. We have to think back to what this means for a business and why project delivery is so important. It comes down to two factors;

  • Capital tied up in Work-in-Progress, meaning that this is an opportunity cost as this limits what we can invest in elsewhere and often can result in having to source additional finance to support investments, when in fact with a change of approach that may not be needed.
  • Lost revenue for every day something is not delivered. In this case for houses, that is the profit that could be gained today by selling or renting a completed house VS waiting 3 or 6 months for that profit to be released.


The same is true in IT. All IT projects deliver value to the business, enabling the business to move faster, be more agile, and keep ahead of the competition. Delays in delivery in IT result in the company becoming a laggard in the industry.

So, let’s get back to the plan for building 100 houses. In a nut shell, we have three core approaches;

  • Delivery Plan 1 – Big Bang: We build all 100 houses, then start to sell them
  • Delivery Plan 2 – Phased Delivery: We build the houses in batches of 25 so we can release 4x lots for sale at one time. This tends to be how the majority of housing developments work.
  • Delivery Plan 3 – Agile Delivery: We build and sell the houses one by one as they become available.


Taking into account the considerations around having capital tied up and lost revenue, let’s visualize what this means in practice. For the purpose of illustration we’re going to assume;

  • Every property is rented
  • Every house takes 1 week to build end to end
  • Every house generates a rental income of £750 per month
  • The house is rented out the day it is completed


What this looks like in numbers;


As we can see from the above graph, the Agile delivery plan, selling 1 house at a time, results in a higher cumulative revenue by the end of the 110 weeks. But this is not just a small difference, this is a significant performance improvement.


Delivery Plan 2 – Phase is 341% more efficient than Delivery Plan 1 – Big Bang. Delivering £937,500 revenue and releasing that working capital to the business in the 12 months.

Delivery Plan 3 – Agile is 25% more efficient than Plan 2 – Phased. Delivering an additional £300,000 revenue and releasing that working capital to the business in the 12 months.

When compared to the least VS worst efficient delivery method for providing value, Delivery Plan 3 – Agile is 450% more efficient than Delivery Plan 1 – Big Bang. Delivering an additional £1,237,500 revenue and releasing that working capital to the business in the 12 months.

Meaning you can delivery 4.5x the value to the business without changing either budgets or people resources available.

Now we know things aren’t always as smooth as this in reality, there are a lot of nuances which get in the way of this perfect scenario. And this brings us onto the main point of this blog post around achieving more by doing less. It’s kind of a given these days that Agile is the way forward for the vast majority of IT projects, or a combination of a more Waterfall-Agile (aka. Wagile) delivery for hugely complex projects that have a lot of dependencies both in and outside of IT.

There are always blockers throughout any process, whether that is building houses or delivery IT projects. Taking the house building example, let’s say for arguments sake that it takes a carpet fitter 2 weeks to fit carpets throughout an entire house. Regardless of which delivery method you choose, you ultimately have a bottle neck and this bottle neck gets compounded the more efficient your overall delivery method is (Big Bang –> Agile). In the Agile example, you are already 1 week over estimate (100% over planned time for delivery) by the time you deliver your first property because of the bottle neck with the carpet fitter. Not great. But, that’s still more efficient than Deliver Plan 2 – Phased because you’ve still sold one house in 2 weeks rather than none.


So how does this apply to IT project delivery?

Hopefully the analogies above has put things into context and you can relate to the elements within IT. The reality for something like IT is that it gets even more complex from the overly simplified example above.

Imagine you have 100x IT projects that you need to deliver and 100x IT staff. The nuances of skills, specialties and experience of staff will hugely vary which can result in issues cropping up that should never have been an issue if the right processes were in place an dependency on a few key resources where they only know how a certain system or technology works. Rarely in IT are we building things from scratch, we’re often either extending or upgrading current functionality and/or integrating with these systems.

Imagine having to re-build a wall on a house because it was done wrong on the first attempt and because that work wasn’t managed properly and peer reviewed for quality. This is what happens in IT on a near daily basis in many organisations, albeit it’s not quite a visible as this. It’s more like having to rebuild a server, refactor poorly written and unsupportable code etc. Ultimately, it’s all waste that needs to be removed.

What this often results in is a situation whereby multiple projects that are running in parallel agile delivery methods end up stuck on the same bottle necks with resources who are either specialized in a specific technology or only have access to that system and this can add weeks and months onto the delivery of a project which is ineffective.

Take the simple example, if we have 21x staff and 4x projects to deliver. We could split this up as;

  • Parallel Projects: 4x Projects of 5x staff and 1x shared resources with specialist skills
  • Sequential Projects: 1x Project of 21x staff including the specialist resource

Let’s say that each project takes a total of 4 weeks to deliver.

Given that, in the Parallel Projects delivery method each of the 4x projects will be complete in 4 weeks, so we can deliver 4x projects in 4x weeks, but, only at the end of the 4 weeks.

When compared with the Sequential Projects delivery method, we’d deliver 1x project per week for each of the 4x weeks. Delivering value faster and without blockers. The reality is though that while the 20x staff working on these 4x projects are wanting to get them over the line, the specialist resource is likely working across 20x, 30x, 50x other projects too where they are required only for a small part of the project. So this person/area soon becomes a significant blocker on many different projects resulting in large delays across the entire IT department.


So what’s the solution?

The reality is that this is a complex beast to manage but there are a set of guiding principles that can significantly enhance IT project delivery to increase the throughput of work to delivery more by doing less. These principles are;

  1. Identify common blockers on projects, and put in place measures to ensure that no longer becomes a blocker. Whether that is training and upskilling other staff, putting in place processes to ensure less experienced staff can still do work in this area as long as it is peer reviewed by an experienced member of staff etc.
  2. Significantly reduce parallel work streams, you can’t effectively split your workforce more than 25% across active projects, i.e. 100x active projects would require 500x staff. If you’ve only got 100x staff, you need to manage the active projects to around 25x projects at any point in time so you have 5x people per project so you can focus. The rest go into the backlog to be worked on in suitable priority. You will always find that you’ll need that 6th person at some point, and you want them to be available when you need them, not to delay the 5x people working full time on that project. It is not IT’s job to prioritise projects based on either opinion, seniority of who asked for it, or whoever shouts the loudest. Put in place a process where the business has a forum to collaborate with senior stakeholders so they can inform IT what the IT priorities are then IT can focus on getting things delivered. Also keep in mind that you should probably split this as 50% Projects, 25% Business-as-Usual (BAU) support and 25% Internal IT Improvement Projects (as often these underlying issues cause delays on all projects so they need to be resolved).
  3. Arrange staff into project delivery squads that can be focused on the delivery of a single project without distractions.
  4. Documented processes are absolutely key to getting this right, and making sure that staff are fully aware of the processes. Far too often processes are informal and/or misunderstood which causes confusion for staff. Basic governance is key.
  5. Tooling, training and peer review help to spread skills and knowledge throughout the delivery squads to reduce dependencies on single people and increase productivity. Build this into the processes.

Your Container Bone is Connected to Your Type 2 Hypervisor Bone

Ok, this is a bit of a play on words to help people understand how technology components are connected together. As the old song goes, the toe bone connected to the foot bone, etc. in the Dem Bones song. We’ll skip over the anatomical inaccuracies of those words… the point is, things are connected.

In the world of technology, things are more connected than you can ever imagine under the hood, it’s no wonder why people struggle to grasp the concepts of how the pieces of the puzzle fit together and why some things work in one area and the same thing doesn’t work in another area. It all comes down to connectivity and how technology components are ultimately built on top of other technology components to perform the features you see as a technical user.


{Insert Latest Technology Trend Here} is the Future – Implement it now!

Is it? Is it really? Is it really anything new under the hood? And if it truly is, can you draw a diagram to explain how and why it is better than the plethora of other options that are already available and have been available for years? If you can’t, you need to go back to the drawing board to start to understand how things plug in, work together and how the entire technology stack is built on the foundations of those technologies that have come before.

Take Docker as a prime example. I’m picking on Docker a little here as I’m getting a little bored of discussions about how Docker is the future of the universe. In reality, it’s not really that different than technology that has been around for over a decade other than the added ability to create cross-node Docker clusters through the likes of Kubernetes and some pre-packaged (aka. inflexible) ‘fake’ images – yeah, that’s pretty cool, but really? Is it actually necessary for the 95% of systems out there? In any real world situation, you’d just beef up a VM and ensure there is decent resources, proper failover and redundancy in place – job done. Unless you’re working for the likes of Google and Facebook, you should probably take a pragmatic approach and achieve the same result with 5% of the effort required.

Look, I’m not against these technologies, they’re great. But. You have to have the resource, technical capability in the specific software and technical understanding of the full technology stack to understand how everything fits together, and that comes with a cost. This isn’t something that comes overnight for anyone, so you’ve either got to be prepared to put in a lot of effort training and developing your staff, or get your cheque book open with your quill ink pen at hand ready to start writing some fairly hefty payments to get the staff/contractors in you need to develop this type of setup.


Your {Insert Latest Technology Trend Here} Bone is Connected To Your…

Taking a look at WordPress specifically as this came up in a recent conversation to help to illustrate how all this fits together. Basically this fairly large diagram below (click/right click and open in new tab, to open in full screen to view!) helps to highlight how the different types of technologies fit together in the technology stack. WordPress is simply the one that is highlighted throughout the diagram with the others less of a focus to help to illustrate the point.

What you will notice in the diagram below is how there are so many flavours of technology at the same technology stack layer that you need to understand how they are aligned. There is an enormous amount of similarity between a lot of the common technologies that are branded as {Insert Latest Technology Trend Here} – So when you get into the detail and discussions, you need to make sure your discussion point holds weight and this only comes with a solid understanding of how the technology stack works.



Basically at the simplest level…. Your Physical Hardware is connected to the Type 1 Hypervisor … is connected to the Type 2 Hypervisor … is connected to your application. Simple, right? Well, as you’ve probably realised when reading the docs from all the software providers at the different layers of the technology stack, it’s not always that clear what sits where.

The core concepts of the different layers are as follows…


Physical Hardware Virtualisation – Single Virtual Machines

This layer basically securely segregates your hardware resources into logical units that have defined boundaries. Think of this in the same concept of a piece of land with houses on. Once you’ve built one house (aka. a Virtual Machine) then that house cannot suddenly decide to take resources from the second house since it is not allowed to access that space.


Type 2 Hypervisor Technology –aka. Landlord / Owner Controlled

Imagine this as a property you own, whether you live in the property or rent it out. As the ultimate owner of the property, you decide what can or cannot be done within the physical space. You determine the boundaries of which the tenant can operate. You may decide that there can only be one tenant in this location, it may be your own organisation, or you may open this out to other organisations, either way – this is your choice. By this very definition, in technical terms, you get to decide what software can or cannot operate in this environment – aka. Shoes off in the house rules etc.

As you’ll see in the diagram, there is a wide variety of software that allows you to configure these Type 2 Hypervisor technologies to suit your needs – each with their own specific pieces of functionality.


Type 2 Hypervisor Technology – Account Specific

This is the next layer which determines what specific accounts can or cannot do. For example, taking the landlord example a little further, let’s say you have a house (aka. the Type 2 Hypervisor Technology) and you can then decide if Tenant 1 in Room X is allowed to ‘keep pets’ VS Tenant 2 in Room Y is not allowed to ‘keep pets’. That is the level of control that is capable with technology layers.

Hence why the security element is explained as such, anything within this layer is the security of the owner of this element. For example, imagine a tenant who is the owner of a rental room in a house. If this tenant decided host a dinner party of well-rounded guests, then all of a sudden decided to also invite around a rowdy crowd of guests (aka. bad actors in the web space, sending spam or receiving lots of spam traffic), then this is clearly going to interrupt the evening. The reality of web hosting is no different. Disruption results is lower performance for other websites hosted within this layer.

If you need the security of performance, you need to be moving to a service / subscription / plan with your provider that can accommodate you needs which will naturally come with an additional price tag. Hopefully that explains why – In summary, it’s because you are reserving an amount of hardware resources (CPU, RAM, HDD) to secure the performance needed of your server to keep the lights on for your end customers to do business with you.



Hopefully the diagram above helps to convey some of the common technologies and where they sit in the layers. When I say layers here, I’m not talking about the traditional OSI Layer Model as quite frankly that has been broken for years – Another blow post to follow on what I believe this should look like in the modern world.

It’s also important to understand these layers and how they blend with the cloud technology providers. A lot of the time this type of information is abstracted from you to “help” (but it rarely does from an understanding perspective…). Regardless of where the technology stack ultimately lives, it’s important to understand these building blocks.


Cloud is the Future!

As the saying goes, the cloud is just someone else’s computer. And that goes for the likes of Amazon Web Services (AWS), Microsoft Azure or Google Cloud Platform (GCP). All they have under the hood is some fancy bit of tech to easily create the different bits of the diagram above, and many more elements too that are not in that diagram. By the way, there are some pretty awesome open source versions of the cloud tech they are using, or derivatives of it – but I’ll leave that for another blog post!

When you get under the skin of the majority of cloud environments, they are often using open source technology in the background, branded as their own service. Don’t be fooled! It’s not magic, it’s marketing.

This blog post isn’t about cloud VS non-cloud, I’ll do a blog post in a while about how the cloud is doomed for failure in the next 5 – 10 years once people realise the true cost involved, but that’s for another time. This is when open source cloud platforms will really start to come into their own and usage really starts to grow in a hockey stick manner.

Understanding How Sub-Domains and Addon Domains Work on cPanel

Ok so this was an interesting question that came through recently when I was asked about why someone couldn’t access files via a nice URL that they could see on the cPanel File Explorer and what they needed to do so they could access the files. There was a couple of very interesting technical scenarios that had been done as a workaround, but fundamentally this was due to a lack of understanding of how routing works from Point A, the user in the web browser typing in a URL, through to Point Z, the technical gubbins deciding on what content to serve.

So we went back to the drawing board to show how the different parts of the process work.



Simple, right?

Ok, let’s break this out into the few core areas and let’s discuss how the different parts fit together.


Step 1 – User Accessing Domain / URL in Web Browser

Hopefully this bit is fairly self-explanatory, the user types in something into their web browser, and this magically returns the correct information.


Step 2 – DNS

This is often a step that a lot of people misunderstand, and with good reason – it’s not a straight forward topic to understand. I’ll to a more detailed blog post about DNS at some point in the future as it is a hugely misunderstood topic.

Ultimately though, the DNS translates the user friendly domain / URL from Step 1 into an IP address which is the server where your website(s) live.


Step 3 – cPanel Routing

Ok, this is a little over simplified as there are quite a few steps between Step 2 and Step 3, but for the purpose of the average user of cPanel, this is sufficient to explain how this works. If you are a more advanced user such as a user working with WHM cPanel or an infrastructure engineer working at the physical hardware layer you’ll understand there is a lot more in between. This blog post is not designed to cover those details as they don’t apply to the average cPanel user.

Ultimately all we care about as a standard cPanel user is that Step 1 and Step 2 magically route through to my cPanel account.

From here, this is where we have full control over how a website URL route through to the correct files on your cPanel account. It doesn’t matter if the site is categorised as a Main Domain, Sub-Domain or Addon Domain in cPanel terminology. All we really care about are two concepts;

  • Domain
  • Document Root

Hopefully the Domain is obvious what we are talking about here, the, or

What confuses a lot of people is the concept of a Document Root. This is not just cPanel terminology, this is terminology used across a wide range of software and applications. In a nutshell, it simply means where the starting point is for documents related to this ‘thing’.

So let’s put that into context.

For a Main Domain such as, the Document Root is likely set to /public_html/ by default.

For an Sub-Domain such as, the Document Root is likely set to /public_html/

For an Addon Domain such as, the Document Root is likely set to /public_html/


And it really is as simple as that. It’s all about how you’ve got things configured within cPanel which determines how these things actually work. There are configuration screens within cPanel where you can manage Addon Domains and Sub-Domains, so you can technically configure these however you want. It would always be recommended to keep things sensible when doing this as mis-configurations can result in a lot of unexpected results.


Word of Caution

While you can do this within cPanel, you probably shouldn’t for security reasons. You need to understand that in the scenario whereby a single website or sub-domain or addon domain contained within the single cPanel account gets hacked, this can spread with ease to every other website hosted within this single cPanel account.

If you are containing multiple websites within a single cPanel account, you need to accept this risk and be prepared for the worst case scenario. If these are all your own websites and you fully manage and control them, then this significantly reduces the risk – assuming you know what you are doing. But please, never host multiple websites within a single cPanel account where there are multiple website administrators such as hosting websites for clients, friends, family, contacts, charitable organisations etc. You need to ensure that each of those websites is as an absolute minimum set up as a separate cPanel account as you cannot trust the actions of other website administrators to meet your security standards.

How to Transfer WHM cPanel from One Server to Another Server

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;



Migration Process

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.

How to Upgrade XenServer to XCP-NG Server

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,


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.


Backup XenServer

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, (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.

Understanding the Differences in Managed VS Unmanaged Web Hosting

Web hosting is web hosting, right? Well… no.

So how do you assess the difference in web hosting from Company X to Company Y and with all the different terminology and packages available – particularly if you’re not a technical boffin?

Don’t worry, it’s confusing for a reason, and that reason is that it is so that it’s not easy to compare things between suppliers, you have to take them on good faith that they are covering off what you need. This is fine for basic personal usage and don’t mind when things go wrong, but for small and medium sized business use, this is not adequate, so you need to understand what you are paying for and ultimately who is responsible for the different aspects – you – or – your web hosting provider.

You may think that your web hosting provider is simply doing everything they should be doing for you, but that is rarely the case. As a general rule of thumb, the less you pay, the more you are responsible for. And that means that you need the skills, expertise and time to deal with situations as they arise, and they arise on a regular basis – someone has to take care of your infrastructure.

Below is a starter for 10 for the types of things that are common ‘things’ that need doing on web hosting infrastructure with a comparison of how cheaper providers generally manage things VS managed web hosting providers, like ourselves and many other quality providers out there too.

Hopefully this information below helps you to see as a non-technical person what is really happening behind the scenes and how the £ pricing for the different providers generally tilts the scales between where you are responsible for activities VS where your web hosting company is responsible for the activities.


Activity Unmanaged (Cheaper)

Web Hosting

Who is Responsible For…

Managed (Expensive)

Web Hosting

Who is Responsible For…

Provisioning core server resources for creating your virtual server (Hard disk space, RAM, CPU, Networking, Security Groups, Containers etc… too much to cover here) You Provider
Installing and configuring the operating system You Provider
Installing and configuring core web server Control Panel software You Provider
Server level backups You Provider
Monitoring and managing Operating System level updates You Shared responsibility
Monitoring and managing web server software packages for updates and security patches You Shared responsibility
Monitoring and managing web server infrastructure and resource utilisation (Hard drive, CPU, RAM, IOPS, etc.) – i.e. when your hard disk fills up, your customers can’t place orders via your website You Shared responsibility
Installing and monitoring core infrastructure utilisation software and proactively respond to changes rather than reacting to catastrophes. You Shared responsibility
Designing and managing Networking and Security Groups to ensure you limit your exposure in the situation whereby security breaches happen You Shared responsibility
SSL Certificates for keeping your data safe during transit from your web server to your customers. You Shared responsibility
And a lot more… You Shared responsibility


Look, the above is a huge over simplification of the reality, and there are so many types of unmanaged and managed web hosting solutions that there are an awful lot of nuances in both categories so this is a very simplistic view of the world. Hopefully it helps to show some of the common differences between cheaper (unmanaged) web hosting and more expensive (managed) web hosting solutions.

At Contrado Digital we focus on things that “Just Work”, so as you can guess we tend to sit in the Managed Space, and more expensive. Although even still, we work across the board, for example with enterprise clients we can support through training and development where corporate organisations are wanting to self-manage their infrastructure with their internal staff. The joys are that there are endless options available, so let’s have a chat about your requirements and we can see what works best for you.

Ultimately if you’re reading this post, you probably fall into one of two categories;

  1. A small to medium sized business who needs help? If so, you probably need support via a managed service, whether that is from a single virtual machine hosting one website to a more complex hosted or physical infrastructure that we manage on your behalf.

A large enterprise business who has staff internally who needs help with how to work with self-managed solutions? If so, you probably need some consultancy, training and coaching for staff to manage these solutions effectively through one of more of your cloud providers or on-premise providers.

Understanding Network Private Address Ranges Easily

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.x.x.x)
  • (172.16.x.x)
  • (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?), – 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


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.

  • – supports a total of 16,777,216 addresses and is classed as a single class A network.
  • – supports a total of 1,048,576 addresses and is classed as a 16 contiguous class Bs network.
  • – supports a total of 65,536 addresses and is classed as a 256 contiguous class Cs.

Simple, right?

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.

Understanding Incoterms – International Commercial Terms

As an ecommerce retailer, small or large, you will have a supply chain that likely spans the globe to a lesser or greater degree. Whether you are aware of this or not, ultimately the products you’re purchasing have likely been made outside of the UK. If you’re new to the import/export game then you’ll likely be as confused as everyone else when it comes to how things are shipped around the world and what all the terminology means. This blog post is designed to be a handy resource to simplify the import/export game and terminology so you can get up and running importing and exporting your products with ease.


What are Incoterms?

Simply put, Incoterms is the abbreviation of what is called International Commercial Terms. In other words, a common vocabulary used around the world to explain who is responsible for what and ultimately who holds the risk at the different stages of the shipping process. So we know who to speak to when things don’t quite go according to plan, and if anything is guaranteed, it is that things don’t always go to plan.

For smaller quantities of goods being shipped around the world, you may not need to worry about the finer details of this as it is likely encapsulated within the costs you are paying – but it is always worth being diligent in this area as even when small orders ‘go missing’ you’ve got to take into account the products you’ll need to sell and the profit you need to make to recover this cost through additional sales.

As your order quantities grow, you’re going to want to keep a close eye on Incoterms when dealing with multiple suppliers and customers around the globe. Getting things wrong can be an extremely costly mistake to make.


Understanding Incoterms

The images in this post are referenced to international logistics company OceanAir who have done an excellent job at creating the infographics to simplify these terms into an easy to digest image – once you understand what the terms actually mean. So let’s dig into the terminology first before we look at the images.

One of the common terms that you’ll read throughout the incoterms is a freight forwarder. But what exactly is a freight forwarder? In simple terms, a freight forwarder is a common courier that doesn’t operate shipping vessels.



One of the simplest and most basic shipment arrangements places the minimum responsibility on the seller with greater responsibility on the buyer. In an EX-Works transaction, goods are basically made available for pickup at the shipper/seller’s factory or warehouse and “delivery” is accomplished when the merchandise is released to the consignee’s freight forwarder. The buyer is responsible for making arrangements with their forwarder for insurance, export clearance and handling all other paperwork.


FOB (Free On Board)

FOB means that the shipper/seller uses their freight forwarder to move the merchandise to the port or designated point of origin. Though frequently used to describe inland movement of cargo, FOB specifically refers to ocean or inland waterway transportation of goods. “Delivery” is accomplished when the shipper/seller releases the goods to the buyer’s forwarder. The buyer’s responsibility for insurance and transportation begins at the same moment.


FCA (Free Carrier)

In this type of transaction, the seller is responsible for arranging transportation, but he is acting at the risk and the expense of the buyer. Where in FOB the freight forwarder or carrier is the choice of the buyer, in FCA the seller chooses and works with the freight forwarder or the carrier. “Delivery” is accomplished at a predetermined port or destination point and the buyer is responsible for Insurance.


FAS (Free Alongside Ship)

In these transactions, the buyer bears all the transportation costs and the risk of loss of goods. FAS requires the shipper/seller to clear goods for export, which is a reversal from past practices. Companies selling on these terms will ordinarily use their freight forwarder to clear the goods for export. “Delivery” is accomplished when the goods are turned over to the Buyers Forwarder for insurance and transportation.


CFR (Cost and Freight)

This term formerly known as CNF (C&F) defines two distinct and separate responsibilities-one is dealing with the actual cost of merchandise “C” and the other “F” refers to the freight charges to a predetermined destination point. It is the shipper/seller’s responsibility to get goods from their door to the port of destination. “Delivery” is accomplished at this time. It is the buyer’s responsibility to cover insurance from the port of origin or port of shipment to buyer’s door. Given that the shipper is responsible for transportation, the shipper also chooses the forwarder.


CIF (Cost, Insurance and Freight)

This arrangement similar to CFR, but instead of the buyer insuring the goods for the maritime phase of the voyage, the shipper/seller will insure the merchandise. In this arrangement, the seller usually chooses the forwarder. “Delivery” as above, is accomplished at the port of destination.


CPT (Carriage Paid To)

In CPT transactions the shipper/seller has the same obligations found with CIF, with the addition that the seller has to buy cargo insurance, naming the buyer as the insured while the goods are in transit.


CIP (Carriage and Insurance Paid To)

This term is primarily used for multimodal transport. Because it relies on the carrier’s insurance, the shipper/seller is only required to purchase minimum coverage. When this particular agreement is in force, Freight Forwarders often act in effect, as carriers. The buyer’s insurance is effective when the goods are turned over to the Forwarder.


DAF (Delivered At Frontier)

Here the seller’s responsibility is to hire a forwarder to take goods to a named frontier, which usually a border crossing point, and clear them for export. “Delivery” occurs at this time. The buyer’s responsibility is to arrange with their forwarder for the pick up of the goods after they are cleared for export, carry them across the border, clear them for importation and effect delivery. In most cases, the buyer’s forwarder handles the task of accepting the goods at the border across the foreign soil.


DES (Delivered Ex Ship)

In this type of transaction, it is the seller’s responsibility to get the goods to the port of destination or to engage the forwarder to the move cargo to the port of destination uncleared. “Delivery” occurs at this time. Any destination charges that occur after the ship is docked are the buyer’s responsibility.


DEQ (Delivered Ex Quay)

In this arrangement, the buyer/consignee is responsible for duties and charges and the seller is responsible for delivering the goods to the quay, wharf or port of destination. In a reversal of previous practice, the buyer must also arrange for customs clearance.


DDP (Delivered Duty Paid)

DDP terms tend to be used in intermodal or courier-type shipments. Whereby, the shipper/seller is responsible for dealing with all the tasks involved in moving goods from the manufacturing plant to the buyer/consignee’s door. It is the shipper/seller’s responsibility to insure the goods and absorb all costs and risks including the payment of duty and fees.


DDU (Delivered Duty Unpaid)

This arrangement is basically the same as with DDP, except for the fact that the buyer is responsible for the duty, fees and taxes.

Incoterms Simplified Images

Below are a couple of handy diagrams to show the above incoterms and how they differ from each other.



International Shipping

Clearly international shipping is an extremely complex area and this blog post only gives a very brief overview for common international commercial terms in relation to shipping. Hopefully this at least helps you to understand where your potential risks lie whenever you’re importing or exporting goods around the world.


How to Test the Spammyness of your Emails

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.

How to Migrate a WordPress Website to a New Web Server and Web Host Easily Using All-in-One WP Migration Plugin

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 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 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 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.