The Cloud Migration Checklist

Organizations are rapidly adopting cloud technologies, but migration is still proving to be a challenge. What should you look out for? What applications make the most sense to migrate? How should applications get refactored to be cloud friendly? What are some lessons learned by those making the move? In this series of articles, you'll get practical advice from those who have experience helping companies successfully move to cloud environments. There is an area that deserves significant attention, and we hope that you'll participate in the conversation.

This InfoQ article is part of the series “Cloud Migration”. You can subscribe to receive notifications via RSS.

Are you in the process of moving applications to a public cloud? You’re not alone. 451 Research says that 46% of 2015 IT budgets are going towards off-premises systems, with that number expected to climb to over 50% within the next three years^[1]. Organizations still purchase cloud services in order to achieve cost savings, but increasingly identify strategic goals like “time to market”, “improved availability”, and “establishing new revenue streams” as primary adoption drivers. However, with a recent survey showing that only 27% of participants were extremely satisfied with their cloud migration experience, there’s clearly room for discussion on how to introduce cloud services into your IT portfolio and successfully transition apps and/or data to the new environment.

In this article, we’ll explore four stages in a cloud migration lifecycle. To be sure, a (cloud) migration is never truly “done.” As you constantly hire new services to solve business problems, the cycle starts all over again, potentially with different technologies and objectives. While the below checklist may help you start your journey, it’s important to personalize it to your particular situation!

Assessment

There is no “one size fits all” cloud service. Many organizations try to identify a preferred cloud environment before understanding how that cloud matches their organization’s maturity, culture, and application portfolio. What questions should you ask of yourself and the candidate providers?

• Are you the right fit for THIS cloud? There are countless providers of cloud services, and not all of them fit your specific needs. One cloud may offer thousands of virtual servers in seconds, which is wonderful if you are among the organizations that need such a capability. Another could deliver white-glove managed services that may or may not be relevant to your mode of operation. Consider what matters most to your organization, and actively try out a handful of providers that fit the bill. Don’t just blindly choose a “leader” in a particular cloud domain and accidentally choose a provider that negatively impacts your ability to deliver services successfully.
• What are your capacity demands? Based on the type of workloads you’re considering for the cloud, different providers may bubble to the top. Is your application portfolio bursting with modern, cloud-native applications that capitalize on thousands of cheap, ephemeral servers or containers? Do you need a relatively slow-growing pool of a few hundred durable compute resources? Consider your application landscape and make sure that providers can support your upper bounds of compute, storage, and network throughput.
• What are the actual costs? The “cost of cloud” is rarely the easily-calculated number you see in the price list. Make sure to model real-life scenarios and look for special charges applied based on geography, backup storage, consumed bandwidth, API calls, and more. Also, don’t forget to factor in costs around onboarding programs, support plans, and net new environments (e.g. performance testing, staging) that didn’t exist on-premises.
• Where are the “gaps” and are they still gaps after migration? It’s likely that you’ll finish your first assessment of cloud providers and have a list of perceived or actual deficiencies. It’s important to talk about those with the provider and see if (a) there are future plans to close those gaps, or (b) if there are viable workarounds to those gaps. One possible workaround is that the infrastructure or application pattern that caused the gap is refactored to fit more natively into the cloud’s defined model.
• What’s the fit for your existing tools? If you’ve been in business for more than a month, you probably have an existing set of tools (and processes) that you’ve grown accustomed to using. If you can’t easily adapt your tools to the candidate cloud environments, make sure you’re comfortable replacing the status quo with the toolset(s) supported by the cloud vendor.

Planning

Congratulations, you picked a cloud provider for a particular business domain. Now comes the hard part: planning a migration! What are the most important things to consider when plotting out the migration strategy?

• What are the candidate apps/workloads/environments? Ideally, the first applications you move to the cloud aren’t the trickiest, most business critical ones. But either way, make sure that you do a comprehensive inventory of applications and indicate those that are the best fit – strategically or tactically – for a cloud environment.
• What’s the topology of the application architecture? There’s a good chance that your application architecture will differ in the cloud. Cloud servers, data services, and networks behave differently than their on-premises counterparts, so you may need to evolve your reference architecture and deployment process in order to fit in this new world.
• What possible performance bottlenecks are being introduced? Does moving to the cloud guarantee an instant boost in application performance? Absolutely not. If you take a monolithic application and distribute its parts among cloud services, you may introduce unforeseen latency. If your applications have integration points with on-premises systems that do NOT migrate to the cloud, you may also see performance problems due to long-distance connections. Cloud servers come in all shapes and sizes, so make sure that give your applications the necessary CPU, memory, and disk horsepower to meet or exceed their historic performance levels.
• What are the hybrid integration plans? It’s unrealistic to think that you’ll move an entire application portfolio to the cloud at once, or maybe ever. Treat the cloud as a logical extension to your existing landscape and consider how you will extend your current data, network, and identity to the cloud.
• Have you identified the first adopters? A migration to the cloud can be disruptive, and it’s important to find people within the organization who are eager to help define new standards and guide the organization through this important transition.
• How will users access the environment? Your co-workers probably already have too many passwords to manage. The last thing you want to do is add an entirely new set of complex credentials necessary to access a critical set of cloud services. Look at Single Sign-On (SSO) mechanisms offered by your cloud vendors and make this an upfront aspect of any project to adopt a cloud service.
• How will you train staff? It’s important for your team to get deeply familiar with these new cloud services. Consider each audience (e.g. project managers, developers, architectures, system administrators), and tailor onboarding materials that help staff get comfortable in the cloud.
• What internal processes have to change in order to capitalize on the new service? Your documented procedures for hardware requisition, change management, testing, and deployments may not apply in the same way when using cloud services. If you attempt to overlay current processes on more agile, self-service environments, you may lose all the benefits that you were after in the first place. Do an honest assessment of the changes that need to be made.
• How will you deploy updated code, data, and configurations to the environment? Your new cloud service may work with your existing system administration tools, or it may not. If you’re using modern configuration management tools like Chef or Ansible, there may be available extensions that work seamlessly with your cloud destination. Make sure that you do a thorough simulation of the deployment and configuration process and identify any areas of improvement.
• What’s the plan for operating this service after migration? The migration is only the start of that application’s new life in the cloud. What happens when a change is needed? How do you troubleshoot a problem? What monitoring hooks will you use to measure key performance indicators? Look at the full lifecycle of a cloud workload and consider all the care-and-feeding activities.
• Do you have a strategy for cutover? If your application users can tolerate a prolonged downtime while a migration occurs, you may pursue a simple, yet disruptive cutover plan. However, if you want to minimize downtime, you will have to consider strategies where you set up the new environment and keep it in sync with the primary environment until the time comes to steer all traffic to the new instance.
• How will financial processing occur? Yes, you’ll probably have to pay for your cloud usage. How will you do that? Do you plan on charging each business unit that consumes cloud resources, or simply pay the entire bill out of a general fund? Make sure to think through the process of incurring charges, getting an invoice, and making a payment.
• Have you completed a small scale pilot that flexes all the above concerns? Above all, don’t go into a migration with only paper prototypes. Physically set up applications in the target cloud and do trial runs. Get familiar with the interface, capabilities, and constraints so that you develop hands-on expertise.

Migration

With proper upfront planning, the migration itself should be uneventful. To be sure, surprises will invariably surface when the actual migration is underway, but if you’ve answered the above questions, your team should be equipped to handle the unexpected.

• How are you distributing the apps and data to the cloud environment? There are a handful of ways to get your applications and data up to a cloud location. For moderately-sized workloads, you can often use simple copy commands and pass this data over your Internet connection. For large data sets, however, you might be incurring significant bandwidth charges from your cloud provider and long transfer times. In those cases, it’s better to either (a) compress the data and copy it to a staging location in the target cloud before transferring it to the final destination, or (b) physically ship drives to the cloud provider (if they support it).
• What security controls are in place during transit? During the migration, you may end up using staging servers or temporary object storage repositories. Make sure you’ve thought through the data and access security considerations, especially for sensitive data.
• Migrate virtual machines. Moving entire VMs is one way to migrate an application to the cloud. There can be unexpected side effects depending on how the VM was attached to the on-premises network, the domain it was part of, the types of drives used, and more. While a “lift and shift” of VMs often appears to be the easiest route to the cloud, it’s often more complex than expected. Additionally, that sort of approach doesn’t force you to reconsider your application architecture and strategic ways to refactor your application for the cloud.
• Migrate data. Your data may move to a database-as-a-service environment, or a self-managed database instance. Make sure you know which tools are provided by the vendor, and what limitations exist regarding data volume, or structure.
• Migrate applications. If your application deployment tool can natively point to cloud infrastructure, containers, or application platforms, you’re in good shape. You’re also probably in the minority! It may take some reconfiguration to get your on-premises tools to deploy code to the cloud, or you might evaluate new tools to make the process more seamless.
• Recreate metadata. Companies often say that they want “portability” in the cloud and seek to avoid “lock-in” with a particular vendor. Good luck with that. While assets like virtual machines and application code can move relatively freely between clouds, environment metadata is often very provider-specific. Account structures, users, permissions, policies, load balancers, and the like vary from cloud to cloud. Make sure you know how to set up the supporting configurations for your particular cloud destination.

Validation

Once the migration is completed, it’s critical to verify that ALL aspects of the application are performing as expected.

• Is the application reachable? A simple test, but it’s vital to check out all the various application services and make sure that users can access them, and internal components can communicate without error.
• Did all the data make its way into the environment? Through automation – or at worst, a manual spot check – verify that both transaction data and reference data successfully transferred to the cloud. If you have complex data relationships, one failed migration can cause a cascading problem.
• Can administrative tools access the cloud environment? You hopefully verified this during your planning phase, but here’s one last chance to validate that all of the management tools can “see” the cloud application and monitor it with no issue.

Summary

Every day, organizations are successfully adopting cloud services and breathing new life into their IT portfolio by migrating applications to a more agile environment. Unrealistic expectations are a leading source of migration frustration. The best way to avoid this angst is to seriously evaluate your organization’s goals and readiness, and answer practical questions about the planned migration process.

Have additional suggestions for improving your odds of success? Leave feedback in the comments below!

[1]Source: 451 Research Voice of the Enterprise, Cloud Computing, Q4 2014

About the Author

Richard Seroter the VP of Product for the CenturyLink platform, a Microsoft MVP, an instructor for developer-centric training company Pluralsight, the lead InfoQ.com editor for cloud computing, and author of multiple books on application integration strategies. Richard maintains a regularly updated blog on topics of architecture and solution design and can be found on Twitter as @rseroter.

Organizations are rapidly adopting cloud technologies, but migration is still proving to be a challenge. What should you look out for? What applications make the most sense to migrate? How should applications get refactored to be cloud friendly? What are some lessons learned by those making the move? In this series of articles, you'll get practical advice from those who have experience helping companies successfully move to cloud environments. There is an area that deserves significant attention, and we hope that you'll participate in the conversation.

This InfoQ article is part of the series “Cloud Migration”. You can subscribe to receive notifications via RSS.