Are you ready to Migrate to the Cloud?

What steps are needed?  What skills are needed?  How fast can we move to the cloud? What are the pitfalls and concerns?  All of these are great questions and the concerns of most CIOs or whomever has been tasked with moving to the cloud.   Here is one approach to answer these questions.

My approach comes from the 6 R’s that Amazon Web Servers (AWS) offers.  I will modify them slightly and add an additional R.   Here is a picture of my flowchart for the process of migrating to the cloud. 

I will mention upfront; MISTAKES WILL BE MADE!  The best design will not be the first design!  The process of continual improvement will need to take place.  Get moving!  Don’t let “paralysis by analysis” prevent your cloud migration.  The more applications that you move to the cloud the more knowledge you will gain, and the designs will get better.  The best education and training you can give your team are hands-on experience. 

Which is more costly? A misconfigure datacenter or a cloud environment.  Cloud mistakes are less expensive than on-premise infrastructure mistakes.  When building out an on-premise datacenter, capacity planning takes place and equipment is ordered.  But what if too much capacity was ordered, or not enough?  What if the wrong type of servers, SAN or switches were ordered? There a not too many vendors that will let you ship back your servers, switches, SANs.  Also, normally there is a 1-year or 3-year contract with the datacenter to host your equipment.   Now, think of the time invested.  Contrast that to the cloud, if a mistake is made, changes can be made instantly, thus reducing costly mistakes.

The first step: Bring in a Cloud Architect.   I have a couple of thoughts on this.  If there are only a few applications to move, you may want to contract with a Cloud Architect.   In any other situation hire a Cloud Architect as opposed to contracting.  You will want an Architect to be invested in your company and not wondering about his/her next project or stretching out your project.   

How many cloud architects?  I was talking to a company that wanted to move over 500 applications to the cloud.   For a very large enterprise companies, you’re going to want to bring in more than one Cloud Architect and form another cloud team.  This will decrease the time it takes to migrate.  The Cloud Architects will need to work and communicate together with proper agreed upon standards.   Also, keep in mind that a Cloud Architect doesn’t have all the answers and could always use another opinion or perspective on designing. 

For small to mid-size companies, one Cloud Architect should be enough to get started.  If there is more work than one Architect can handle, bringing in a short-term contract Cloud Architect to assist might make sense.

No matter how many Cloud Architects are selected, be sure to get solid documentation.   Also, make sure the rest of the Cloud team has access to the Cloud design for each application.  Initially the documentation may not be understood, but some team members will begin to understand the design over time and the thought that went behind the decisions.

Next, start forming your initial Cloud team.  This may require some forethought.  Some companies will find techs who don’t want to learn new skills and want to stay with the legacy systems.   While other companies may have too many volunteers to work on the Cloud migration.  When making your selection keep in mind the legacy systems still need to be maintained, possibly for quite some time.  As the company focuses on the cloud remember managing the legacy systems is still critical to your business. 

Select those who are most eager to learn cloud skills.  Your Cloud team will learn along the way, but make sure to provide online training access for those who are selected so their learning will be accelerated.   The Cloud team’s skills will increase as they spend more time migrating to the cloud. 

Select 3 to 4 developers from your software development team.  Also, choose a Systems Engineer, Security Engineer from your infrastructure team, plus a Software Architect from your design team.  The developers will become the DevOps team.  The Systems Engineer will become the Cloud Engineer, the Security Engineer will become the Cloud Security Engineer.  The Cloud Architect will also be a member of this Cloud Team. 

If possible, choose a System Engineer with programming experience.  Keep in mind that infrastructure as a code (IaC) is the goal in your cloud environment.   Automation or IaC, will be learned over time, but someone with programming experience will reduce the learning curve. 

There is a shortage of cloud expertise.  Companies are finding it hard to find Cloud Engineers and DevOps to hire, some companies are developing these skills internally.  Other companies are shifting IaaS over to the Software Architect.

The size of the cloud team will vary depending on the size of your projects.  If scrum agile method is used, then form cross-functional members who can categorize the applications into one of the R’s.  The backlog can be the list of applications and the sprint length will be how many applications the team feels they can categorize.  If Scrum Methodology is used, then the Cloud team might be called your scrum team.

I would want on my scrum team for the assessment: Product Owner, Scrum Master, Development Team, Cloud Architect, Cloud Security, Cloud Engineer.  In Scrum methodology all members of the team are called “development team” regardless of what they do.  The exception is the Product Owner and Scrum Master.  I mentioned Cloud Architect, Cloud Security, and Cloud Engineer separately from the title “Development Team” because I wanted to make sure it was understood that those skills are needed and should be part of the team.   I would make the Software Architect the Product Owner on the Scrum Team.  The members of this team could change after each sprint based on the application and who in the company has knowledge of the application.  

This may be overkill for a small company.  If there are only a few applications that will move to the cloud, then just have the Cloud Architect, Cloud Engineer/DevOps and application developers meet to discuss. 

Let’s start the first assessment! During the assessment the Cloud team needs to discover the application’s features, function, security, communications, programming language, current hardware, licensing, impact on the business, impact on the customers, these items will be important when you design the cloud environment.  

As mentioned earlier, one company that I spoke with was planning on moving approximately 500 applications to the cloud.  Don’t assess all 500 applications at once.  Each iteration of the flowchart will produce more knowledge and skills.

The assessment shouldn’t take long.  Try to focus on the low hanging fruits or your ancillary systems so you can start your cloud migration quicker.  Start with your ancillary systems which are the best systems to gain cloud skills with and often with the least risk for the business.

Discovery Phase goes hand in hand with the Assessment Phase. As the Assessment Phase progresses you may discover things about your applications, markets, customers, or team which could affect the categorizing of the application.  For example, you may discover that your team lacks the skills necessary to move an application.   This application would then be categorized as “Retain” for now. 

Later, during a reassessment, if the skills are developed or acquired this application would be moved to another category.   It is possible that you may discover a few applications running that weren’t on the list.    There may be patching that needs to be done; there may be security issues discovered.   During the Assessment and discovery, it will become clearer what category the applications should fall under.  Below is my explanation of the 6 Rs and the 1 additional R.

Let’s define the categories.

Retire – During the assessment the team will discover applications/servers that are deprecated or soon will be.  If these applications are discovered categorized them as “Retire”.   In very large enterprise companies with many data centers this is common.   Even in smaller companies a few older systems may be discovered.  

With virtualization, spinning up multiple servers to test something is easy and happens often.   After the test is completed sometimes it is not communicated to the server team to turn down these servers.  When proper controls are not in place this negative effect of virtualization, which is known as Virtualization sprawl, happens.  The problem will be very costly in the cloud unless there are controls in place. 

Retain – There will be some systems that the team will determine that just need to stay on premise for now.  This could be ERP systems, old legacy systems, very complex systems, or systems that need to stay on-premise because of licensing or security.   Also, on the first assessment this may be the largest category.  To keep the speed of cloud migration moving a “Retain” doesn’t mean the application won’t eventually move to the cloud.  The “Retain” may mean, let’s wait and reassess this application when we have more knowledge, more skills, and more resources. This will provide less risk to the company.

Remember, there will be mistakes made along the way.  The ideal situation would be to make those learning mistake on less impactful and less critical systems.  As you move each application to the cloud you will gain greater knowledge, skills, insights, with better designs.   If the larger more critical systems are moved first, the team may not have the knowledge to take advantage of lower cost, higher availability cloud services.

Repurchase – I like to move Repurchase phase up the list because it helps the company to think “Cloud First” and “Cloud Adoption”.  During the assessment you may discover that an application running on-premise has a SaaS solution from the vendor.  Repurchase these applications as SaaS from Vendors in the cloud.   For example, move Exchange and SharePoint to Office 365 or any other product of your choosing.

This might be the team’s first experience working with a cloud-based software.  Additionally, by shifting some of the responsibility to the vendor this should free up staff to be able to participate in the cloud migration.

Rehost – These are systems that are running local but could easily move to the cloud in what is called a “lift and shift”.   That mean migrating on-premise servers/databases to the cloud with little or no modifications.   There are third party tools to help with this or you can use AWS or Azure migration tools to assist. 

Some suggest this maybe the easiest way to get your applications in the cloud, but it may also be the least cost effective.   There are choices to reduce cost, like EC2’s spot instances, or reserve instances.  Also, if the servers don’t need to be running 24x7, setup auto shutdown and startup.   For static websites, you may want to consider S3 Static web hosting.

 

Replatform – This is like Rehost, but with some modifications.  It is known as a “Lift and Shift and Tinker”.   Once you have gotten your feet wet with Rehost then it is time to lift and shift but make some changes.   For example, on premise you may have an application server that talks to a SQL database.  In the Replatform phase you may want to move the SQL database to AWS’ RDS service or Azure’s Azure SQL service.  Depending on the application you might want to setup autoscaling with a load-balancer in front.   

If you have a website that you moved to cloud storage, you might want to put in a Content Delivery Network (CDN) to serve up your website.   There are many small tweaks you can make in this phase.  As you start to make these tweaks you increase your knowledge and experience.

Rearchitect – Some might also call this the Redesign phase.  These are the applications that you want to rewrite to take advantage of cloud services such microservices or serverless services that the cloud providers offer.  Running function as a Service (FaaS) or taking advantage serverless services will result in the lowest cost.   Serverless and FaaS isn’t the answer for every application, but a properly designed application running as a FaaS or serverless will save money and reduce man hours of labor.

Reassess – You have made your first pass through.  The team’s knowledge, skills and experience have increased.   Does the team have enough knowledge to move one of the Retain applications to the Cloud?  If not, just reassess the remaining applications in the backlog using the knowledge that was gained from the last migration success.  Go through this process until you can eventually move all your applications and servers to the cloud.

There are many things that need to be figured out with your migration, like what to use for third party tools, automation tools, and programming languages.  Plus, you need to decide on the following: serverless, monitoring, cost analysis, tagging, security, account organization, and others.

Support your Cloud Team.  I covered team formation earlier and I mentioned that team skills will increase the more the cloud team works in the cloud.  There are some things that can be done to supplement their learning.  Online courses, attending conferences, attending usergroups, and giving cloud team members time to read best practices from the service providers. 

Cloud migration risk and concerns – as more of your technical team joins the cloud, you will have less resources on your legacy systems.  What if those techs assigned to your legacy applications/infrastructure think their jobs will be eliminated?  What if they feel underappreciated and they find another job?  A plan needs to be in place to deal with this risk. 

Let’s start your cloud migration – Bring in a Cloud Architect.  The Cloud Architect can help you get your cloud migration started.   They will have a similar approach to the one that I have described.  A Cloud Architect can help answer your questions and get your company started with cloud migration.