Establishing a Business Justification for a Migration Effort

The decision to migrate is never an easy one. There is inherent risk associated with the task, and there are several drawbacks that can make a migration effort appear to be unattractive when you first consider one, including the following:

• The benefits of a migration project, both tangible and intangible, are only achievable and measurable after the migration of the IT infrastructure is complete.

• The costs to the organization in terms of productivity and monetary expenditures can be significant.

• As a result of a migration effort, there is always a chance that people could lose their jobs.

Consequently, the undertaking must be clearly justified by the business benefits it yields. These benefits can be expressed in terms of technological advances as well as financial rewards, which can be related to improved productivity, scalability, availability, and the like. For information about the common benefits that can be achieved through migration, refer to Chapter 1.

In this section, we explain how gaining executive sponsorship and performing due diligence help justify the decision to undertake a migration effort

Gaining Executive Sponsorship

When undertaking a migration project, ensure that you receive executive approval by someone in a CFO capacity, as well as someone with CTO, CIO, or data center manager responsibilities. The CIO or CTO will be interested in the technical feasibility of the migration solution and will want to ensure that Service Level Agreements (SLAs) will be met and that the systemic qualities (reliability, scalability, availability, and manageability) are achievable. Additionally, a CIO or CTO will position the enterprise so that its technology will be implemented on a modern, extensible platform that will have longevity.

When executive sponsors consider the longevity of a platform, it is critical that they assess the ability of the chosen vendor to provide a technology road map that details the product plans for both hardware and software for some period of time. When working with vendors who are attempting to eradicate or merge existing product lines or environments, it is important to closely examine their offerings to ensure that the new products they are providing actually exist and will be backward compatible with earlier releases. The last thing any enterprise wants is to have to repeatedly migrate their environment and infrastructure to a schedule that is dictated by a third party, such as a hardware or software vendor.

The CFO, on the other hand, will want everything the CTO or CIO looks for, and more. A CFO's concerns relate to the total cost of ownership (TCO) of the new environment, as well as the cost to get there. This includes not only the costs of the new hardware and software, but also the associated costs of training, facilities modification, testing, system transition, hardware amortization costs, and the like.

Regardless of the metric used to justify a migration effort, be it TCO, return on investment (ROI), or some more esoteric construction, the metric must be measurable to ensure that all parties are satisfied. Moreover, as the following sections describe, the establishment of these metrics and the manner in which they are determined will be critical to the justification of the migration effort.

Performing Due Diligence

Due diligence is the act of verifying that a migration opportunity exists. The level of due diligence you perform will vary depending on the amount of risk involved in a migration project. Obviously, risk tends to scale proportionally to the size and complexity of a project. The amount of due diligence required will scale accordingly . For example, it is not unusual to spend considerable amounts of time and effort to perform due diligence for a mission-critical enterprise application. However, you would not expend this effort for a simple application port.

At this early stage of the project, the level of detail required for approval can vary. However, as you proceed through iterations of this phase or later phases, the detail captured during this phase might need to be refined through further assessment and analysis.

To successfully perform due diligence before beginning a migration project, you must perform the following tasks :

• Identify the business case

• Build consensus

• Establish and prioritize objectives

• Define a value proposition

• Identify benefits

Identify the Business Case

A business case is a document that includes an investment appraisal based on cost/ benefit analysis. There are several ways to derive an investment appraisal, including leveraging prior experience, applying industry rules of thumb, or performing detailed fact-finding. For example, lines of code might provide a rough estimate for rehosting projects involving source code porting techniques, whereas the number of business rules might be more appropriate for COTS applications in a rearchitecture effort. The business case includes high-level estimates of the cost involved in your project that are based on the duration of the tasks and the level of effort required to perform them; these costs need to be approved by a budget holder. The level of detail captured in this document will vary from project to project. In some cases, the benefits of a project are easily identified. In other cases, further analysis, both technical and financial, must be performed before a business case can be formalized .

After justifying a migration, you will create a resource plan that identifies the roles and responsibilities involved in a project, and the level of commitment required to support them. The high-level details that you capture in the business case should be moved forward into the resource plan you develop.

Chapter 3 provides information about the strategies you can use to develop a business case that can be used as an outline for the resource plan. It is possible that candidate architecture plans and artifacts might be required to develop the business case. It is this difficulty of defining justification activities that has led to confusion between these activities and the architect phase.

Build Consensus

Before beginning a migration that will touch many different components of an organization, you must ensure that everyone who will be affected by the migration is consulted. They do not necessarily have to be in agreement with the plan to migrate, but it is critical that all concerns are brought to the table before you begin the project. This also requires input from all stakeholders. Not all organizations are able to accomplish this. Frequently, upper-level management's decision to migrate is made in a vacuum without consulting other stakeholders. At the opposite end of the spectrum, the IT staff might initiate discussions about a migration without considering the business functionality supported by the application or the long- term technology plans for the organization as a whole.

To better accomplish the task of discovery, you should conduct a migration workshop. This event typically lasts two to three days, and allows all segments of the organization that might be affected by the migration to review the project together. Having everyone in the same room ensures that all viewpoints are heard and, hopefully, understood .

As an example of the types of interactions that occur at these types of events, consider a situation where the IT staff rejects the idea of migrating to a new platform, stating that things work fine as they are currently implemented. Their viewpoint might change when they find that the company is about to double its capacity and therefore double its demand on the current infrastructure. Similarly, the IT staff might say that application X works well, meets the existing SLAs, and is understood by everyone. However, upon finding out that the licensing fees for that technology have increased fivefold, they will understand why the business functionality must be migrated .

The workshop also has an additional advantage: It can be an early gauge of the amount of commitment there is for the migration within the organization. Little or no commitment to the workshop often indicates a lack of commitment to the migration effort itself.

The following figure illustrates the various components of an enterprise architecture. It is critical that participants representing all segments of the architecture are represented in the discussion of a migration.

Figure 4-1. Enterprise Architecture

The following table identifies who is responsible for the functionality associated with each component of the architecture. Before implementing a migration, consult all of these people (or their representatives), and ensure that they provide input about the impact the migration will have on their area of the enterprise architecture.

Table 4-1. Architectural Roles and Responsibilities

Position	Role	Function
Business Architecture
Process/Strategy	CIO or CTO	Understands and sets the technological direction for the organization as whole, identifying long-term technological trends, and positions the enterprise to take advantage of the trends whenever possible. This person typically attempts to implement technological convergence.
Financials	CFO	Understands the financial state of the enterprise as a whole rather than the line of business owner. This person ensures that the migration meets specific financial objectives.
Quality of Service (QoS)	Business unit owner	Understands the functionality provided by the application. This person is typically involved with developing SLAs and has the responsibility to ensure that they are met or exceeded.
Execution Architecture
Application	Software developer	Supports, maintains, and enhances the application. Understands how it is built, its dependencies, interactions, and third-party products used in the runtime or development environment.
Application Infrastructure	System/database administrator	Understands the data requirements of application. They are usually responsible for backup requirements.
Compute Platform	Operator/system administrator	Ensures that the platforms remain available.
Storage Platform	System administrator	Understands the interaction between the application and the storage platform, be it a SAN, NAS, or directly attached.
Network Infrastructure	System/network administrator	Understand the technology used to connect the application to a network.
Facilities	Technician	Ensures that the necessary environmentals (power, air conditioning, ventilation , battery backups , etc.) can support the hardware.
Management Architecture
People	IT manager	Defines the required skills for the IT staff.
Process	Management architect	Implements the IT management process (change management, trouble ticket reports , etc.).
Tools	System administrator	Implements the instrumentation of the IT environment.

The workshop is structured such that the initial kickoff session is attended by all participants. The perceived business and technological drivers for the migration are put forward for discussion. Having all the players in the same room allows for a quick determination of consensus or the identification of dissent. Remember, for the migration to be successful, everyone must understand why the project is being undertaken and the projected outcome before starting the project. Migrating IT functionality, only to find that the requirements of one group of stakeholders have not been met, is a fruitless, costly, exercise. Conflicts should be identified so that they can be remedied through the development of an alternative approach or by executive decree.

After the initial kickoff, interviews with the stakeholders are conducted to document their requirements and comments. Finally, a report providing an overview of the problems and business drivers is presented to those who attended the kickoff meeting. The purpose of this report is to draw a line in the sand and to identify what has to be done. The purpose of this activity is to define the "what," not the "how," of a project. As you will see, you cannot determine how parts of the project will be executed until you have fully assessed the three levels of architecture, developed a strategy, and evaluated the cost of implementing a solution.

In rare cases, organizations might fully understand what migrations require, both in terms of a solution and in terms of the necessary outcomes. In these cases, the necessary interviews and discussion have already been conducted, the approach identified, and required outcomes documented, so the workshop activity can be eliminated. However, before implementing a proposed solution, the organization might benefit from having its approach evaluated or assessed by an outside consultant as a form of due diligence. A neutral third party can provide an objective evaluation of the problem and recommended solutions.

In all cases, assumptions should be documented and deliverables clearly defined with specified due dates.

Establish and Prioritize Objectives

With any large or complex undertaking, it is vitally important that you clearly define and document the project's objectives and scope. Addressed too broadly, the project will not complete to the user expectations; defined too narrowly, it might not bring the benefits the organization requires. Balancing the objective and scope with the technical migration strategies is the key to a successful project.

Major objectives will fall into three main categories:

• Business objectives focus around process and functionality, assuring that the newly migrated environment provides adequate functionality and integrates smoothly into existing business processes.

• Financial objectives center on the cost (or total cost of ownership) differential between the legacy solution and the new solution.

• Technical objectives concentrate on ensuring that the delivered solution provides the qualitative factors to fully support the business.

When setting objectives for a migration project, ensure that they are measurable, achievable, and timely . The biggest pitfall when setting migration project objectives is failing to define measurable objectives that can be closely followed by estimating the timeliness of the objectives. Vaguely worded objectives such as "providing similar functionality" or " roughly the same performance" leave the project's success at the mercy of end-user opinion, which might not be kind after a migration has disrupted their routine. Objectives should be more clearly stated ”for instance, "meeting the functional tests outlined in the service definition document" or "providing performance that meets or exceeds the performance tests outlined in the service capacity plan."

Once you have identified the high-level objectives for a migration, prioritize them to suit your business case. All project stakeholders should be involved in the prioritization of objectives.

Define a Value Proposition

The choice of long-term strategies and short-term tactics depends on the drivers that were already in play. For example, if the inability to meet SLAs is a primary driver for a migration project, the migration should produce improved QoS or improved service levels. Addressing the business driver as a value proposition can help you determine which strategies and tactics will best satisfy your business needs.

Some of the value propositions resulting from a migration are tangible and measurable, whereas others are intangible. The tangible benefits are outlined in the following table.

Table 4-2. Tangible Value Propositions

Value Proposition	Description
Faster time to market	Ability to get application to market faster than redevelopment (rehosting)
Investment protection (intellectual property)	The same features and functions from the legacy environment (rehosting)
Improved service levels	Rearchitect new and improved service levels in the new environment, or architect to deliver on existing service levels
Reduction in hardware costs	Migration/consolidation of legacy assets due to performance characteristic of new technology
Reduction in software cost	Migration/consolidation of legacy applications resulting in fewer software licenses
Reduction in operational cost	Migration/consolidation of legacy assets due to performance characteristic of new technology, architected to support SLA requirements and defined processes and procedures
Reduction in facilities costs	Migration/consolidation of legacy assets due to performance characteristic of new technology causing footprint reduction
Improved performance	Increased performance characteristic of new technology

The intangible (or unmeasurable) benefits are outlined in the following table.

Table 4-3. Intangible Value Propositions

Value Proposition	Description
Staff skills retention	In the case of mainframe rehosting, there is no need to retrain the IT staff for new skills.
Staff skills improvement	In the case of UNIX/NT, staff retraining would be required; in most cases, it is looked upon as career enhancing.
Technological longevity	Sun provides best-of-breed investment protection with the Solaris OS.
Simplicity	Typically, when moving from multiple operating systems to a single operating system, all aspects of data center management are simplified.
Superior use of software market supply chain	By migrating from legacy solutions based on old hardware or software, the enterprise can rearchitect external support agreements to improve service or reduce cost (replace, rehost).

Identify Benefits

A number of migration benefits were defined in Chapter 1. As described in Chapter 3, these benefits create a value proposition for the migration exercise. As a result of migrating to new technology, the enterprise can expect to see an improvement in some metric that is relevant to its business functionality.

Ideally, benefits should be both objective and measurable. These benefits are the key drivers for the migration effort. If the benefits are not realized, it will be difficult to show that the migration effort was successful. Objective, measurable benefits, such as reduced licensing costs, improved throughput, or reduced transaction costs are clearer evidence of improvement than are subjective benefits such as the adoption of a a more modern technology, improved productivity, and reduced vendor dependencies.

Defining the Project Startup Stage

The justify stage defines a project plan including a project governance model. The business plan is used to obtain executive buy-in and sponsorship. The project governance model should be used to sustain the executive support throughout the project. Project governance includes the definition and nomination of a Project Executive/Project Manager team, together with other key roles to be undertaken during the project.