1-888-317-7920 info@2ndwatch.com

Five Pitfalls to Avoid When Migrating to the Cloud

Tech leaders are increasingly turning to the cloud for cost savings and convenience, but getting to the cloud is not so easy. Here are the top 5 pitfalls to avoid when migrating to the cloud.

1. Choosing the wrong migration approach

There are 6 migration strategies, and getting to these 6 takes a considerable amount of work. Jumping into a cloud migration without the due diligence, analysis, grouping and risk ranking is ill-advised. Organizations need to conduct in depth application analyses to determine the correct migration approach. Not all applications are cloud ready and those that are may take some toying with when there. Take the time to really understand HOW your application works, how it will work in the cloud and what needs to be done to migrate it there successfully. 2nd Watch approaches all cloud migrations using our Cloud Factory Model, which includes the following phases – discovery, design and requirement gathering, application analysis, migration design, migration planning and migration(s).

These 6 migration strategies include:

  • Retain – Leaving it as is. It could be a mistake to move the application to the cloud.
  • Rehost “aka” Lift and Shift – Migrating the application as-is into the cloud.
  • Replatform – Characterized as re-imagining how the application is architected and developed, typically using cloud-native features. Basically, you’re throwing away and designing something new or maybe switching over to a SaaS tool altogether.
  • Retire – No migration target and/or application host decommission on source.
  • Re-architect/Refactor – Migration of the current application to use the cloud in the most efficient, thorough way possible, incorporating the best features to modernize the application. This is the most complex migration method as it often involves re-writing of code to decouple the application to fully support all the major benefits the cloud provides. The redesign and re-engineering of the application and infrastructure architecture are also key in this type of migration.

From a complexity standpoint, replatform and rearchitect/refactor are the most complicated migration approaches. However, it depends on the application and how you are replatforming (for example, if you’re going to SaaS, it may be a very simple transition.  If you’re rebuilding your application on Lambda and DynamoDB, not so much).

2. Big Bang Migration

Some organizations are under the impression that they must move everything at once. This is the furthest from the truth. The reality is that organizations are in hybrid models (On-Prem and Cloud) for a long time because it’s very hard to move some workloads.

It is key to come up with a migration design and plan which includes a strategic portfolio analysis or Cloud Readiness Assessment that assesses each application’s cloud readiness, identifies dependencies between applications, ranks applications by complexity and importance, and identifies the ideal migration path.

3. Underestimating Work Involved and Integration

Migrating to the cloud is not a walk in the park. You must have the knowledge, skill and solid migration design to successfully migrate workloads to the cloud. When businesses hear the words “lift and shift” they are mistakenly under the impression that all one has to do is press a button (migrate) and then it’s “in the cloud.” This is a misnomer that needs to be explained. Underestimating integration is one of the largest factors of failure.

With all of the cheerleading about of the benefits of moving to the cloud, deploying to the cloud adds a layer of complexity, especially when organizations are layering cloud solutions on top of legacy systems and software. It is key to ensure that the migration solution chosen is able to be integrated with your existing systems. Moving workloads to the cloud requires integration and an investment in it as well. Organizations need to have a solid overall architectural design and determine what’s owned, what’s being accessed and ultimately what’s being leveraged.

Lastly, code changes that are required to make move are also often underestimated. Organizations need to remember it is not just about moving virtual machines. The code may not work the same way running in the cloud, which means the subsequent changes required may be deep and wide.

4. Poor Business Case

Determine the value of a cloud migration before jumping into one. What does this mean? Determine what your company expects to gain after you migrate. Is it cost savings from exiting the data center? Will this create new business opportunities? Faster time to market? Organizations need to quantify the benefits before you move.

I have seen some companies experience buyer’s remorse due to the fact that their business case was not multifaceted. It was myopic – exiting the datacenter. Put more focus on the benefits your organization will receive from the agility and ability to enter new markets faster using cloud technologies. Yes, the CapEx savings are great, but the long-lasting business impacts carry a lot of weight as well because you might find that, once you get to the cloud, you don’t save much on infrastructure costs.

5. Not trusting Project Management

An experienced, well versed and savvy project manager needs to lead the cloud migration in concert with the CIO. While the project manager oversees and implements the migration plan and leads the migration process and technical teams, the CIO is educating the business decision makers at the same time. This “team” approach does a number of things. First, it allows the CIO to act as the advisor and consultant to the business – helping them select the right kind of services to meet their needs. Second, it leaves project management to a professional. And lastly, by allowing the project manager to manage, the CIO can evaluate and monitor how the business uses the service to make sure it’s providing the best return on investment.

-Yvette Schmitter, Sr Manager, Project Portfolio Management

Facebooktwittergoogle_pluslinkedinmailrss