The journey of migrating applications to the cloud is sometimes as valuable as the destination — it's often through trials and tribulations that best practices are created.

Having traveled this journey with several different companies, here are some common and not-so-common pitfalls organizations face, advice about how to deal with these challenges when they arise, and lessons learned.

Cloud migration pitfalls

Pitfall #1 — Celebrating Too Early

While celebrating victories as you continue on your cloud journey is important, it’s equally critical to focus on the bigger picture. The pitfall occurs when the team builds one new project successfully on the cloud and the company claims victory without understanding or realizing that 95% of what runs the business day to day is not actually in the cloud. The early celebrated projects are usually not mission critical, so the cloud team can act independently without integrating with current systems. In these cases, the majority of employees have no idea what benefit the new ecosystem brings, so there’s no alignment to the cloud outcome. In fact, most cloud efforts fail because the first cloud “success” alienates a large percentage of the company’s technology organization instead of becoming a change agent for the company. This is especially true in larger, Fortune 500 companies that have had people and processes in place for many years.

Solution — Focus on getting your organization ready for the cloud transformation journey before it begins. You need your organization to be on board, ready, and willing. That takes time. Hold managers accountable for providing training and certifications. Often, when it comes to technology, it’s not that people are unwilling to change, it’s just that they don’t know how. Educate them, let them know that the modernization isn’t going to take their jobs away, make them feel like they’re a part of the long-term program, and give them the tools they need to adapt. You may consider leveraging early adopters on your legacy team to do the cloud modernization work instead of solely relying on a separate cloud or digital team.

Pitfall #2 – Moving from a single-cloud environment to a multi-cloud one

A lot of SaaS and PaaS vendors say they are multi-cloud enabled, so if you commit to a multi-cloud strategy, you are more likely choosing those vendors so that you can potentially leverage their ecosystems to handle data synchronization and failover. But, if you commit to a single cloud, your software vendor strategy may be different. Many technology professionals don't realize that the moment they outline costs for a single solution, there's a bunch of subsequent decisions that will be impacted. For example, optimizing cloud usage and downstream vendor selection on products that will be hosted on the cloud. This scenario then brings up questions, such as "Do you choose a database platform that can be leveraged across multi-cloud to build your applications, or should you use a similar solution that is offered natively by the cloud vendor? The pitfall occurs when a team commits to a single cloud early and later moves to multi-cloud, because moving data between clouds, especially through custom integration, is complex and expensive.

Solution —Take your time and do your research. The needs of your organization will determine whether you should choose a multi-cloud strategy or commit to a single cloud. Your business processes will also influence your decision to go with a specific vendor or select vendor-neutral cloud offerings.

Pitfall #3 – Not expecting the unexpected

A very common pitfall is when organizations try to leverage the cloud, but they use the same code and development paradigm and expect it to work seamlessly. However, moving to the cloud often triggers subsequent things that you did not expect. For example, during one migration, my team needed to upgrade runtimes because the on-premises version wasn’t compatible with the cloud. But, then we had to also update the code to be compatible with the new version of the runtime. In another situation, we tried to migrate old web applications to the cloud, which required us to rewrite a lot of code to make it “container friendly.” A lot of things you think are trivial are not, especially when your software and applications may very well be either outdated, incompatible, or not supported by the cloud.

Solution — Sometimes it’s less expensive to rewrite and reengineer older applications before leveraging and migrating them to the cloud. However, some software just isn’t suitable for the cloud and should be left on-prem. I believe that hybrid cloud is sometimes inevitable for large organizations that think they want to move everything to the cloud. A lot of companies just take one approach, but that won’t allow you to experience the full benefits of the cloud. It’s better to take a multi-prong approach that combines rewriting, revising, lifting and shifting, and moving. For example:

• My team rewrote and consolidated a bunch of our capabilities into a common microservice and deployed it to the cloud.
• We lifted and shifted an application, going directly into the cloud with a hosting service.
• We also moved that application by leveraging a cloud managed service.

Ultimately, the long-term goal is to leverage the cloud properly, not just treating it like a new data center.

Pitfall #4 – Having tunnel vision

Some organizations build new things on the cloud without first looking at how to make the rest of their existing systems work. They get cloud tunnel vison instead of examining the whole environment and taking all aspects into account. For a lot of older applications, cloud modernization is basically a rewrite, as the software architecture, programming language, and tools are not compatible to the cloud environment. The pitfall is that they never get the speed and agility they’re seeking, because they’re to bogged down trying to “move” everything without considering alternatives. It’s incredibly difficult to achieve the benefits of migrating to the cloud if your focus remains just on the tip of the iceberg.

Solution — Take a holistic look at the entire environment and architecture. A lot of the decisions you make should be based on the research conducted before any migration occurs. This will save you from hours, days, and possibly even weeks of headaches and frustration. Sometimes rebuilding or even sunsetting the application is a better option than a cloud migration.

Pitfall #5 – The old system lives on

Things need a certain critical mass to be useful and successful. That is especially important when you're transforming applications that already exist, not just building new stuff. For example, if I'm building a replacement platform for a company, it needs to have enough features for it to be adopted and useful; otherwise, users will be using two systems in parallel, slowing down adoption and hurting the credibility of the transformation. The pitfall here is that this can result in a "double-dipping” impact, both technically and financially for a long period of time, because you must maintain two systems in parallel — the one you're building and the one that's been there for a long time. This requires keeping a lot of systems in sync and connecting the two systems continuously to make it work for the company, which is complex and expensive “throw away work.” A lot of times, you have bigger, newer things on the cloud, but then you never get the chance to sunset the other systems, which has financially failed a lot of transformations because both adoption and integration are usually an afterthought. Similar to Pitfall No. 1, this is not unique to any transformation, but cloud modernization usually amplifies the impact.

Solution — Planning far enough ahead will help reduce both the complexity and the cost. Define the adoption path of the cloud-transformed systems and how you plan to incrementally sunset the old ones. Financial implications are often an afterthought, so get the finance team engaged from the very beginning to manage these expectations. It will change the complexity of your company’s financial model in terms of what things become capital expenses versus operating expenses and how you manage that mix. While financial benefit is not the primary (or only) driver of cloud modernization, you should avoid making your ecosystem more complex than it was before.

Lessons learned

I’ve gained a lot of experience as a technology leader migrating business processes, applications and systems to the cloud for multiple Fortune 500 organizations. These experiences didn’t come without pain points, especially early in my career. However, each challenge I faced was a lesson that I could refer to and avoid in the future. Here are a few of those lessons.   

• Cloud migration isn’t just transforming technology, it’s transforming the team and the company.
• Manage expectations from the very beginning. A lot of companies think they will reap benefits very quickly, but there may not be a lot of tangible benefits in the first couple years. It takes time to build, move, and show progress. When you do see benefits, be sure to show the incremental progress.
• Embrace a multi-prong approach: rewrite and consolidate, lift and shift to hosting, and leverage cloud services. This is especially important when transforming large monolithic applications where incremental progress is critical to long-term success.
• The goal of your initial efforts should be to create a repeatable playbook for the rest of the company. Measure the success for the organization not only on the execution of the outcome but also in terms of how it become a repeatable process for the rest of the company. The first team is hit with all the roadblocks and unknowns, but make it very clear in the strategy that the goal is to pave the path, to identify the checks and burns.