New PowerCloud Addon: Recurring Upgrades Keep Your Site Updated Always

We have been going over how to face Application Upgrades issue for a while now. It is a nasty one; so surely we have been delaying it as much as we could, but the time has arrived to confront it.

Why do I say it is “nasty”? There are a number of reasons:

• Each customer has a different history. So, it is a process very difficult to automate.
• Plug-ins make it even more challenging, as there are not always supported in newer application versions. 
  
• If customer has done any application core changes (that does happen often) then a nightmarish landscape starts to unfold.
• You can have two or three new application releases per year, so just consider going through this twice or thrice in a year.
• Customers tend to stick with what works (independently of security), so there are some with VERY old versions of the application without a direct upgrade path to the latest. (So you need to do intermediate upgrades, which results in a repeated nightmare.)

I agree that application maintainers are quickly improving the upgrade processes (i.e., WordPress), but for most real world situations and most applications, it remains to be a tedious, painful, slow, and risky process. (Things can break, you know!).

But let’s face it, what are the alternatives to hosting or managed services providers like ourselves?

• DO NOTHING: This is what most companies do. Let it be a customer problem. As said, customers usually stick to what is working, irrespective of security implications. So, what is the long term consequence of this? Customers sites get hacked, defaced, or abused—and who will fix it (for a fee or otherwise): the hosting or managed service provider. So, what we are doing in this scenario is just delaying the nightmare.

[Read: Stop Getting Hacked: 8 WordPress Security Tips To Keep Hackers At Bay]

• DO SOMETHING – This is a tricky one too. Customers like to stick to what is working. True! But, they don’t like to pay extra. Per the challenges seen above, doing it for free—and properly—is suicidal for the hosting or managed service provider finances. Besides, as it is a tedious, painful, slow and risky process (remember!), no one in the industry will be willing to take the responsibility of doing it for free. This means that you need to convince customers that they should pay for it.

But, it is what it is and we can’t escape reality!

We, at Cloudways, have at least the advantage of working exclusively in cloud environments. As you know, cloud gives flexibility [See: Endless Features & Benefits of Managed Hosting], and this flexibility is precious when confronting nightmarish upgrade scenarios as we will see below.

So after much internal lobbying, the agreed Cloudways approach to this challenging issue is as follows:

• We offer Application Recurring Upgrades as an Add-on. So customers, once briefed of the consequences of NOT upgrading their sites, can weigh the risks, assess the related costs, and make informed decisions.

• There are two fees related to this Add-on: A One-Time Custom Fee and a fixed Recurring Fee.

• The One Time Custom Fee will be determined after our engineers analyse the customer application, application version, plug-ins used, and customizations done. It will change from customer to customer and for each individual install of an application. This fee will cover upgrades from application version currently deployed to the latest stable one.

• The fixed Recurring Fee will ensure application upgrades in the long run. Always! This will be done in close coordination with the customer, as it is a process where the customer’s involvement is very much required. This fee is fixed and varies for each application. (Customers can see the current fees listed in the Add-on page.)

We think that this is a fair and open approach for everyone involved in such processes.

And, retaking on the flexibility that a cloud environment brings when implementing this approach, let’s do a high-level walk-through of the steps involved:

1. We clone the current live server.
2. We perform the necessary steps to upgrade the application, plug-ins, and any other part of the system on the cloned server.
3. We deliver the cloned server to the customer for testing. Production has not been modified in any sense.
4. We work with customer to fix any issues, if found.
5. Once the cloned server is fully functional, we agree with the customer on a final migration date and time. [Read here: Some Common Application Migration Issues & Solutions]
6. On agreed date and time, we do a last sync of files and database from current production server and change the IP from current production server to new upgraded server.
7. Upgrade process is completed. After few days, we delete the old production server.

We hope this helps to clarify the challenges of keeping your systems up-to-date as this post clearly explains our approach. In case you need assistance, feel free to talk to our technical support team at the earliest. Or, check other benefits and features of our Application Upgrades add-on HERE.

Pere Hospital

Pere Hospital (CISSP & OSCP) is the CTO and co-founder of Cloudways Ltd. He has over two decades of experience in IT Security, Risk Analysis and Virtualization Technologies. You can follow Pere on Twitter at @phospital and read his blog at www.perehospital.cat

Get Connected on: Twitter Community Forum