For most organizations, moving to the cloud is no longer a matter of debate. Most are already using it in some form—maybe cloud-based productivity applications such as Office 365 and SharePoint or an app on users' smartphones that lets them interact with in-house business applications.
Many organizations have already moved most of the easy applications to the cloud but still have hundreds (or even thousands) of applications running in corporate-owned data centers and branch offices. Now they are looking to further their cloud strategy by engaging in application rationalization and moving as many of the remaining applications as possible to the cloud. The question for most is how.
Moving an on-premises application and all of its constituent parts—compute, middleware, and database—is not nearly as easy as signing up for SaaS and writing off a few unused software licenses. It requires careful planning and thoughtful execution for your go-live day to go off without a hitch. Here's a four-step approach.
1. Planning
As with all big projects and complex challenges, planning is essential. If you can what-if-scenario all of the potential pitfalls and problems you will encounter along the way (and you will encounter plenty), then it will make resolving them in a timely, cost-effective fashion much easier.
Put together an interdisciplinary cloud transformation team consisting of stakeholders from across the organization:
- Finance
- IT architects and operations people
- Program management (not just project management, since migrations are made up of multiple, interdependent projects)
- Cloud engineers
- Cybersecurity folks (of course)
- A representative from the CIO's office
These should all be permanent members of the team. Application owners, line-of-business managers, and other business stakeholders should be included when needed.
It is extremely important that all transformation team members have decision-making and sign-off authority. Nothing slows a project down like having to wait for decisions to go through an approval chain.
Here are just some of the decisions and considerations the transformation team will be working through:
- Deciding which applications and databases to move and how (partial or full lift-and-shift)
- Designing the cloud landing zone where the application will live (or zones, for multi-cloud deployments)
- Understanding the business impact, should things go awry
- Ensuring that business continuity and disaster recovery plans take the new cloud environment into account
- Considering the impact on developers, cybersecurity, and agile and DevOps process and workflows
- Determining the compute shapes—OS, types of virtual machines and containers, uptime requirements, storage arrays, microservices, etc.—each application will require
2. Discovery
The next step is to both identify the applications you want to move and understand their dependencies. Talk to application owners to understand how the applications actually work (not just how they are supposed to work), the workarounds users have developed, what other workloads will be impacted if the application fails, and so on.
It also is a good idea to deploy automated discovery tools. These will generate a spaghetti map of all of the daily interactions the application has with servers, networks, databases, middleware, microservices, APIs, storage arrays, and other applications, as well as the applications of your outside partners, suppliers, and vendors.
You will also need to understand where all of these applications and services physically reside in the world: in your data centers, the cloud, partner data centers, etc.
3. Pre-launch
After you've identified the applications you will be moving and how you will be moving them, designed your cloud landing zone with all of the needed services such as firewalls and middleware, identified dependencies, and so on, it's time to stand up a preproduction environment that will mimic the real-world conditions the application will run in.
It is a very good idea to involve more than just your IT operations people in this phase. Get your developers on board so that when problems do occur, it does not take the developers months to get up to speed on how the application runs in the cloud compared to how it used to run on premises.
If you are running an application across multiple clouds, this is even more critical, since no two cloud providers architect their environments the same way. (This was a mistake we made here at Micro Focus during one of our cloud migrations. When an application stopped functioning as expected, it took a full quarter for our dev teams to figure it out.)
At this stage, you're testing functionality and performance. Pre-launch allows you to validate your core processes: the business processes, the functional processes, the application transactions, and so on. From a performance perspective, you are stress-testing to ensure that any performance goals—such as improving the application's response times—are met.
Some organizations don't do this extensive pre-launch testing. Amazon, for example, has such a large footprint and fast deployment cycle it can select a small subset of customers upon which to test changes as they go live. Most organizations, however, should not take this approach.
4. Go-live
Go-live is more than just flipping a switch. You have to understand and have planned for a big shift in data flows. Up until now, you've had a production application running in your data center. You now have a live copy ready to go in the cloud.
You've done your testing. You know it works. But you now to have cut over and start directing traffic away from the old application to the new one.
You will need a strategy. For example, if you are running both applications in parallel before the changeover, you will need to constantly sync the updates. This is because you will be creating transactions and new data in both systems simultaneously.
You will need to code and design data synchronization so there is only one source of truth for transactions at any given time—either the old system or the new one.
You will also need to do tasks such as ensuring that the new application is registered correctly in the asset and service management systems. This will make certain that network monitoring systems are ingesting log data from the correct URLs and IP addresses and that trouble tickets are being generated for the new system, not the old one.
Make a good start
While not exhaustive, the strategies outlined here will give you a good starting point from which to explore your strategy further. While no two IT environments are the same, the approach they take to the cloud will be similar. It is imperative that you do not rush the effort. If a mission-critical application fails after it is moved and no one can figure out why, it will be costly.
With careful, thoughtful planning and execution, however, the goals you set can be met. Tens of thousands of organizations are benefiting daily by fully adopting cloud. Yours can too.
Keep learning
Choose the right ESM tool for your needs. Get up to speed with the our Buyer's Guide to Enterprise Service Management Tools
What will the next generation of enterprise service management tools look like? TechBeacon's Guide to Optimizing Enterprise Service Management offers the insights.
Discover more about IT Operations Monitoring with TechBeacon's Guide.
What's the best way to get your robotic process automation project off the ground? Find out how to choose the right tools—and the right project.
Ready to advance up the IT career ladder? TechBeacon's Careers Topic Center provides expert advice you need to prepare for your next move.
