Patrick Pushor is a creative thinker based out of Western Canada with a fierce focus on cloud computing and related technologies. Patrick consults in many IT disciplines related to automation, business process modelling, virtualization and cloud, and demonstrates his deep expertise in this first contribution to InsightaaS – a “how to” of application migration. The piece below is the first installment in a two part article series focused on the challenges of application migration, a topic that is sure to gain increasing traction with the acceleration of cloud adoption that has been documented by virtually all industry watchers. InsightaaS is pleased to welcome Patrick onboard for the ride. (ed.)
Application migration is often one of the most significant early challenges to enterprise cloud adoption. Many organizations are not waiting for all applications to be cloud aware before capitalizing on infrastructure-as-a-service (IaaS) offerings. As a result, tactical strategies for traditional workload migration to the cloud are needed.
At the same time, enterprise IT is focusing on the end of extended support for Microsoft Windows Server 2003 as the defining event that will trigger a complete evaluation of their application estate. Applications will be retired, migrated, upgraded, or even quarantined to run alone in extreme cases. July 14, 2015 is mere months away, however, many organizations still need to begin planning their move away from Windows Server 2003.
This article will focus on the “don’ts” of application migration by exploring some common pitfalls and how to avoid them. In it, businesses will find some questions to bring to partners that may help with migration efforts, as well as a level set on expectations around service provider functionality. A companion piece in this series will focus on the “do’s”.
The “don’ts”
Many organizations have worked their way through large application migration projects in the past. VDI, disaster recovery, and clustering and load balancing initiatives often have an element of workload migration associated with them. IT teams that have not experienced application migration en masse are advised to seek aid from a partner that has. Don’t do it alone! Of course experience is a consideration in the selection of any partner candidate, but the following questions may help filter out those with experience vs. those just trying to capitalize quickly on cloud migration or Windows Server end of life opportunities without understanding enterprise IT fundamentals.
- What tools exist to help me understand pre-existing relationships between application tiers spread across my data center that my current staff may not understand well?
- Experienced and honest answer: Very few to none. Some tools can investigate a single host to try and determine relationships between applications, but very few exist to crawl applications and try to ‘map’ the pre-existing data center from an app-centric information flow perspective.
- What are some of the best ways to classify or group applications with respect to migration?
- Experienced and honest answer: This can be done a couple of ways. If the organization is highly siloed by business unit (including IT), this will likely be the top level classification. If the company is more flat than that, application technology is a good place to start for classification. Group all SQL database applications and servers together, all Microsoft IIS servers together, etc. At this stage, questions can arise around servers that host multiple applications. It’s important to underscore the fact that it’s workloads that are migrating, not servers. Don’t try and fit a square peg into a round hole; virtual machine specs may not align well with either the catalog of instance size offerings from the IaaS provider or even the managed service provider. Lastly, some organizations with key application owners/support teams tend to silo efforts that way, handling all applications under a single group’s care as a wave of activity. That way, they can focus on the task at hand – support through the entire migration process and have it be top of mind until completed rather than having to revisit support for a task for each wave of similar technology. The right answer for each organization will depend on the nature of the business.
- How much downtime is associated with app migration?
- Experienced & honest answer: More than businesses will like. When migrating applications or application tiers without associated data the downtime can be minimal to none. However, applications like this are rare. Most applications have some sort of data or runtime component that is locked during their execution. So to migrate an app or even to pull only the data associated with an application from one place to another often requires an outage. There are tools and approaches that can minimize downtime associated with migration (tune in for part two of this presentation!), but planning for some downtime and ensuring the business is in the know is key.
It is a regular occurrence to see organizations interchange the meanings of application compatibility and supportability. Don’t confuse them! For older workloads migrating to newer platforms, the question of whether or not the applications will perform technically usually comes first. This is a question of compatibility. The concern that normally follows immediately on focuses on vendor support of the application in the new target environment. The distinction between the two is usually relatively well understood, but the two concepts become intimately related as evaluation of the application inventory begins. Some organizations will value supportability over compatibility and will begin their evaluation by establishing which applications will remain in a supported state post-migration. Others will do a technical feasibility study of each app (or group of technically similar apps) against the target platform and then funnel those results down into a supportability decision as one of the next steps associated with the evaluation.
The way an organization chooses to begin application migration planning comes down to risk tolerance. Some organizations (typically smaller ones) will rely less on third party vendor support for many applications and will emphasize technical functionality. Others will do the opposite. Regulated industries, such as finance and healthcare, take supportability very seriously as it is a key concept in many information related regulations such as PCI-DSS and HIPAA-HITECH. The reality is that this decision takes into account age of application, age of operating system, importance of the application to the business, possible alternatives and cost. If the challenge is big enough (at least five hundred applications, for example), building a team that will handle the tasks associated with understanding this information would be worthwhile. If it’s possible to build a short process for determining the overall need of the application to the business, including the aforementioned criteria, and have the same team exercise it throughout the life of the project, consistent and predictable results will follow; a project manager’s dream!
When migrating from a traditional data center or even a managed service provider to an IaaS offering, organizations should not assume that security, performance benchmarking and analysis, or data backup/retention will be automagically done on their behalf. The service provider may have specific functionality that can be leveraged to perform some of the aforementioned tasks (for example AWS Glacier for longer term data retention), but this capability is significantly different in fit and function to standard enterprise IT tools. Businesses need to look at their data center architecture and try to model each area of functionality with the short list of service provider partner candidates. The basic vectors of concern for tactical information management tend to be common and include data integrity, data retention (important for regulated industries), system performance, including load balancing, identity management, and of course data security. Whether service provider functionality will be leveraged, or third party solutions implemented to meet requirements, businesses should take the time to plan a complete approach that spans the entire application estate needs.
Stay tuned for Pat Pushor’s next article exploring the things to do rather than avoid, strategies around application migration and tool recommendations.
—
