Cloud computing is perhaps not as headline-grabby as blockchain or machine learning, but it's just as revolutionary. Plus, it's getting better all the time, advancing in speed and agility across the IT services supply chain. As a result, more and more organisations have undertaken the process of migrating from IT infrastructure that uses on-site storage and in-house software to cloud systems. This is generally recommendable, and spells certain advantages like having a faster, safer, and more scalable IT system for the company's employees—however, the process of implementing such a system also brings challenges, some less obvious than others. In this article I've endeavoured to catalogue the most common errors that companies make in their cloud migrations.

1. Teaching a new dog old tricks

There is a tendency for companies to design their future cloud environment based on their current infrastructure footprint. But this one-to-one mapping of on-premise infrastructure to a cloud system can lead to an unrealistic (and less effective) cloud design, mostly because the old system was often intentionally built to be too big—since enlarging it takes great time and effort. However, the resulting inefficiency does not need to be reflected in a cloud system, because cloud systems are far more scalable by design.

Similarly, on-premise systems often had a safety buffer in place to handle data overflow, again since the capacity couldn't be changed quickly. For the same reason, their design also frequently overlooked features relevant to downsizing. With the cloud, the opportunity for an updated design taking these factors into account should be taken.

2. Neglecting the little things

Many questions surround the process of moving all the programmes and apps that the old system accommodates. Should all these programmes be moved onto the cloud, or is there an opportunity for housecleaning? Which should be moved first, and which last? Should some of them be moved in clusters?

The cloud architect must have an overview of all the programmes and apps—and sometimes there are hundreds—to find the optimal design. Gathering information on them can also pose challenges, especially if programme owners have left the company, or explanatory documentation is lacking. The information about each programme or app should, roughly, include:

  • type of application
  • business continuity requirements
  • data dependencies
  • sensitivity to latency
  • compliancy and regulatory requirements
  • application eco-system and coupling

Gaps in the above could muddy the migration but could also jeopardise the expected performance of IT services once the migration is complete. According to an IDG survey (2016), nearly 40% of organisations with public cloud experience reported moving workloads back to on-premise platforms in the months following an initial cloud migration.

3. Leaving your head in the clouds

Cloud migrations can last up to two years, so it's imperative that the lights of the current system are kept on! We have observed even mature organisations underestimating how energy-sucking the migration can be, and the losers end up being the employees who are working overtime to run the legacy system while focusing on the new one too. It's even worse for them if processes and policies are poorly documented, meaning that their colleagues need extra help from them.

To prevent such issues, the leadership team must be invested in the planning phase and aware of employees' day-to-day issues. Generally speaking, a 60/40 split is pretty good territory for personnel: having 60% of staff (or staff time) implement the cloud, and 40% run the business.

4. Waiting before communicating

Cloud migrations are often pigeonholed as technical projects, given to architects who lock themselves away to plan and test. They build a small proof of concept into a large and invasive project, but when they are ready to move into high gear the IT department is unprepared—due to a lack of change management. IT managers must not be overlooked in the early migration stages, as the skills necessary under a cloud model differ to those for on-premise systems. There will be less need for managing storage, computers, and databases, and more need for application monitoring, overseeing access controls, and security. If a change is sprung on the IT department, their initial reaction—naturally—will be to fear for their jobs. This creates, in terms of morale, problems. Far more effective is to bring them in at the ground level of the process, and ensure that they understand both the reasons for the change and that they are the best ones to carry it out. (Indeed, they are!) Offer them training and solicit feedback frequently.

(Read more about the three common pitfalls of change management in this article).

5. Missing the forest for the trees

Even if skills changes are addressed, there is sometimes a lack of higher-level strategic thinking regarding the new delivery model. The IT department, as a whole, will need to operate differently: no longer will it control the IT supply chain. IT specialists will function under a "shared responsibility model" with the cloud provider. Change management is again the answer, to make sure that these changes—which can sound scary but are ultimately changes in mentality more than in skills—are not met with outright scepticism.

Takeaway

There are of course other items to examine with cloud migration projects (notably finances, which I did not take the space to go into, here). I would leave you with the final observation that no two cloud migrations come off in quite the same way, given companies' unique set-ups, needs, and budgets. But the general recipe for success always includes the same ingredients: thorough assessment and planning; effective knowledge transfer; and communication and change management.

Please feel free to leave a comment below if I missed any challenges. For further information, don't hesitate to contact me directly.

Next up on the KPMG Blog:

The Signs That Fintech Has Reached Adulthood In 2018

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.