A 4-Step Guide to Defining Your Cloud Needs

Editor’s note: This is part two in a two-part series. In part one, ServerCentral Turing Group introduced how to execute a cloud migration with reduced risk, on time and on budget.

Start your cloud migration by figuring out the basics. What, exactly, are you moving to the cloud? It seems dead simple, but it’s amazing how often we see credit unions skip this step, then find the project ballooning as they discover more and more applications that need to move or can’t move and now pose a different challenge for the credit union. An infrastructure assessment will tell you what needs to go where. It will provide you with a solid start and a sense of what your cloud should look like.

A good assessment will answer the following questions:

• What applications and data are you moving?
• How long can each application or database be offline in support of the migration?
• What are the compliance and security requirements of each application?
• Who are the owners of each application and infrastructure component?
• Where do all your applications and data live today, and how much capacity are they utilizing?
• How does everything connect to your network? Where are the dependencies and relationships – technically and operationally – between each application and infrastructure component?

I know what you’re thinking. “Aren’t there tools that do this for us?” Yes. There are absolutely automated tools you can use to achieve these outcomes. However, we find it best to have everyone thinking about these issues in advance of any automation deployment. The level setting these simple exercises provide is invaluable in successful migrations.

What Data and Applications Are You Migrating?

It all starts with identification – simply understanding exactly what applications you have within your organization and which applications should move to the cloud. This step is often where we’ll find applications that are already in the cloud, completely unbeknownst to our clients.

Once you know what you have, prioritize your list of applications by how critical each is to your business. A straightforward approach is to assign each application a tier based upon its acceptable Recovery Time Objective or Recovery Point Objective (RTO/RPO). For instance, tier 1 could be for applications that can’t be down for more than 10 minutes without significant impact on the business, while tier 5 could be for applications that can be down for more than 24 hours without having a substantial effect on the bottom line. These RTO/RPO windows will vary based on your business, but the point remains – know, in advance, exactly what is at stake.

This is also a good time to also consider what regulatory restrictions your applications and data have today and how you anticipate them changing in the future. There is nothing worse than completing a migration plan only to have the brakes slammed at the last minute because no one bothered to understand the regulatory, compliance and security needs before moving the application or data.

Who Should Be Consulting on Your Cloud Migration?

Once you know what you have, the next step is identifying who manages each application that’s slated to move to the cloud. As you do this, it’s wise to also determine who needs access to these applications. These particular steps are often overlooked simply because it takes time to figure out who really owns each application and which groups are using them. It’s crucial to the success of your migration, however, to meet with the people who have their finger on the pulse of these applications. There’s nothing like watching an application go offline for an hour when it’s moved to the cloud, only to have an irate manager say, “Why didn’t you tell me this? My team can’t work.” Start consulting with these people early, so you can score their information, get their sign-off and keep them informed throughout the process.

Where Are Your Applications Running and What Capacity Are They Utilizing?

Now that you know the what and the who, it’s time to find the where. Which servers, hypervisors, etc. are these applications and their associated data running on? Where are they physically located and what shape are they in? A cloud migration is a great time to jettison old infrastructure, and you might consider prioritizing applications that are running on hardware that’s close to the end of its useful life.

Finding the applications is the easy part. You then have to figure out how much capacity they’re really utilizing. All too often we see clients with 40-60% overhead for each application, just sitting there as unused capacity. It’s bad for business when it’s physical infrastructure, but when that kind of waste gets replicated in your cloud, it can be disastrous. The transfer of this excess capacity eliminates any efficiencies the cloud can deliver, all while driving up costs. We have people come to us every day complaining that they’re spending 10 times what they planned on their public cloud. This is all because they began by replicating their physical infrastructure into the cloud instead of assessing what they needed and establishing a migration plan with clear, measurable objectives.

We recommend beginning by identifying exactly how much CPU, memory, storage and bandwidth you’re actually using for each application. Again, we keep it simple. This is extremely logical, very easy to execute and always – ALWAYS – missed. We then translate these requirements into a right-sized cloud.

You can worry about refactoring applications or developing new, cloud-native applications once you know what you have in place today!

How Should Your Cloud Infrastructure Architecture Work?

The last step is looking at the how of your applications. Before you start moving them, you need to know how they’re architected and connected. Identify which applications have an architecture for high availability and/or redundancy so you know what can be migrated with minimal to no downtime. The flip side of this process is equally important – knowing which applications can’t be migrated without operational impact. Too many credit unions have no idea what happens when a maintenance window is declared on an individual application. This step reduces your risk of unhappy members.

Take the time to understand the relationships – both the technical and operational dependencies between each application and infrastructure component. If you move an app or shut down a server, what are the ramifications? Trace the potential consequences of your actions before you start migrating. Doing this will save you hours, and tens of thousands of dollars.

How to Test Your Cloud Migration Plan

We know how crucial insulating the business from risk is for all IT organizations. To realize cloud benefits, after all, you have to make sure you’re not introducing any new vulnerabilities. That’s why we recommend our clients execute test migrations before kicking off a full-scale cloud project. This will help you understand the actual time involved – as well as identify potential connectivity issues that were previously unknown.

For example, attempting an equipment cool down may sound silly, but it is really important. Each and every customer we migrate has an issue with at least one critical hardware component not coming back from a cool down, or not operating properly after a cool down. It’s much easier to find a solution if you know which devices won’t recover from the power down before you begin moving to the cloud. One customer we migrated found issues with a router’s firmware that would have never come to light without this test. We were able to bring in a new router and address the issue quickly before we migrated. This brief test will save hours of time, thousands of dollars and countless headaches.

Declaring a maintenance window and powering down all of the applications and their associated infrastructure gives your company an opportunity to see just how quickly applications can be brought back online post migration. With real data to work with, you can minimize the unexpected and incorporate the actual times into your cloud migration plan.

When we have the opportunity, the best way to run a test migration is to move a company’s disaster recovery environment to the cloud. This gives everyone a much more accurate sense of how thorough the plan is and where we may run into pitfalls. Any bugs that we find can be worked out here and added to the cloud migration plan, further reducing the risk. It also gives us an opportunity to virtualize the backup environment, so it will match the migrated production environment.

Find a Trusted Advisor That Can Turn Your Cloud Migration Plan Into a Reality

The best way to control the risk of a cloud migration is to find a partner – a true trusted advisor who has been through the process many times before. This knowledge and experience will be invaluable in helping you realize a successful cloud migration for the first time.

Chris Rechtsteiner is a Vice President at ServerCentral Turing Group, a provider of cloud-native software development, AWS consulting, cloud infrastructure and global data center services.