WHITE PAPERS. The Ultimate Guide to Cloud Migration

WHITE PAPERS The Ultimate Guide to Cloud Migration Contents Introduction 3 The grudge purchase and valuing your data 4 The skill gap 5 A to B in Six Easy Steps 6 What good looks like 11 Conclusion 12 About
of 13
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
WHITE PAPERS The Ultimate Guide to Cloud Migration Contents Introduction 3 The grudge purchase and valuing your data 4 The skill gap 5 A to B in Six Easy Steps 6 What good looks like 11 Conclusion 12 About the Author 14 2 Introduction only 16% of data migration projects were delivered successfully Bloor Research 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 computing. 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. 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 3 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 Data protection is the top security priority in 2013 Computer Weekly 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 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. 4 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. Industry Insight 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. 5 A to B in Six Easy Steps 1. Planning Planning for a migration is not significantly different than planning for any other major IT project, particularly if it s already built in to the total cost of ownership. Companies will start with an initial need and then outline a roadmap towards the solution, generally composed of: Starting conditions Desired end results Processes of change Testing (of both functionality and performance) Reporting to measure success However, given the intensive (and intrusive) nature of migrations, migration partners also require a degree of transparency and disclosure not usually needed in other projects of both the reasons for the migration and of the initial shape of the IT environment itself. For instance, certain initial conditions, such as aging pieces of infrastructure, a lack of disk space or recurring downtime must be factored in to the migration strategy. These types of issues can often be planned around, but failing to highlight them at an early stage could unexpectedly impact the image quality or the ability to complete synchronisations successfully. 2. Getting Access Actually getting access to the companies systems can be quite complicated depending on the day-to-day hygiene of the client s IT environment. It relies on strong password management policies and a solid understanding of access criteria to routers and servers. Essentially, they need a bunch of keys to hand over and they need to know what each key does. This is usually a good indicator of how well the business knows their own systems and can foreshadow potential problem areas later in the migration. Once those keys have been handed over the migration specialist will then need to perform a gap analysis to measure up how closely the customer s idea of their IT estate aligns with reality. For instance, it s fairly common for a company to employ a number of different developers over the lifetime of a single server. During that period, each of the developers could have been building scripts and uploading backups independently of one another, without ever informing the wider business. So, out of a hypothetical terabyte of storage, ¾ of it could be taken up with archived zip files simply because there was nowhere better to back up that data at the time. This is a fairly common situation, and it s not at all unusual for companies to have a very poor understanding of their own environment particularly given the shrinking numbers of technical and system administration jobs in modern IT departments. 6 3. Proof of Concept Essentially, the proof of concept stage is a dry run of the migration model itself, executed on a sample set of data, without hitting the Go Live button at the end. This can be configured around a single transaction or event just to demonstrate the functionality of the migration path, or be more complex depending on the number and variety of systems being moved. If the move isn t complicated, this can be a very fast piece of due diligence. Alternatively, the proof of concept stage can be a good point at which to align expectations with what is possible given the timeframe, budget and resources allowed. It can become a stage at which the migration partner says We re not going to commit to complete this what we re committing to is establishing whether or not this is possible. 4. Carrying out the migration Imaging or Domain-by-Domain? Historically, migrating a large amount of data was a case of putting a disk drive in a jiffy bag and calling the courier. Obviously, the kind of downtime this creates isn t compatible with the high-availability culture of today s business environment. Consequently, there are two fundamental ways to migrate non-disruptively, which can be loosely summarised as either moving all the data at once in as short a time as possible, or moving discrete elements of the environment in the background. Imaging On the surface, the first method sounds like the obvious choice; a simple copy and paste process completed outside of business hours. Uninformed companies tend to presume they can shut their systems down in the legacy environment on a Friday, copy a clone image to the new environment over the weekend and press Go at 6am on Monday so everyone can pick up their s. In reality, there are many factors that could affect the quality of the transfer, the consequences of which might not emerge until the destination. This is also the only method with scheduled downtime outside of the Go Live phase you can t take an image of a live environment, and the prospect of shutting everything down can be alarming. For many organisations, hitting the off switch isn t something they ve done before. Domain Domain migrations are more reliable than imaging, but they take significantly longer. By moving across one system component at a time such as an exchange server the chances of service outage are significantly reduced. However this also means the customer has to maintain two environments simultaneously, which can be costly, particularly if the domain is part of a large infrastructure. 7 The transfer rate is also slower as the data transfer tends to happen over the internet, with most migration providers allowing around 1 Gb/hour. This is a skill in itself, because if the migration can be completed with no impact to existing services, it can be carried out at any time in the background without disrupting the IT environment. A good analogy is to think of your IT environment as a house. Migrating data using imaging is the equivalent of picking up the house and moving it to a new location in its entirety. The likelihood of that house reaching its new destination without having a single brick loose or piece of furniture out of place is highly unlikely. The house is probably going to need to tweaking and spring cleaning once it arrives. Similarly, it s certainly quicker, but during the process you don t have anywhere to live. Domain migration is the equivalent of moving the house room-by-room; much slower, but necessarily more attentive to the respective parts. It s very easy when doing a migration to trip up along the way to do things and not consider the unintended consequences of a particular action. This is resolved by marrying up suitable IT skills with a more business-focused outlook understanding the business impact of the technical decisions being made. A migration is a very specific, contained process, with long term implications. Having someone with a foot in either camp (business and technical) is preferential. 5. Testing It s surprising how frequently companies don t anticipate the possibility that the migration might not have worked perfectly first time round. For many the testing phase is regarded as just a formality similar to a car mechanic driving around the block to demonstrate that everything works perfectly. It s not rigorous enough. Testing should be a point at which the migration is given a chance to fail; better in the testing phase than weeks after completion, when the migration specialist will need to be called back in, usually at a cost to the business. In fact, testing can be significantly more work than the actual move itself, particularly if you re migrating complex websites with many points of entry, types of interaction and different user groups those interdependent processes all need to be tested thoroughly. Ideally, organisations will have a shopping list of required tests to carry out at the other end, though again, the loss of internal IT skills can make this unlikely. Ultimately, it entirely depends on size, preparedness and complexity. Testing could only require up to half a day, or at the other end of the scale, up to 3 months for an organisation with thousands of clients who can t risk downtime. This is also perhaps the only stage at which there s a risk of the customer being too cautious, so it s important to make the clear distinction between testing and staging in more traditional projects. Testing in a safe, staged development or test environment is an integral part to most 8 IT projects, and so companies are often surprised to find out this is not the case with migrations. The testing phase, though not taking place in a discrete environment, fulfils this need completely so long as adequate resources are devoted to it. Carrying out additional staging as a precautionary measure is a duplication of effort. 6. Go Live The go live phase is a very important part of the process and the only time (except for imaging) where scheduled downtime occurs. It s at this point all the file structures and databases are verified and checked for changes. Many organisations are tempted to go live very late at night on a weekend because of a presumed sense of security if something goes wrong, there s plenty of time to fix it before work starts again on Monday. In reality though, this is often a mistake, for two reasons. Firstly, if the stages prior to the go live point have been completed exhaustively, no more errors should occur. Secondly, in the unlikely event something does go wrong, it s incredibly difficult to get in contact with the relevant web developers and engineers in the middle of the night at the weekend. General best practice dictates that the optimum time is around 7am on a Monday morning, leaving a good amount of time to rectify any issues without causing much disruption. 9 What good looks like it s not unheard of for companies to spend upwards of 200 man days on the data gathering alone process Migration is a complicated process, but it s no dark art, and overcoming some of the most common (and most severe) pain points is often just a case of having prepared sufficiently. And yet there s often a reticence in the mid-market to regard migration as the critical process it is, and therefore little to no concept of best practice. This reticence is not present at the very top end of the market. The regional nuances and idiosyncrasies (from both a technical and process standpoint) make migration a dizzyingly complex exercise for global companies with disparate workforces and IT environments. Consequently, larger organisations or heavily regulated industries often have very fixed ideas about how migrations should be conducted, and plan for them accordingly. Processes must be bulletproof, with clear, accountable owners assigned to every aspect. Migration at this level is necessarily laborious, and the organisations carrying them out simply can t afford the catastrophic disruption that failure would cause. This diligence is a matter of necessity, and is also reflected in the accompanying documentation. One of the main migration guides used by large organisations is nearly 600 pages long and distils hugely complex moves, such as consolidating servers from multiple geographical data centres, into standardised processes. These rigors permeate the entire migration strategy it s not unheard of for companies to spend upwards of 200 man days on the data gathering process alone, and this kind of attention to detail is reflective of what is needed at the lower end of the market, although at the moment it s completely absent. It s rare for smaller companies to even anticipate migration projects, let alone have a firm grasp of best practice. Obviously smaller companies don t merit hundreds of man hours of planning but efforts must be scaled down in a relative fashion rather than s
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks