The Ultimate List of Cloud Migration Do's and Don'ts

by Douglas Bernardini

Cloud Migration – Enterprises typically begin to contemplate how to migrate an application during the second phase of the “Migration Process” — Portfolio Discovery and Planning. This is when they determine what’s in their environment, what are the interdependencies, what’s going to be easy to migrate and what’s going to be hard to migrate, and how they’ll migrate each application.

Using this knowledge, organizations can outline a plan (which should be considered subject to change as they progress through their migration and learn) on how they’ll approach migrating each of the applications in their portfolio and in what order.

The complexity of migrating existing applications varies, depending on the architecture and existing licensing arrangements. If I think about the universe of applications to migrate on a spectrum of complexity, I’d put a virtualized, service-oriented architecture on the low-complexity end of the spectrum, and a monolithic mainframe at the high-complexity end of the spectrum.

I suggest starting with something on the low-complexity end of the spectrum for the obvious reason that it will be easier to complete — which will give you some immediate positive reinforcement or “quick wins” as you learn.

6 Application Migration Strategies: “The 6 R’s”

The 6 most common application migration strategies we see are:

  1. Rehosting: Otherwise known as “lift-and-shift.”: We find that many early cloud projects gravitate toward net new development using cloud-native capabilities, but in a large legacy migration scenario where the organization is looking to scale its migration quickly to meet a business case, we find that the majority of applications are rehosted. GE Oil & Gas, for instance, found that, even without implementing any cloud optimizations, it could save roughly 30 percent of its costs by rehosting. Most rehosting can be automated with tools (e.g. CloudEndure Migration, AWS VM Import/Export), although some customers prefer to do this manually as they learn how to apply their legacy systems to the new cloud platform. We’ve also found that applications are easier to optimize/re-architect once they’re already running in the cloud. Partly because your organization will have developed better skills to do so, and partly because the hard part — migrating the application, data, and traffic — has already been done.
  2. Replatforming: I sometimes call this “lift-tinker-and-shift.” Here you might make a few cloud (or other) optimizations in order to achieve some tangible benefit, but you aren’t otherwise changing the core architecture of the application. You may be looking to reduce the amount of time you spend managing database instances by migrating to a database-as-a-service platform like Amazon Relational Database Service (Amazon RDS), or migrating your application to a fully managed platform like Amazon Elastic Beanstalk. A large media company we work with migrated hundreds of web servers it ran on-premises to AWS, and, in the process, it moved from WebLogic (a Java application container that requires an expensive license) to Apache Tomcat, an open-source equivalent. This media company saved millions in licensing costs on top of the savings and agility it gained by migrating to AWS.
  3. Repurchasing: Moving to a different product. I most commonly see repurchasing as a move to a SaaS platform. Moving a CRM to Salesforce.com, an HR system to Workday, a CMS to Drupal, and so on.
  4. Refactoring (Re-architecting) or Re-imagining:  how the application is architected and developed, typically using cloud-native features. This is typically driven by a strong business need to add features, scale, or performance that would otherwise be difficult to achieve in the application’s existing environment. Are you looking to migrate from a monolithic architecture to a service-oriented (or server-less) architecture to boost agility or improve business continuity (I’ve heard stories of mainframe fan belts being ordered on e-bay)? This pattern tends to be the most expensive, but, if you have a good product-market fit, it can also be the most beneficial.
  5. Retire (Get rid of): Once you’ve discovered everything in your environment, you might ask each functional area who owns each application. We’ve found that as much as 10% (I’ve seen 20%) of an enterprise IT portfolio is no longer useful, and can simply be turned off. These savings can boost the business case, direct your team’s scarce attention to the things that people use, and lessen the surface area you have to secure.
  6. Retain: (Usually this means “revisit” or do nothing for now). Maybe you’re still riding out some depreciation, aren’t ready to prioritize an application that was recently upgraded, or are otherwise not inclined to migrate some applications. You should only migrate what makes sense for the business; and, as the gravity of your portfolio changes from on-premises to the cloud, you’ll probably have fewer reasons to retain.

Do:

Assess your current applications

It is essential to devise a detailed strategy before migrating your business operations to the cloud. That strategy starts with deciding what to do with your current on-prem applications. It will require an in-depth understanding of your existing business challenges and future goals because not every application will need to be migrated. It depends entirely on the vision set forth by your company and what you hope to accomplish by moving to the cloud.

Get input from employees

A common mistake when moving to the cloud (and implementing any organizational change) is discussing the upcoming changes with your employees. They are the ones who can tell you which applications you NEED to migrate to the cloud. Just because your organization is paying for something does not mean that your employees are fully utilizing it. Chances are some applications are not being used at all, and your employees will be able to tell which ones they are and why.

Determine WHY you want to move to the cloud

After deciding on your goals and which applications will need to be migrated, the next step is to figure out your why. Your reason for moving to the cloud is important because that ultimately supports and defines your overall strategy. Are you merely migrating because everyone else is telling you it’s the right thing to do? Are you trying to follow in the footsteps of your competitors?

There should be a good reason your company is moving to the cloud, and you should be able to answer why now is the right time to do so.

Find a partner

Choosing a partner to work with on your journey to the cloud can provide invaluable help. Businesses can accelerate their migration and time to results through a strategic partnership. A partner can also help by offering:

  • Licensing and Cloud Expertise
  • Cloud Migration Strategy & Planning
  • Mentoring on Optimization Best Practices
  • Team member Productivity Training

Don’t:

Lift and Shift

A simple lift and shift is the easiest and most common way to overspend in the cloud. The concept of just taking every on-prem application and moving them all to the cloud will not leave your infrastructure optimized. Not every application needs to live on the cloud, and, more often than not, choosing to lift and optimize your cloud infrastructure is a much more efficient way to tackle your migration.

Be reactive with your cloud optimization

Establish a strategy to obtain the maximum benefits of cloud adoption by tracking the fast-changing standards evolving for cloud computing. Before beginning your cloud journey, do the math and compare cloud computing expenses against in-house IT expenses.

Start without adequately making a budget

Cloud migration is a complex process, and so are the costs. Determining your move’s cost and benefits requires a strategic, holistic approach, so it’s essential to understand and account for all of the factors that go into a migration.

While cloud pricing used to be overly complicated, cloud infrastructure providers have simplified their pricing structures so potential customers can more easily understand them. There are many cloud cost calculators available to give you an idea of what your cloud infrastructure costs may be, regardless of whether you’ve selected a cloud provider yet.

Neglect Security in the Cloud

There’s never a time when keeping your data secure shouldn’t be a top priority, even when migrating resources to the cloud. Do not assume that the cloud environment you’re moving your data to will automatically be secure. Although there are several policies and services in place to protect your data, the cloud is still less secure than on-prem. Therefore your company information will be more susceptible to hacks and security breaches.

https://www.crayon.com/us/resources/blogs/the-dos-and-donts-of-cloud-migration-and-optimization/

 
douglas-bernardini-cloud-migration-microsoft
douglas-bernardini-cloud-migration-azure