Chapter 8: Mainframe Migration Fundamentals

This chapter provides information on common misconceptions regarding migration, the principles that should guide a migration, migration strategies, a brief overview of MSF, and prescriptive guidance available for a migration from inception to completion.

On This Page

Common Misconceptions about Migration Common Misconceptions about Migration
Guiding Principles Guiding Principles
Migration Strategies Migration Strategies
Microsoft Solutions Framework Overview Microsoft Solutions Framework Overview
Migration Project Guidance Migration Project Guidance

Common Misconceptions about Migration

A number of common misconceptions about migration should be recognized and addressed before initiating the migration process:

  • A migration is a technical exercise

    A migration requires a great deal of work up front in defining scope, targets, and plans before the target architectures can be defined. These activities require the active engagement of management, users, and customers. If migration is positioned as an exclusively technical exercise, it is unlikely to receive the required attention from management and customers, and will be at serious risk for failure.

  • Old skills will be devalued and people fired

    Confronting this misconception is one of the most important success factors in gaining support for migration. The technical skills and management disciplines that maintain the mainframe (for example, the knowledge of the business and its supporting applications) are also required in the Windows environment. There will be new skills to be learned, but they will not be radically new and will reward those who learn them with a more satisfying workplace experience and higher-valued professional skill set.

  • Programmers will be forced to learn new languages

    In many cases, the approach to migrating an application will be code conversion, recompiling application source code using a new version of the original programming language that can execute in the new environment. In this situation, programmers may work in a familiar language, and perhaps in the context of a familiar application.

  • Lines of code drives schedule and cost

    The use of automated analysis and conversion tools makes the measure of lines of code somewhat irrelevant. For example, it may require a minute to recompile a small application, and two minutes to recompile a large one, and, similarly, the amount of time to analyze a complex application may only be a minute longer than that of a simpler one. Scope and cost are much more profoundly driven by the amount of manual intervention that is required to analyze, recompile, and unit test all the components of an application. Applications that are cleanly architected and coded to observe good programming standards will require substantially less manual intervention.

Guiding Principles

Observing the following principles will improve the success of any migration process:

  • The migration must have well-defined and informed sponsorship.

  • The migration must be managed to the delivery of specific benefits.

  • The migration must target a set of business-driven capabilities.

  • The migration must be precisely scoped.

These principles are discussed under the following subheadings.


Without sponsorship, no migration initiative will survive the challenges that any major program of change will encounter. It is usually not sufficient for the CIO to sponsor a migration alone. The most effective sponsorship comes from the business management or a major consumer of the existing information technology services; ideally, even a small group of key business executives. Having a Sponsorship Team allows the work of sponsorship to be shared, and avoids the perception that the migration may be driven by the ideas of a single individual.

Migration is only superficially a technical undertaking; in reality, it should be considered a business transformation. A transformation such as this can be a complex and difficult process. Without steadfast support from the core business leadership, it is unlikely to succeed.

Informed sponsorship is also an absolute necessity for project success. Helping nontechnical decision makers understand the many issues driving a migration may require extensive preparation and effort, but is necessary because no matter how senior the sponsorship is within the organization, challenges will be made to the idea of migration. If the sponsor can only respond to those challenges by deferring to the IT group, the migration is at risk. Like all transformations, migrations threaten many established interests, both internal and among established vendors and partners. Thus, there will be no shortage of volunteers ready to defend the maintenance of the status quo.

Business Case and Clear Benefits

For the same reasons that informed senior sponsorship is needed, a business case for the migration that the sponsors can support and defend is also required. Business cases will be tailored to conform to the standards of the organization, but an important part of any business case is the benefits gained. Benefits such as “better competitiveness” may be adequate in some organizations, but are difficult to defend, and are useless for guiding the migration. Benefits must be stated clearly and need to be specific, believable, compelling and measurable.

The defined business benefits are the first in a series of many deliverables that should guide all decisions. Business benefits must not be defined just for the sake of checking off an item on a project plan and then forgotten. This is a key element in succeeding at a transformational change such as migration: having well-defined and mutually agreed upon benefits that are being sought, using them to guide decisions, and referring to them when making the inevitable compromises and tradeoffs that occur during the project.

Business-Driven Capabilities

A set of business-driven capabilities must be established as requirements for the migration. They are business-driven in the sense that they enable specific business capabilities that are required for the benefits to be realized. For example, the capability to process 100,000 customer orders per hour is a business-driven performance specification that has direct influence on numerous technical design decisions. This principle maintains a direct correlation between the benefits that the sponsor is counting on and the design decisions that are made. In this way, it makes the migration not only more straightforward but protects the business case it was initially founded on.

These requirements may be implicit if a single existing application is to be migrated. But because business change is frequently a driver of migrations, even apparently well-established requirements need to be made explicit.

Precise Scope

Scope creep is a phenomenon familiar to those who deliver IT solutions, and to those who pay for and sponsor them. Its root cause is an imprecise up-front understanding of the business problem being addressed. Defining the scope of a migration might seem to be a comparatively simple process, especially if the object of migration is a single existing application. Unfortunately, many factors may change the original intended scope:

  • Available budget can constrain the scope to what may be less than optimal.

  • Inter-application dependencies can force the scope to grow to accommodate interfaces and even other application subsystems.

  • Stakeholder expectations can cause the scope to grow if some stakeholders have a perception that they are not receiving sufficient benefits for their support and active contribution. In addition, when planning a large project such as a migration, some stakeholders may become interested only as an opportunity to address outstanding requirements that do not directly support the migration itself.

Although the scope may evolve from the migration’s inception, an organization should not select a migration strategy without a well-defined scope.

Migration Strategies

Four primary strategies are available for mainframe migration. The deciding factors when choosing an appropriate strategy include understanding the scope of the migration project, the resources and skills affected and required, the short and long term goals of the organization, and the level of complexity and commitment involved in implementing the strategy. It is necessary to fully understand the interests driving the migration from the information gathered before beginning a migration.

Although the four strategies are listed individually in the following text, several of them may be required simultaneously to achieve the desired results. For example, migrations that are initiated with a business-level or application-level scope, where the application being migrated consists of many different components, more than one strategy may be used.

Careful consideration should be taken when selecting the applications to migrate. It must be determined in advance whether to migrate a single application or all applications, and which specific applications are the most critical to migrate. For example, the drivers for migrating applications may be a combination of cost reduction or avoidance as well as the need to modernize capabilities.

An Application Value Assessment (AVA) is recommended to help select and confirm the candidate applications for migration. For example, a "lower value" application is at lower risk for failure and usually migrates quicker but benefits the organization less. However, a "higher value" application is at a higher risk for failure and is generally more complex and therefore more time-consuming, but provides a greater return on investment.

Note AVA is beyond the scope of this book, but is a service supplied by many consulting firms and supported by various software packages.

Integration: Moving Part of an Application

Integration involves moving one or more components of an application to the Windows platform. For example, one scenario may be to move executable components, but leave a database shared with other applications on the mainframe. Application components such as reporting job streams, high volume printing, or read-only queries may be separated from the rest of the application and migrated on an individual basis.

Integration will often be the first step an organization takes in migrating an application, because it mitigates costs and risks. However, this strategy may not deliver a sufficient degree of benefit commensurate with the required investment when compared to other available strategies that potentially eliminate the mainframe.

Code Migration: Moving an Entire Application

Code migration involves recompiling or converting the application source code to the new platform. Many third-party tools are available to ease this process, especially for applications written in COBOL. When using this technique, it is important to decide whether to migrate existing bugs associated with the code or fix them as the code is recompiled.

This strategy is an extended and complex process that can easily be underestimated because a large number of different technical components must be migrated. Recompiling code may not adequately address the needs of changed business processes, which may be the real benefit of the new application.

Replacement: Adopting a New Windows Application

The replacement strategy takes advantage of the availability of relatively inexpensive Windows versions of many “off the shelf” software packages. The old application is withdrawn from service and its functionality is replaced by the newly adopted Windows application. The issues in this strategy center on the adaptation of the business processes to the capabilities of the new applications, which are unlikely to exactly duplicate those of the old application.

Evolution: Begin to Develop Applications in the Windows Environment

The evolution strategy advocates using the existing application as a starting functional specification, and then rebuilding the application using modern programming languages and tools. The challenge here is to maintain existing applications and infrastructure as required while creating new applications and infrastructure. This may be an effective strategy to employ when you need a major new application without eliminating the older application.

Microsoft Solutions Framework Overview

Although this book does not specifically detail each phase of MSF, it is important to consider and understand the principles behind this proven framework to increase the likelihood of success in a mainframe migration.

MSF is a structured, yet adaptable, approach to managing technology projects that is based on a defined set of principles, models, disciplines, key concepts, guidelines, and proven practices from Microsoft. It provides guidance on how to organize projects to plan, build, and deploy successful IT solutions; while concentrating on the three aspects of people, process, and technology.

Specifically, the MSF Process Model establishes a series of tasks assembled into five distinct sections, or “phases”; Envisioning, Planning, Developing, Stabilizing and Deploying.


Migration Project Guidance

Note The following section is a brief overview of the UNIX Migration Project Guide (UMPG). Although specifically intended for migration from UNIX to a Windows environment, the fundamental phases and processes described in the UMPG are applicable to any migration, including a mainframe migration.

For more information on the UMPG, refer to:

The migration project guide provides a general framework for migrating applications, databases, and infrastructure from a UNIX environment to a Microsoft Windows environment. The migration project guide is a companion to migration solution guides, which contain project-specific, technical guidance.

The migration project guide is organized sequentially at the highest level to represent the technology life cycle stages of plan, build, and deploy. At the next level, the migration project guide is structured to follow the MSF Process Model for IT projects.

Table 8.1: IT Life Cycle Stages and MSF Phases

IT Life Cycle Stage

MSF Process Model Phase




Team defines the vision/scope of the project based on the business need, organizes the project, and delivers an approved vision/scope document.



Team develops the conceptual, logical, and physical designs and creates the functional specification. It also develops project plans addressing development, testing, communication, and other tasks, and creates and delivers the master project schedule.



Team builds and tests the solution components.



Team completes testing the solution and performs pilots and reviews.



Team deploys the solution and ensures that it is stable and usable. Responsibility then shifts to operations and support teams.

Envisioning Phase

During the Envisioning Phase, the team clarifies the business problem or opportunity that the solution must solve. The goal is to complete tasks and create deliverables regarding the project goals, constraints, and solution. The Envisioning Phase culminates in the creation of a vision/scope document, which when approved, indicates team and customer agreement on the purpose and direction of the project.

Table 8.2: Major Envisioning Phase Tasks

Major Tasks


Setting up a team

Senior management determines that a project is viable and selects a Program Manager who assembles a project team.

Defining project structure

Team creates the project structure, describing the administrative structure for the project team, including standards the team will use to manage and support the project.

Defining business goals

Team identifies the business problems or opportunities to determine the objectives for the solution.

Assessing current situation

Team assesses the current state of the business and performs a gap analysis to help identify a path toward the desired state of the business.

Creating the vision and defining the scope for the project

Team creates a shared and clearly articulated vision statement that guides the team toward its business goals. The team also identifies the scope of the project by defining what will and will not be included.

Defining high-level requirements and user profiles

Team determines the needs of each key stakeholder, sponsor, and end user to provide input regarding the formation of the solution concept, to provide criteria for evaluating the vision/scope document and to provide a basis for more detailed requirements in the Planning Phase.

Developing the solution concept

The team transforms the high-level requirements into an initial concept of how the solution solves the business problem. The solution concept serves as a baseline and sets the stage for the more formal design of the solution.

Assessing risk

The team proactively identifies project risks and creates plans to deal with them during the Envisioning Phase. It continues this recurring process throughout the project.

Closing the Envisioning Phase

The team completes the approval process for the Vision/Scope Approved Milestone by formalizing the documentation that records the results of its tasks and presenting it to management for approval.

Planning Phase

During the Planning Phase, the team defines the solution in detail. The team works to create the solution architecture and design, writes any functional specification, and prepares the work plans, cost estimates and schedules for various deliverables.

Table 8.3: Major Planning Phase Tasks

Major Tasks


Developing the solution design and architecture

The team begins the design process with the solution design and architecture and culminates it with a design document that becomes part of the functional specification.

Validating the technology

The team begins validation of the technology.

Creating the functional specification

The team creates a functional specification that describes the solution requirements, the architecture, and the detailed design for all the features.

Developing the project plans

The team develops a collection of plans that address how the six MSF team roles will perform their tasks. These plans are consolidated into the master project plan. The master project plan is considered a roll-up of all of the plans and, thus, also includes strategic items such as the approach, dependencies, and assumptions for the solution.

Creating the project schedule

The team creates the master project schedule, which consists of milestone-driven schedules developed by each of the individual team roles when planning their respective activities.

Setting up the development and test environments

The team creates development and testing environments that are independent of the production environment to develop and test the solution.

Closing the Planning Phase

The team completes the approval process for the Project Plans Approved Milestone and documents the results of completing the tasks performed in this phase.

Developing Phase

During the Developing Phase, the components of the solution are built including code, documentation, and infrastructure. The team also identifies and addresses new risks as they emerge during this phase.

Table 8.4: Major Developing Phase Tasks

Major Tasks


Starting the development cycle

The team begins the development cycle by verifying that all tasks identified during the Envisioning and Planning Phases have been completed.

Building a proof of concept

Before development, the team does a final verification of the concepts from the designs within an environment that mirrors production as closely as possible.

Developing the solution components

The team develops the solution using the core components and extending them to the specific needs of the solution. The team also develops and conducts unit functional tests to ensure that individual features perform according to specification.

Developing the testing tools and tests

The team develops a testing infrastructure and populates it with test cases that help ensure the entire solution performs according to specification. This solution test suite typically incorporates, as a subset, the individual feature tests used by developers in building the solution components.

Building the solution

A series of daily, or frequent, builds culminate with major internal builds and signify points where the development team is delivering on key features of the solution. These builds are subjected to some or all of the project test suite as a way of tracking overall progress of the solution and of the solution test suite itself.

Closing the Developing Phase

The team completes all features, delivers the code and documentation, and considers the solution complete, thus entering the approval process for the Scope Complete Milestone.

Stabilizing Phase

During the Stabilizing Phase the team conducts extensive testing to resolve and prioritize bugs in preparation for release. This is intended to improve the solution to meet the acceptance criteria for release to production.

Table 8.5: Major Stabilizing Phase Tasks

Major Tasks


Testing the solution

The team executes the test plans created during the Planning Phase, which were enhanced and tested during the Developing Phase.

Resolving defects

The team corrects defects identified through testing and from other sources. New tests are developed to reproduce issues reported from other sources and are integrated into the test suite.

Conducting the pilot

The team moves a solution pilot from development to a staging area to test the solution with actual users and real scenarios. The pilot is conducted before starting the Deploying Phase.

Closing the Stabilizing Phase

The team documents the results of completing the tasks performed in this phase and seeks management approval at the Release Readiness Approved Milestone meeting.

Deploying Phase

During the Deploying Phase the goal is to place the solution into a production environment. Included in this phase is stabilizing the deployment and transitioning the project to operations and support. When deployment is complete, the team conducts a project review and obtains final customer approval of the project.

Table 8.6: Major Deploying Phase Tasks

Major Tasks


Completing deployment preparations

The team updates the deployment plan and installs, configures, and tests hardware and software components.

Creating operation procedures

The team creates and documents procedures and defines checkpoints to help the operations team monitor and maintain the solution.

Deploying the solution

The team deploys the core technology and completes site deployments.

Stabilizing the deployment

Project team and operations work toward a predefined state of completion for the solution.

Transferring ownership to operations

The team formally hands over responsibility for the solution to the operations team.

Closing the Deployment Phase

The team meets the Deployment Complete Milestone requirements and later completes post-project reviews with the customer and project team.