By Simon Mohr, CEO at SEM Solutions
This is the first in a 3 part series, taken from ‘The Ultimate Guide to Cloud Migration’ by Simon Mohr and Databarracks. Next time we’ll break down the six easy steps of the migration process. You can download the full whitepaper here.
The pace at which we’ve come to regard cloud technologies as an everyday utility is staggering. Even the language we use has changed.
Looking back only a few years, people would speak in terms of movement; of the journey towards cloud. Today, it’s often assumed we have arrived at some new technological frontier, and are instead occupied with making improvements – making things bigger, faster and more efficient.
In truth though, no one makes this journey just once. Moving data is, and always will be, an inherent part of owning a digital environment – particularly if part of that environment is hosted by a third party. It’s a universal stage in the technology lifecycle; whether you’re a multinational company or a two-man start-up, migrating data between environments is one of most important processes to get right.
Moving data is, and always will be, an inherent part of owning a digital environment – particularly if part of that environment is hosted by a third party.
It can also be deceptively complicated, and something the uninitiated tend to underestimate. The paper ‘Data Migration in the Global 2000′ from Bloor Research found that only 16% of data migration projects were delivered successfully (e.g. on time and to budget). On paper it’s a just a big copy and paste job, so why do so many migration projects fail to match up to expectations?
For a start, migrating to the cloud is a remote, rather than a physical process; it’s rarely a case of simply moving data from point A to point B. Instead, cloud migrations often arise as a consequence of wider business drivers like corporate growth or restructuring, and so must be simultaneously absorbed into a wider business strategy but regarded as a single, contained process.
The huge and widely broadcasted benefits of moving away from a traditional dedicated environment has generated an atmosphere of urgency around cloud adoption; success stories of companies becoming exponentially more agile, flexible and efficient are common, and the rest of market wants a piece of the action.
However organisations must be careful this enthusiasm doesn’t translate to impatience with the migration process as a whole. Remote migration isn’t inherently risky, but it can be a disruptive process that should be held in equal regard to the expected benefits of the destination environment. Moving to an untested platform without first establishing how suitable it is for the immediate business need (and compatible with the existing environment) is like going on holiday without booking a plane ticket or packing your bags.
Hasty migrations risk two major consequences:
- The migration process is ill-planned and therefore likely to encounter difficulties.
- The destination environment fails to live up to the unreasonable expectations placed on it.
Working with a trusted migration partner sidesteps the majority of potential problems. Cloud computing has proved to be a disruptive technology, and as systems and infrastructure have become more complex, so have the operational skills sitting behind them compartmentalised.
‘Migration’ as a contained skillset has emerged as a part of this process, and as we’ll go on to see, successful migration projects are frequently a consequence of good planning, sufficient resources and, perhaps most fundamentally, the anticipation of the migration process as an intrinsic part of cloud adoption.
The ‘grudge purchase’ and valuing your data
Before we get in to specifics, let’s take a look at one of the main causes of tension during migration projects – cost.
Migrations, particularly for small and medium sized enterprises, are rarely budgeted for. This can be for two reasons: either the need to migrate arises suddenly (perhaps due to failing hardware or immediate change in business need), or more likely the process is assumed to be included as part of the service provider offering.
Whatever the cause, it’s a mistake to regard the migration process as an inconvenience. Doing so undermines the value of your business critical data. In countless annual IT surveys, organisational data is universally regarded as the single most important company asset. In fact, respondents to a Computer Weekly survey reported ‘Data Protection’ as their top security priority in 2013. So why does this attitude suddenly evaporate once the data is in motion?
The remedy for this is relatively simple: to build in migration as an expected part of the total cost of ownership.
This doesn’t mean simply allocating more budget to service providers though: for the majority of them, this is no longer a core competence.
Ten years ago budget hosting companies might have been able to move a simple website onto their servers with relative ease, but IT is too complex now – there are too many concurrent services and interdependent systems. Service providers are getting much savvier about this too; many have underestimated this complexity and had their fingers burnt in the past.
The same dynamic is true of internal IT teams. Organisations might be tempted to cut corners and reassign internal technical staff to oversee a migration project because, on paper, the skills look quite similar. But technical aptitude is only a single prerequisite of successful migrations – it’s not simply a case of following a set of instructions and hitting the ‘go live’ button at the end. It’s a more nuanced business process that demands a suite of other skills to get right first time.
This is really the key: migrations are highly intensive events with no real margin for error, and skimping on cost up-front is very short-sighted given the significant costs incurred by rectifying a botched project.
Of course, underpinning all of this is the fact that there is no inherent risk in data migration, so long as the planning, testing and allocation of resources are sufficient. This might sound simple enough, but the reality is often quite different.
The skill gap
Another side-effect of the recent uptake of cloud services has been a dramatic loss of internal technical skill. As organisations outsource more of their IT functions, it’s often assumed there’s a corresponding drop in the need for technical staff. In some cases, this only becomes a problem in times of disruption – when systems fail client-side and there’s no one around to resolve the issue.
However, understaffed IT departments can have invisible but serious consequences in the long term. In short, outsourcing the systems does not mean outsourcing the knowledge, and companies that cut back internal capability too far necessarily distance themselves from their IT, and put their data at unnecessary risk.
One of the supposed pillars of cloud computing is that IT becomes a disposable utility that does not need to be maintained internally. In specific cases, such as individual services from providers with very high SLAs, this might be true. But a central part of migration is having an accurate image of the entire IT estate for comparison at either end.
This is a basic requirement without which the success of a migration is impossible to determine, and yet increasing numbers of companies have a very limited picture of the systems they possess – a consequence of overzealous outsourcing.
This emerging skill gap is proving to be particularly painful in conjunction with a recent trend anecdotally reported by digital agencies.
As big brands are realising the importance of continuous digital engagement with their customers, many are building out significant internal creative and development functions to test campaigns and reduce their time to market.
Whilst this ability is hugely beneficial for creative teams, there’s a danger that as individual development clouds become easier to spin up (most today can be set up with a few mouse clicks and a credit card) organisations are unwittingly creating masses of data in separate, temporary instances without maintaining them or closing them down afterwards.
Where historically these would have been maintained and/or consolidated by on-site technical and system administration staff, there is now a risk they’ll simply remain, unused. This leads to ‘cloud sprawl’ – an inefficient cloud environment, often with the same levels of unused capacity seen in traditional dedicated environments that will inevitably require a migration to rectify down the line.
This is the other side of building migration into the total cost of ownership – undergoing regular maintenance as a business-as-usual activity to prolong the longevity of existing systems and reduce the amount of extraneous work required during actual migrations.
Next time we’ll break down the six easy steps of the migration process… You can download the full whitepaper here.