“If the transition process is managed poorly – and unfortunately, it often is – a migration can cause more harm than good. So, where do businesses typically go wrong?”
If the recent news surrounding Myspace and TSB teaches us anything, it’s that server migration is fraught with risk, write Barney Taylor, Managing Director, Ensono, Europe and Sean Roberts, General Manager, Public Cloud, Ensono
Of course, there are plenty of legitimate reasons for moving workloads and applications – from cloud migration to application rationalisation – but rarely is the move an easy one. Successful server migrations are never an accident. They’re the result of commitment to intelligent planning and preparation.
If the transition process is managed poorly – and unfortunately, it often is – a migration can cause more harm than good. Extended or unplanned downtime, data breaches, and data loss can all cause reputational and financial harm. Vendor lock-in, data duplication, and strains on internal staff can add to that damage.
So where do businesses commonly go wrong?
Server Migration: Common Mistakes and Ways to Avoid Them
The most common mistake tends to involve a lack of understanding of the applications being migrated. Concentrating on servers only is missing a trick and moving them without integrating dependencies can inadvertently break them. This is where many problems arise.
Not all applications communicate over known communication paths, and dependencies may be more complex than first assumed. Where applications are found to be have hard dependencies, it will be necessary to make changes to individual applications first in order to make them more loosely coupled. This is especially true of large enterprises (and large database servers in particular) where applications are usually closely coupled.
It’s therefore important to conduct an inventory of all legacy applications that are to be migrated.
The most successful server migrations are always undertaken by businesses which understand and mitigate the risks involved. This can often be a daunting task without engaging with a partner, especially if a business lacks the internal expertise.
All key stakeholders, including server, network and application teams, must be informed of the clear sequence of events, and an alternative plan of action.
This is where having a cross-functional and collaborative team is important under the umbrella of a change programme. A smart use of technology can always be made redundant without the right process and team of people behind it, and a server migration, in particular, always needs this. Internal and external parties must work to an agreed plan to ensure that any hurdles along the way are addressed as efficiently and effectively as possible.
Planning of the estate is key, alongside having the right level of due diligence, and this boils down to having a robust migration inventory. The best inventories also consider appropriate timeframes and risk profiles. Most organisations will default to SaaS, PaaS and IaaS in that order, but other compelling events, such as data center closures, may result in a two-step process, such as IaaS then to PaaS at a later date.
End-to-end performance testing is a crucial part of gauging risk. Pre-production deployment is the time to really nail the process, while you’re still connected to the management network.
During this time, it is generally worthwhile piloting some low risk applications, carrying out some development tests, and then working your way up to higher risk applications. By increasing the risk gradually, you are less likely to experience issues as you become more confident in the process and the way it works and can take on bigger and more complex applications.
But nevertheless, post-deployment is just as crucial, and servers should really remain in a somewhat ‘intensive care’ state post-migration.
This is because, in new environments, servers usually behave differently than on-premise, especially when hit with a volume of users. The IT team must be ready to jump on these kinds of issues quickly, to allow the server and applications to become stable and fully-functioning in that environment.
In order to make a migration process as robust as possible, businesses must also back-up all data before the migration takes place. This will ensure that if hiccups happen, resources are available in a timely manner.
Migrating a server from one location to another is always a nail-biting exercise – the consequences for the business can be severe, hampering customer experience, reputation and ultimately revenue.
Take Myspace’s data outage as an example: somewhere along the way before the major outage happened, the company were unable to revert back and restore the 12 years’ worth of data that was lost.
While we don’t know the exact reasons for this migration, a lack of backing-up data seems to have changed this outage from being inconvenient to a disaster.
Even the simplest migration can run into hurdles, so it is important that you ensure you have the right culture, skills and processes in place before embarking on the transformation journey.
Whatever the challenges posed by the scope, networking, and security of the migration, careful auditing of an infrastructure’s current state, testing for its future state, and accommodation for when things go wrong can together provide a safe and stable means to migrate.
In many ways, the migration itself should be the easiest part of the process, following the heavy lifting, piloting, and early stage migrations that should happen before.