August 14, 2015 | Written by: Prashant Bhatnagar
Share this post:
Recently, I met the director of IT infrastructure for a manufacturing company who told me he wanted to move to the cloud.
“What’s next?” he asked.
This is a loaded question, and it can be addressed many ways based on the company’s previous knowledge and experience with cloud. For some, moving to cloud is a complex project that presents significant business risks. Nevertheless, here are five areas to start your assessment:
Evaluate workloads or the group of applications that the customer wants to move to cloud. Common examples of workloads are business applications, email servers, SaaS services, external/internal websites, FTP servers and many more.
Business application workloads (as opposed to infrastructure services) form the bulk of a company’s servers. Some of these workloads are independent while others are interlocked with add-on applications. It is essential to migrate all the add-on applications together, which are heavily dependent on the primary application.
In a few cases, executives will want to migrate all interconnected workloads together, which sometimes constitutes 60 percent of the total servers. This requires more pragmatic and detailed analysis.
The CIOs may ask the team to do risk analysis or a proof of concept for testing cloud underlying infrastructure and services. You should test a non-critical application’s migration to cloud before committing to a total cloud transformation. If the company has multiple critical applications, prioritization should be done in batches or waves. The first non-critical application moved to cloud should be important enough for the CIO to make the strategic decision for the rest of the applications, used as a business justification model for cloud.
Customers must decide the specific time slots for their migration. They are different than downtime requirements for migration. During a certain part of the year, the business application performance is key in driving the company’s revenue. Clearly, this would not be the ideal time for a migration. System uptime and efficiencies are regularly reported. Downtimes are seldom given, and changes to the system are for critical business functionality only. It’s important to determine the months/weeks when migration can happen.
4. Grouping or interface
Sometimes subcomponents of the same application are named differently. Over a period of a business application’s lifetime they are treated and funded separately, and the top level IT staff categorize them separately during assessment. When it comes to moving to cloud, these subcomponents are part of the same combined application. Correctly determining the existing business application and infrastructure footprint is essential.
One also needs to document all the interfaces, synchronous/asynchronous data, and file transfers. It enables best permutation/combination approach for the set of applications/server images to migrate to cloud. The number of servers going live in a particular timeframe may also limit the migration.
5. Migration strategy
Cloud migration is considered a pure “lift and shift” of the software stack: operating system, applications, databases, interfaces and other components. In this approach, the customer expects similar functionality and features after the application is enabled in Cloud environment.
The second approach, “big bang,” is an accelerated approach where migration and an upgrade are combined together. For some customers, the big bang approach works better. It saves cost and manpower requirements by combining testing for the two changes. A single go-live also enables the company to achieve the same goal in shorter duration. The benefits will almost always outweigh the risk when using this approach.