“That hosting partner of ours isn’t worth much – our website even goes down a few times a year – but most of the time, everything works somehow. Most importantly, we don’t want to migrate anywhere!”

The biggest obstacle to switching from the current hosting provider to a better one is almost always migration. The dreaded data transfer from one hosting solution to another is without exception accompanied by an outage and quite a few risks. Moreover, it is often the case that when contemplating migration, the necessity to make changes to the client’s application is discovered, without which the migration cannot move forward (i.e. the application wouldn’t work properly after migrating it to the new solution).  All in all, web migration is no picnic. 

But what about the risks that go along with not migrating? Many don’t even consider them since “everything works” but these invisible dangers are often much larger and their potential consequences much more severe.

Let’s take a look at the main anti-migration arguments, how we address those at vshosting~, and what dangers go along with preserving the status quo at all costs. 

Application or technology changes 

The number one factor deterring from web migration is most often the necessity to make application or technology changes. This is a usual requirement for migration given the current application runs on outdated technology or is incompatible with the new hosting solution. 

The necessity of such change unequivocally presents extra workload for the client’s development team that needs to update the app or learn to work with a different technology.  This might be further complicated by the fact that some clients don’t have a development team at their disposal which happens to be quite common among smaller projects. 

On the other hand, the outdatedness or inadequacy of the technologies used is in no way merely an obstacle to migrating to another hosting provider. It is also, and perhaps more importantly, a hindrance to further growth of the internet project, a risk for its security and more.  Therefore, it is advisable to implement the recommended applicational and technological changes regardless of migration. After they have been put in place, switching over to virtually any provider will have become a piece of cake.  

Outdated technologies

An application using a no longer supported or utterly obscure technology often proves to be an obstacle to migration. For example,  an app written in PHP 5.2 is essentially un-migratable because it lacks compatibility with virtually any of the current technologies. It is, therefore, necessary to update it to a more recent, fully supported version. 

Application changes are no picnic, that’s for sure, and they cost a lot of developer time. On the other hand, running an application using outdated technology is exceptionally dangerous – migration or no migration. For instance, PHP 5.2 is no longer supported and eligible for neither security updates or bug fixes. Aside from incompatibility with modern hosting solutions, such application is then vulnerable to various security attacks and hacks. Considering the current GDPR legislation, this presents a risk of fines that can be catastrophic for the business (fine value of up to 4 % of revenue). Besides, outdated applications don’t tend to be prepared to deal with a significant rise in traffic so if you wish to further grow your business, updating your app is unavoidable either way. 

Simply put: if an application cannot be migrated, it pays off to thoroughly consider why that is and to fix the problem. Since with extremely high probability, something is terribly wrong. Regardless of migration and hosting, serious risks endanger your business. 

Compatibility with the hosting solution

Another common scenario is the necessity to shift towards a new technology that will be compatible with the newly selected hosting solution. This typically happens in the event of a client deciding to migrate from simple, non-redundant infrastructure to a cluster or if he aims to move towards a scalable solution but his application is not prepared for scaling.

An example would be migration from a single database server to a database cluster, where we recommend to our client to switch to Galera from a single node to ensure ideal functionality. Galera is the perfect solution for a cluster and will prove to be an advantage for the client in the long run. However, his developers will have to learn to work with a new technology, which is rarely a welcome situation. 

Service windows and other inconveniences

A further source of worry when it comes to migration is the necessity of a certain service window, where the client’s app simply doesn’t run. This step cannot be circumvented and in the case of large projects can even encompass an entire night. Even the toughest e-shoppers feel distressed by the idea.

At vshosting~, we do everything in our power to make the outage as short as possible. Unfortunately, the entire process has its technological limitations that are set in stone. For this reason, it is key to schedule the service window so that the impact on the client’s business is as small as possible. Furthermore, we thoroughly test the new hosting solution before the migration itself to prevent the emergence of complications that would prolong the out-of-operation period. 

What if something goes wrong?

Migration is a complicated process and there is a lot of room for making mistakes. In consequence, it is important to only switch over to providers who have extensive migration experience. Those can minimise the potential risks via thorough analysis and diligent testing of the new hosting infrastructure. And should something go sideways nonetheless, they’re capable of rapidly solving the situation. 

A good example can again be the migration from a single node database to e.g. a 3-node one. Should the balancing among the nodes not work perfectly after migration, experienced administrators are able to temporarily direct the database solution to a single node. As a result, the application can function without any issues and the administrators have time to get to the bottom of the balancing issue in the background. When all is resolved, they switch the database over to the 3-node solution.

In emergency cases, there is always the option of doing a rollback, that is returning everything to its original, pre-migration state. Based on our experience, however, it is more effective to try and solve the given problem as quickly as possible (e.g. by an emergy change of server settings as in the database example above) and finish migrating. The problem, which tends to be of the application sort, can be addressed after that. Unsurprisingly, even here we recommend choosing an experienced hosting provider who is capable of dealing with such unexpected situations in an agile manner. 

At vshosting~, you don’t need to fear migration 

Migration to vshosting~ is no reason for concerns – we have an experienced team of professionals directly in our datacentre who migrate internet projects on a daily basis. When it comes to very large migrations, we conduct dozens of those each year. Thanks to our extensive know-how, we are able to prevent the vast majority of potential risks and make sure everything runs smoothly. 

Before the migration itself, we thoroughly analyse and test the application – we are, among other things, able to evaluate the performance of the entire solution using specialised tests. Based on the initial analysis, we provide recommendations regarding application changes to the client and point out what to pay attention to, what to change, and what to steer clear of. 

Moreover, we design hosting solutions individually and customise them to the needs of each application. The new solution is then thoroughly tested including its compatibility with the client’s app and its synchronisation with all implemented systems (e.g. the warehousing system, CMS, redaction system, etc.). Thanks to that, the new solution gets tweaked to perfection before we even start with the migration.

In specific cases, for instance, when the client has no IT team of his own, we are even capable of conducting the entire migration process for him (although only in cases where no application changes are necessary). The client then needs to put in only minimal effort: to test the functionality of the new solution, to agree to migration start and so on.

To minimise the impact of migration on the client’s business, we carefully plan its date and time together with him. Because our experienced administrators and technicians are present in the datacenter nonstop, we have no problem whatsoever with conducting the migration in the middle of the night, any day of the week.

Should complications arise, preventative measures notwithstanding, we very quickly identify their causes and solve the problem because our experts monitor dozens of the web’s parameters, 24/7.