At ServerCentral, we offer counterintuitive advice at the start of all cloud discussions: forget about the technology.
The truth is that the key to a cloud project’s success is knowing what you want to get out of the cloud. Technological solutions are abundant, but the most complex and important step is understanding what you’re trying to achieve.
How to build a cloud migration plan everyone can follow
A good cloud migration plan is simple. Keep it that way. To make sure things keep moving according to the agreed-upon plan, follow these steps:
Establish a clear leader.
Assign a project owner, ideally an impartial party who has the authority to demand execution and who can keep everyone informed.
Build a runbook.
Outline the process and get a copy into the hands of everyone involved in the migration, so they’re all working from the same page.
Whether they take the form of meetings, calls or emails, set up a systematic way to keep everyone informed and a space for people to voice potential problems as they arise.
Why it’s important to include every department in your cloud plans
You’d be surprised how often this happens:
- A company wants to move its email to the cloud (Gmail, Office365).
- The company’s IT team is proactive and makes the switch. Email is in the cloud.
- The compliance team realizes that sensitive information is regularly exchanged over email, which is now in the cloud. The company is violating a specific compliance requirement and must rush to switch over to a private cloud, where it will have total control over the security environment.
Looping in the right business units early in the process would have avoided this scenario entirely.
According to research from Gartner, Forrester, IDC, and 451 Research, more than 50% of cloud migrations exceed budget, exceed migration windows, and/or cause unexpected business disruptions.
In our view, this is unacceptable. With the right plan, nothing is unforeseen. It’s realistic to execute a cloud migration within the schedule and budget allotted, with minimal risk to the company.
How to identify your cloud migration plan needs: What, Who, Where, How
Start by figuring out what, exactly, you are moving to the cloud. It seems dead simple, but it’s amazing how many companies skip this step, then find the project ballooning as they discover more and more applications that need to move. It’s by far the most common mistake we see at this stage of a cloud migration.
“You start with the least complex application to learn how to migrate while learning more about the target platform, and then build toward the more complex applications.” -Stephen Orban
An infrastructure assessment will tell you what needs to go where, so you can start getting a sense of what your cloud should look like.
A good assessment will answer the following questions:
- What are you moving?
- What are the RPO/RTOs of each application?
- 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 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?
We even have a handy infrastructure assessment worksheet (.xlsx) for you to follow.
You need to identify what’s out there and how much capacity it requires, sure. But you also need to know if you shut down a collaboration server, will your email still work? What about your CRM application while your SAN is being migrated?
Consider assigning a dollar value to the impact of downtime for each application. That way you’ll be able to quickly assess whether or not the risk of an application’s migration is worth the cost — as well as what type of cloud, public or private, may best match your requirements.
It all starts with identification — simply understanding exactly what applications you have within your organization and whether or not they are in play for a move to the cloud. This 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.
Here’s an application prioritization worksheet (.xlsx) to help you.
This is also a good time to also consider what regulatory restrictions your applications and data might have.
There is absolutely 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.
Find out if anything is subject to HIPAA, PII, and PCI compliance, or internal regulations.
Think back to our example above, where an email application was humming along on the cloud before anyone realized it was transmitting confidential information across a public cloud. This happens all the time. Make sure you’re looping in every stakeholder, including the compliance team.
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 break when it’s moved to the cloud, only to have an irate manager say “I could have told you that.”
Loop these people in early, so you can score their information, get their sign-off, and keep them informed throughout the process.
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.
Which servers, hypervisors, etc. are these applications and associated data running on? Where are they physically located, and what shape are they in?
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 to 60 percent 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 10x 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.
The last step is looking at how your applications are connected before you start moving them. Identify which applications are architected 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.
It is amazing how often no one knows what happens when a maintenance window is declared on each application.
Take the time to understand the relationships — the technical and operational interdependencies between each application and infrastructure component. If you move an app or shutdown 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.
Validating your cloud migration plan
We know how crucial insulating the business from risk is to our clients. To realize cloud benefits, after all, you have to make sure you’re not introducing any 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.
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 everything 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 also 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 backup environment to the cloud. We’ll even mix and match test migration applications based on the risk, running on backup infrastructure where possible when a production application’s risk to the business is low.
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.
How to find a partner that can turn your cloud migration plan into a reality
Of course the best way to control the risk of a cloud migration is to find a partner who has been through the process many times before. At ServerCentral, we’ve spent the past 18 years managing cloud migrations day in and day out. That experience allows us to not just reduce your risk, but also help you capitalize on opportunities that are unique to your business.
According to research from Gartner, IDC and 451 Research, more than 60 percent of companies have delayed a data center migration after completing the planning stage. Of that 60 percent, 40 percent said it was a lack of resources holding them back, while 20 percent pointed to their lack of migration experience.
No company should expect to have the resources or the expertise to manage a large-scale cloud migration in-house. This is a major shift for any business, and not one the average IT team has the capacity to manage. It’s also a one-time affair, meaning your in-house talent is unlikely to have been through it before even once.
ServerCentral has completed hundreds of migrations. We learn something new from each one. If you want our help with your migration to the cloud, just let us know. We’ve seen the traps time and time again, and we know how to avoid them.