Cloud Migration: Risks and Ways to Manage Them

The ‘usual’ risks and the fairly familiar countermeasures apply to cloud migration just as much as they do to other projects as well. Some of these risks are quite considerable and need to be dealt with by means of conventional risk management. But there are also knock-on effects that result from inadequate planning. Most of the examples found in the latter category can be prevented by obtaining a realistic assessment of the scope and complexity of individual tasks before embarking on the project and by aligning the financial planning and scheduling of the migration project with the consequent requirements. This article will take a closer look at the potential risks and countermeasures.

Besides the general risks that largely apply to any project, there are a number of specific risks and pitfalls that are more likely to be found lurking in the background of cloud migration especially. They must therefore be given proper consideration from day one within the context of risk management.

This article deals with the special risk topics that need to be addressed for successful migration to the cloud, in addition to the more typical ones. We will start with the classic risk cases that will most probably occur. From there we will gradually expand our list of risks to include issues that apply to the circumstances of the cloud and the difficulties associated with migration.

The scope of the project is underestimated

Reasons include:

• Inadequate scaling
• A sharp rise in data volumes over the course of the project (migration projects often have a schedule lasting months or even years)
• Neglected work stages due to insufficient awareness of the original environment

In almost all cases the budget and deadline risks can be minimized through adequate preparation and forecasting. Experience is another vital key to success. You only stand a chance of reaching a realistic appraisal of the scope and progression of these projects if you are familiar with similar ones in the past.

Inadequate communication

• The substantial number of work packages that usually accumulate means that intense communication between project stakeholders and with users is important.
• Lack of positive reporting of the migration results to end users (poor acceptance)

Communication needs to be planned as a separate and independent category. Typically, project management will account for a hefty slice of the work packages. Proactive project marketing is another useful tool.

Implementation difficulties due to inadequate training of project stakeholders

• Mistakes in the operation of tools.
• Not all dependencies are taken into account in the scripts and configurations
• Inadequate compensation for lack of experience (even with seemingly simple tasks)
• Frequent changes in project members (especially when dealing with large-scale migration)

Highly qualified project members reduce the likelihood of mishaps over the course of the project.

If the migration destination is the cloud (SharePoint Online), there are also more specific risks:

Feasibility

Not every use case can simply be transferred to the cloud.

• Intensive customizing (SharePoint on-premises cannot simply be migrated 1:1 to SharePoint Online, and modifications of the layout/master pages in particular are often problematic)
• The cost of cloud-compliant implementation is exorbitant (compared to farm solutions)
• Often there is the misconception that only a complete mirroring of a current platform can be successful. But a good compromise can also be found by exercising keen judgement and using practical solutions. It also provides a perfect opportunity to eradicate outdated customs and practices.

Stakeholders

Not everyone loves the cloud.

• A decision-maker or influences in the right (or wrong) position can prevent a cloud project (‘cloud opponents’)
• The users must also be willing to work with the cloud

It is essential to realize first of all that controversial opinions do exist in order to ensure efficient risk management. It follows, therefore, that a stakeholder analysis can be inestimably valuable prior to a cloud migration project. Apart from that, positive marketing is a good way to induce a change of heart among users. Often enough, users only need to be reassured that they will not be placed at a disadvantage by switching to this (currently) unfamiliar technology.

Poor selection of tools

• The market is brimming with migration tools
• Their performance differs greatly and is not always reflected in the price
• Even ‘professional’ tools frequently reach their limits when dealing with complex methodologies (e.g. it is possible to break the ‘flow’ when dealing with differential migration)

It is indeed advisable to reach an individual decision in each project. But the price should not be the only factor. The outcome and the usability are crucial as well. Since the most recent update, the Microsoft migration tool has definitely warranted shortlisting as well. Ultimately, however, the crux of the matter is to identify what the tool needs to accomplish during the migration.

Evergreen approach

• What appears beneficial from the perspective of cloud management can be quite the opposite during migration. Changes in the target platform can mean that the final results are no longer consistent with the original planning. Indeed, the entire migration may fail at this point if individual features are withdrawn.
• Modifications to the target system necessitates continuous questioning of the methodology and scheduling.

These modifications of the cloud environment cannot be changed, so the best strategy is to cope with it and to directly implement any alterations that become necessary. But this can only work if project management is up to date with the latest changes. The Office 365 Portal lists all changes that have been carried out so far. It is therefore obvious that project managers must view the analysis of change information as one their routine tasks (unless it has been delegated to a technical team member).

Bandwidth from and to the cloud

• The effects of bandwidth on the speed of migration are very often underestimated, leading to the migration taking longer than originally anticipated.
• Another aspect that people often forget is that migration and productive operations may share the same bandwidth, which can interfere with the users if migration takes place during normal working hours.
• This variance in speed will inevitably lead to disruption in the schedule for migration of content.

Careful calculations in advance of the project can help to avoid bottlenecks further down the line. Quite apart from this, it is advisable to implement active bandwidth control to prevent these two areas from getting in each other’s way.

"Unexpected" operational requirements

• Backup and restore are often neglected in the mistaken belief that they are part of the deal with cloud services
• Exit scenario – In many cases, the opportunity to stop using the service is just as important as the migration itself. Reasons for this may include compliance requirements or conditions imposed by regulatory authorities

There’s nothing quite like experience in this case as well. While service level agreements and redundancy are the principal areas of interest for on-premises projects, it is important in the cloud to actively find suitable approaches that reflect the ‘types’ of use cases and company requirements. In many cases this will mean breaking with old habits and considering even ‘exotic’ factors to accommodate the new realities.

Legacy relics in the form of proprietary solutions and/or customizing

• RAD (Rapid Application Development) tools whose ‘products’ cannot or should not simply be switched to the cloud without further thought (example: 3rd Party Workflows) – Often the only alternatives are to build new ones or to book a corresponding service in the cloud. And while this is hardly a showstopper, it can lead to a precipitous rise in workload and costs that may even call into question whether the project itself is worthwhile
• Successful transfer of site content is often thwarted by undocumented modifications to the pages, and it is virtually inconsequential whether this is caused by changes to JavaScript or alterations of the master page definitions.

The best way to appraise legacy relics is if they are identified during stocktaking and the necessary measures are included in the project calculation. Instead of adopting an expensive solution, it is advisable to take a critical look at future demand and, when in doubt, to switch to more pared down solution scenarios. Sticking to unviable solutions will even multiply the costs in frequent cases.

Reorganizing structures

Reorganizing structures and information during migration is only a good idea at first glance. If it is attempted in practice, it is almost inevitable that people will barely be able to distinguish whether an effect is caused by migration or the (relative) transfer of data. In the worst-case scenario, complex systems and workflows especially can be put out of operation completely.

Avoidance and linearization are the only way forward, which means performing the migration first before turning to the issue of restructuring. This does not apply to processes that require an entirely new organization.

Missing licenses

People tend to forget that licensing terms need to be adapted when they start running additional or newer systems.

But prudent planning will easily prevent projects from drifting off into the fringes of legality or even beyond.

Naturally, other items can be added to this list as well. But a successful migration project to SharePoint Online is virtually guaranteed by giving sufficient consideration to the risks outlined in this article. Preparing a detailed cutover plan at an early stage of the project is a good way to ensure that steps and checks are not forgotten. This plan must also state plainly when which actions need to be performed in order to ensure successful migration, specifically in cases of productive migration.