Common Cloud Migration Pitfalls
Joby Jennings

‍

Migrating to the cloud can be an exciting experience, but far too often, the process turns into a dreaded exercise. Whether the process takes far longer than expected or ends up costing much more than anticipated, the migration can leave people believing they have made the wrong decision. Although moving to the cloud is not for everyone, there are certain things to avoid to ensure you aren’t stuck with buyer’s remorse once complete. This article will be the first in a series covering some common pitfalls that I have experienced in migrating customers to the cloud.

Getting in Your Own Way

One of the most common (and definitely most frustrating) issues I have encountered in migrating organizations and applications to the cloud is customers constantly getting in their own way. This can show up in many different forms, all of which can be prevented or altered to ease the pain of the migration.

Total Buy-in: Usually, when an organization decides to embark on a cloud migration, someone like the CTO or someone in a leadership position decides it is time to make the move. As with all things, though, people hate change. If you do not get buy-in from the application-level owners/developers, the whole process will feel like walking uphill in the snow. Before the process truly begins, everyone involved needs to understand why and how the migration will benefit them and their role in the migration. Having an estimated timeline of when the work on their app will begin can also be very beneficial, as it gives the application developers time to finish up existing work and prepare for the migration.

Over-Complicated Design/Review Processes: Having approval gates and review boards is a critical part of ensuring the infrastructure that you are migrating your app to will be sufficient. However, far too often, I have seen this become a major cause of slowdowns because the processes can take too long. Establishing proper review gates and boards should be an iterative process. The review board/gate process is meant to ensure you are following company procedures, not slow the migration down to a halt. Here are some things that can be done to avoid the latter:

• Have a flexible schedule for these meetings: I have seen some companies only hold these meetings once or twice a month with no wiggle room. This leads to a lot of downtime.
• Those presenting the design: Send out your deck or presentation well in advance. Welcome questions and feedback well before the meeting.
• Reviewers: If material is sent out in advance, review it in depth before the meeting. Follow up with questions you might have ahead of time.
• Schedule follow-up meetings on the spot: I have seen too many times where a design is discussed, and a small portion does not meet the required guidelines. If this is the case, discuss how long it will take to update the design and schedule a follow-up review. This will help avoid downtime, especially if the meetings aren’t frequent.
• Iterate, iterate, iterate: Review and update this process every few months to ensure it is working best for you.

Centralize All Relevant Information: This is much easier said than done but is a vital step that needs to be done early. I was once a part of a client engagement for moving all their APIs to the cloud. The first thing I asked for was a list of all the APIs, to which I was met with a deer-in-headlights look. I then spent the next few weeks meeting with different departments and teams to create this list, setting us back from the start. This step should ideally be done before any type of implementation can start.

Don’t Over-Engineer Your Security Policies: One major benefit of moving to the cloud is an increase in security. RBAC permissions allow for very fine-grained control over who can access what. However, when designing your RBAC controls, it is vital not to implement practices that are going to slow down the development process. I have seen companies require approval for access as low as Reader; having to request access to resources you work with on a daily basis and having that access expire leads to daily slowdowns that add up in the long run. With data being classified differently by different companies, there really isn’t a one-size-fits-all solution for how to handle this. Work with the developers who will be doing the work, understand the access they need, and ensure they have it in their development environments. Enforce stricter policies in environments that aren’t used as the developers' test beds.

The few things mentioned above can help ease the migration process and keep things moving along. If there is one thing I feel all of these tips help with, it is enabling the developers to do their jobs. If the developers are stuck waiting for things to get done, the whole migration will be at a halt.

‍