The rise of cloud application migration factories
The cloud application migration factory is gaining momentum. This methodology enables companies to scale, accelerate and standardize their cloud migration and application transformation activities through a predefined, repeatable process. Read this paper about using highly efficient assembly line approach as each application moves through specific steps on its way to the cloud.
The centerpiece of most digital transformation initiatives is a directive to accelerate the migration of applications to the cloud. But organizations that take a piecemeal, ad hoc approach to cloud migration may be missing a golden opportunity to optimize and reimagine those applications and to deploy them on the most appropriate cloud platform.
One approach gaining momentum is the cloud application migration factory — a methodology that enables companies to scale, accelerate and standardize their cloud migration and application transformation activities through a predefined, repeatable process.
Almost like a highly efficient assembly line in a manufacturing facility, each application moves through specific steps on its way to the cloud. Those steps include an assessment of application readiness, preparing the application for the cloud, deciding whether it needs to be rewritten or not, identifying the best target platform in the cloud, testing and validating the application, and finally deploying it. Successful organizations will be able to accelerate their digital transformation.
Putting together a plan
Before an organization begins moving to the cloud, it is vital that IT executives and business leaders take a step back and carefully craft a strategic plan for cloud migration and application transformation.
An effort of this importance and complexity requires skilled people, an understanding of specific business challenges and goals, a thorough assessment of the current applications estate, deep experience in performing migrations, as well as the deployment of automated processes and specialized tools.
Factory treatments for migration and transformation
The application migration factory treatment starts with creating a readiness roadmap, also known as building the business case. In this phase, organizations conduct a total cost of ownership (TCO) assessment of the entire applications portfolio.
In the next step, decisions are made relative to which applications will be rehosted as is, which will be replatformed to the cloud with minimal changes, which will be refactored and rewritten, and which will simply be retired and replaced by a software-as- a-service (SaaS) solution.
Organizations then decide where each application will eventually land: public cloud infrastructure, on-premises private cloud, hosted private cloud, SaaS, platform as a service (PaaS), containers, cloud databases, serverless environments, etc. None of this is easy, but it is critical to the overall success of the migration effort. Diving right into a migration without a roadmap is a recipe for failure.
A lack of proper analysis and design can lead to surprises popping up that can have a ripple effect across multiple applications.
Organizations should come out of the readiness phase with a high-level, strategic plan. And they should line up an initial set of migration sprints, plus put together a roadmap that addresses applications not included in the initial rollout.
Once the strategic plan is in place, organizations create a detailed migration plan that includes a process known as deep discovery, which is vital for keeping migration activities on schedule. In our extensive experience with cloud migrations,
DXC Technology has found that a lack of proper analysis and design can lead to surprises popping up that can have a ripple effect across multiple applications. When previously unknown issues are uncovered by the discovery process, changes can be incorporated into the roadmap to ensure that the desired business objectives will be achieved.
It’s also important to automate as much of the application migration factory as possible. Organizations should develop lean, metric-driven processes and build out a factory fabric consisting of automated migration planning, workflow automation, development operations (DevOps) automation, agile life-cycle management and real-time dashboards.
Tools that automate migration and transformation processes can deliver significant savings in time and money. Unfortunately, there is no single off-the-shelf automation tool that does it all, so the migration phase requires highly trained experts who are experienced in using a range of tools and know how to orchestrate the work.
Cloud migration is not a one-and-done activity; it’s a continuous, iterative process.
Cloud migration is not a one-and-done activity; it’s a continuous, iterative process. Readiness plans should be reviewed on an ongoing basis, and migration plans should be adjusted on a sprint-by-sprint basis. Make sure you continuously collect and refresh data, refine and prioritize the backlog, and look for key lessons learned to ensure continuous improvement throughout the migration life cycle.
Companies planning a cloud migration would also be well served by developing a containerization strategy and making sure the internal DevOps team is well-staffed and well-trained. And security needs to be baked in, every step of the way. That means embedding security experts into DevOps to create a development security operations (DevSecOps) team, and making sure that security monitoring, threat vulnerability management, identity management, and integrated and cloud access security brokers are integral parts of the migration roadmap.
Another consideration is the ongoing maintenance, management and orchestration of this new, hybrid cloud environment, where complex, interrelated business processes are running on a variety of on-premises and cloud-based platforms.
There are several key sets of decisions that organizations face as part of the digital application factory process. In the following sections, we describe the key decision points for determining which applications are appropriate for rehosting or rewriting, and whether a one-step or a two-step migration approach is best suited to your business needs.
Lift and shift, or reimagine
While there might be a tendency to view legacy apps as a burden, they are assets that embody core functions and key data essential for digital business initiatives.
Companies should therefore manage applications as assets, removing impediments to their ability to function effectively and executing continuous business-driven modernization to provide optimum value.
Companies should identify their major pain points and prioritize applications based on how important they are to the business.
When companies assess their applications estate, they often discover that some applications need to stay on premises for a variety of regulatory, security and business process reasons. And not all apps should be rewritten, because the takes time and costs money.
Companies should identify their major pain points and prioritize applications based on how important they are to the business. For most companies, the top priorities are typically customer-facing, revenue-generating applications that might have special requirements, such as always being available or having the ability to handle rapid fluctuations in demand.
Here are some general guidelines for determining the migration path for different types of applications:
- Lift and shift. Traditional back-end data center or database applications are suitable for lift and shift, because moving to a public cloud platform can be accomplished quickly and provides immediate cost savings and improvements in performance while minimizing the business disruption that could occur if the application was to be refactored.
- Straight to SaaS. If there is an available SaaS solution that can provide the same functionality as a legacy application, organizations should simply switch to SaaS and retire the legacy application. SaaS is particularly appropriate for some of the more generic business applications such as sales, marketing and human resources.
- Replatform. Common scenarios for replatforming, which entails shifting the application to the cloud with minor modifications, include upgrading an outdated version of a commercial-off-the-shelf (COTS) application, a UNIX-to-Linux migration, a simple OS upgrade or migration of a legacy application that is approaching end of life, such as Windows Server 2008/SQL Server 2008. Replatforming can also entail a move to a PaaS environment, which enables cloud-native capabilities without the need for full-blown refactoring.
- Refactor. Highly customized applications that provide a key business differentiator should be refactored to take advantage of cloud-native capabilities. Rewriting applications as cloud-native offers companies the opportunity to slash costs, embed security, integrate with other apps and gain business insight from artificial intelligence-based data analytics. Going forward, all new applications should be written in cloud-native environments.
Figure 1 illustrates an industrialized approach to migrating applications to the cloud.
Figure 1. The cloud application factory approach allows companies to scale up and optimize their cloud migration and transformation efforts. Application migration factories apply an industrialized approach to rehosting and replatforming applications to meet a variety of business needs.
Evaluating two key migration approaches
Once an organization has a plan for each application, the next consideration is whether to take a one-step or two-step approach. In the one-step journey, an application is modernized before migration and then moved to the cloud in one fell swoop. In the two-step journey, an application is moved to the cloud first, then modernized in the cloud using cloud-native tools and methodologies.
The decision will be influenced by such questions as: Is the top priority business velocity or cost containment? And how much risk can be shouldered? The two-step approach, which most companies take, delivers the benefits of cloud computing faster than the one-step approach. Companies focused on TCO and who are willing to assume a greater level of risk are more likely to lean toward the one-step approach. But it all comes down to factors such as criticality of the application, agility requirements and source technologies.
A variety of benefits are associated with the two-step journey. This approach:
- Provides cost transparency that allows organizations to better map infrastructure expenses to specific applications
- Introduces development teams to the cloud-aware and cloud-native capabilities via software-defined infrastructure/infrastructure as code transformations
- Introduces infrastructure teams to software development concepts by defining infrastructure per application
- Moves applications to a micro-segmented network model, which improves security
- Improves identity mapping of engineers to requisite accesses so they can manage the applications and infrastructure they are specifically responsible for
- Reduces risk because there is minimal impact to the applications in the migration stage
- Makes future application modernization easier, since the infrastructure as code process is available to the next applications in the development pipeline
- Enables application teams to release updates more quickly, in tandem with rapid infrastructure changes
There are also several risks associated with breaking the migration into two discrete steps: Organizations can miss out on having a holistic view of business and operations needs during target technology selection; dependencies can be missed when prioritizing application deployment; and automation can slip through the cracks. (See Figure 2.)
Figure 2. An estimated 80 percent of organizations take the two-step approach to cloud migration and transformation. The journey begins with rehosting data center applications to infrastructure as a service (top) and continues through replatforming and refactoring applications in modernized platform-as-a-service and hybrid environments (bottom).
The one-step approach
A variety of drivers and scenarios would cause an organization to take the one-step approach, including:
- If there are serious quality-of-service issues due to having poorly functioning and poorly designed applications
- If a company is facing some type of financial or competitive crisis, it may want to move quickly
- When there is a requirement to achieve the lowest possible total cost of ownership right from the start
- In the case of a corporate mandate to standardize on platform as a service, such as Pivotal Cloud Foundry or OpenShift
- When licensing considerations associated with on-premises applications are an overriding pain point
- When improving the productivity of application developers is a top priority
- When cloud is not currently a top priority but companies want to stage applications for an eventual move to the cloud or some other platform
- If an organization must exit multiple end-of-life platforms such as Windows 2008, UNIX systems or legacy mainframes anyway
- If a company is seeking the efficiencies that can be realized when applications and infrastructure teams work in parallel on the application estate
The risks associated with this approach include essentially biting off more than the organization can chew and plowing ahead before key issues have been resolved. For example, organizations should be leery of moving ahead with the one-step approach if traditional silos between applications and infrastructure teams still exist, or if teams don’t have the experience or skill sets for cloud-native development and PaaS adoption.
Organizations can also experience unforeseen issues with scope creep, with discovering hidden restrictions and feature gaps in certain PaaS services and with keeping up with the migration schedule. But when done properly, a one-step approach can deliver the cost savings and business benefits companies seek.
Next steps for ensuring a successful migration
Cloud providers make it easy for customers to whip out a credit card and spin up a new server instance or launch a SaaS app within minutes. But enterprises seeking the long-term business benefits of a cloud migration should pump the brakes before moving piecemeal into cloud services.
Organizations should take a holistic view of cloud migration and transformation that includes building the business case, evaluating the company’s readiness, assessing the applications estate and then developing a strategic plan that describes the migration/transformation path for each application, as well as where that app will eventually land.
Whether organizations choose a primarily one-step or two-step approach, security should be built in, and automation tools should be used as much as possible. A detailed deployment schedule should be built, and managers should make sure a strict cadence of migration sprints is adhered to. It’s also important to remember that no matter how detailed the roadmap, the entire process is iterative, and improvements should be continuous.
Once applications are living in the cloud, companies are paying on a usage-based consumption model, so they should take steps to continuously monitor, manage and optimize applications, databases and file systems.
By using a highly automated application migration factory, organizations adopt standardized methods and procedures that will accelerate the pace of cloud migration, modernize their existing applications portfolio and create a platform for the creation of new applications that will drive digital transformation of the entire enterprise.
Contact us to learn more about DXC Application Migration and Transformation Services.