With every day that passes, more businesses make the decision to move some or all of their applications and services to the cloud. The case for doing so is strong. By reducing or even eliminating on-premise hardware, there are immediate capital cost savings in terms of upgrades and maintenance costs.
Then there is elasticity: the ability to scale capacity and cost up and down in response to fluctuations in demand. The cloud also offers reliability and redundancy, industry-leading security and the ability to store and process vast amounts of data, a feature that is critical for making the most out of AI and the IoT.
Perhaps the biggest hurdle to cloud adoption is complexity. Over time, companies have developed customized applications and services, many of which are interconnected with multiple dependencies.
Migration is an apt word for the move from on-premises infrastructure to the cloud. It is a long journey, requiring a lot of effort and with plenty of obstacles to overcome. A sub-optimal migration can lead to all sorts of problems from unexpected costs and interoperability issues to security holes and compliance breaches.
This doesn’t mean that companies should ignore the call to the cloud; there are too many benefits for that. What it does mean is that careful planning is in order. Here is a five-step plan any business can use as a blueprint for embarking on their journey to more favorable business solutions.
There is no one-size-fits-all cloud migration template that will work for every business or organization. The very first thing every business needs to establish is exactly what it wants to achieve from the move. This should cover every aspect of each service and application and include specific metrics that you want to improve.
For example, if your prime reason for cloud migration is to save costs, you will clearly need to calculate the TCO of both your existing setup and various cloud options. Everything will need to be accounted for: server purchase or lease costs; data transfer and storage costs; energy costs; engineer salaries, etc. This should also be broken down per application for a granular insight.
You will also need to draw up a list of baseline performance KPIs to ensure that your new architecture delivers the same or better performance levels. For each app, current page load times, availability rates and conversion rates should be locked down.
This will not only enable you to determine if and when a migration has succeeded, but it will also help you to identify and prioritize your ‘quick wins,’ those applications that will deliver the biggest savings and performance gains while causing the least disruption.
Unless you have in-house engineers with hands-on experience navigating a cloud migration, you will benefit from the services of a cloud consulting firm or similar specialist. They will be able to explain what the various cloud providers offer and help design a hybrid or cloud architecture to fit your unique business needs. Some consultants may be a preferred partner of one of the big public cloud providers (AWS, Azure or Google Cloud Platform) while others will be vendor-neutral and more likely to give an unbiased opinion. On the other hand, consultants who are part of a cloud provider’s partner network are often able to access the best deals.
Before deciding on who to work with, ask them what experience they have with cloud migrations; which tools they use; what level of support they can give and how they will deal with the inevitable frustrations such as complex interdependencies; inflexible architectures and obsolete tech.
Most big migrations involve coordinating lots of interconnected parts so if you are working alongside a partner, it is important to be clear who is responsible for each step. Once you know exactly where you are going, have defined your baseline metrics and chosen a companion for the journey, it’s time to make some decisions about where to start.
Some applications and services will be easier to move than others. You may be able to ‘lift and shift’ those with few integrations and dependencies, especially if they have been designed to work across multiple platforms. Others may need to be tweaked or re-platformed before they can be moved over which can be tricky, especially if the original vendors or in-house developers are no longer available. Applications which have been custom built for your environment might need to be completely rebuilt to work in the cloud.
Once you have divided your applications into these types and mapped out their dependencies, you should be able to decide on a way forward, focusing on those ‘big win’ migrations discussed earlier as they are likely to deliver the greatest ROI and sooner. This can also provide benefits on a political level as the positive metrics will impress the board, helping to shore up support.
Other factors that should influence your decision include the application’s production level (e.g whether it is in testing, development, staging or production); its sensitivity to downtime; how many people depend on it; whether it uses stateful or stateless data and whether the data sets are shared with other applications.
When you start the actual migration process, the way in which applications are moved is as important as the decision of which to move first. Maintaining data integrity and operational continuity requires a careful analysis of each application’s integrations and dependencies.
You should also take a wider lens and look at whether you can take advantage of natural business cycles or planned maintenance periods. For example, if users of a service are used to a two hour maintenance window each night, it makes sense to bunch together all applications that are integrated with that service and work on them at the same time.
Maintaining compliance with industry regulations is also critical. Any change to an application workflow risks exposing data. Being aware of the regulations regarding storage and transmission of data will help inform the steps of the migration process and even whether an application can be migrated at all.
You may find that not all existing services can be migrated to the cloud. Anything that is left behind will need to be reconfigured or retired as appropriate.
Depending on the specific assets involved, you may decide to take a peace-meal approach, testing the migration with a small sample of customers first, or you might switch all customers over to the cloud at the same time.
Once you have started operating in the cloud, you will need to optimize the environment to maximize cost efficiency and performance. Your cloud partner should be able to check VM configurations, licensing arrangements and other factors that commonly lead to unnecessary spend. For ongoing support and optimization, outsourcing to a managed IT services provider can be wise. These services have the experience and knowledge needed to unlock the full value of cloud computing through automation and regular monitoring.
It is at this stage that many businesses realize that migration never really ends. Rather, by eliminating (or at least minimizing) on-premise architecture, they put themselves in the best position to react creatively and dynamically to a constantly shifting technology and business landscape.
Brent Whitfield is the CEO of DCG Technical Solutions Inc. DCG provides the specialist advice and IT Support Los Angeles area businesses need to remain competitive and productive while being sensitive to limited IT budgets. Brent has been featured in Fast Company, CNBC, Network Computing, Reuters, and Yahoo Business. He also leads SMBTN - Los Angeles, an MSP peer group that focuses on continuing education for MSP’s and IT professionals. DCG was recognized among the Top 10 Fastest Growing MSPs in North America by MSP mentor. Twitter: @DCGCloud