If the migration destination is the cloud (SharePoint Online), there are also more specific risks:
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.
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.
- 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
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 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.
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.