Chapter 7 - UNIX Migration Fundamentals

Article
12/05/2007

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

Common Misconceptions about Migration

There are a number of common misconceptions about migration that should be recognized and addressed before initiating the migration process:

A migration is merely 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 UNIX, 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.

Sponsorship

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 respond to those challenges only 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 capability 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, there are many factors that 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 the 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 migration from UNIX. 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. Before beginning a migration, it is recommended to fully understand the interests driving the migration from the information gathered.

Although the four strategies are listed individually in the following text, several of them may be required at once to achieve the desired results. For example, for 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 given to 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. AVA is beyond the scope of this book, but is a service supplied by many consulting firms and supported by various portfolio analysis software packages.

Interoperation: Moving Part of an Application

Interoperation 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 UNIX system. 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.

Interoperation 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 reduce the need for UNIX.

Code Migration: Moving an Entire Application

Code migration involves recompiling or converting the application source code to the new platform. 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 there are a large number of different technical components that 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 there is a need for a major new application without the requirement of eliminating the older application.

Windows Production Environment

Establishing a production environment is an important step in migrating to the Windows platform. It is necessary to take into account how the Windows Server production environment should be designed, what production roles need to be established, and what processes need to be in place. A number of different resources are available from Microsoft and its partners that provide information on these subjects:

Windows Server System Reference Architecture (WSSRA). Architectural guidance with specific certified configurations established by Windows Server hardware and software vendors.
Microsoft Frameworks. Microsoft Solutions Framework (MSF), an approach to planning, building and deploying technology solutions; and Microsoft Operations Framework (MOF), processes for production operations based on the internationally recognized Information Technology Infrastructure Library (ITIL) set of best practices.
UNIX Migration Project Guide (UMPG). Process guidance for migration projects based on the fundamentals of MSF.

Windows Server System Reference Architecture (WSSRA) – Formerly Microsoft Systems Architecture (MSA)

WSSRA is a documentation set that guides organizations deploying Microsoft technologies at all stages of the IT implementation life cycle. The guidance provides an architectural framework that has been tested and proven in the lab with key hardware and software partners.

High-level use of the documentation serves as an aid to organizations developing standardized approaches to technology infrastructure. This architectural framework approach solves many typical enterprise-level problems that arise through unstructured, piece-by-piece, and non-standards-based growth. Low-level use of the documentation in the areas of design, build, test, and operation provides a tactical approach to solving implementation issues or leveraging best practice guidance to reduce implementation time, risk, and cost.

For more information on WSSRA, refer to:
https://www.microsoft.com/technet/itsolutions/techguide/wssra/raguide/default.mspx

The IT Life Cycle and Microsoft Frameworks

Within any organization, the IT services and the applications and infrastructure that support them have a finite life cycle. This cycle may be divided into three key sets of activities:

Understand the business and operational needs for the service and create a solution that delivers these within the specified constraints.
Effectively and efficiently deploy the solution to users with as little disruption to the business as the service levels specify.
Operate the solution with excellence to deliver a service that the business trusts.

Microsoft provides guidance and implementation packages for the effective employment of Microsoft technologies across the entire gamut of the IT life cycle. This guidance is clustered into two frameworks — Microsoft Solutions Framework (MSF) and Microsoft Operations Framework (MOF). MSF addresses the first set of activities, that is, analyzing the need and creating a high-value solution; MSF and MOF coordinate processes and activities to deploy the solution in the second set; and MOF addresses the final set of activities until the solution is retired. MOF also incorporates and extends a wealth of guidance that is already available through other existing and developing IT standards organizations.

The IT life cycle and the interaction of MSF and MOF throughout the cycle are depicted in the following graphic.

The development and deployment of an IT solution typically involves two IT teams. The project team is assembled for a limited time to plan, build, and deploy the solution. MSF provides a flexible and scalable way to plan, design, develop, and deploy successful IT solutions. MSF guidance consists of principles, models, and disciplines for managing the people, process, technology elements, risks, and the trade-offs that most projects encounter.

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

In contrast, the operations team is permanent and is responsible for the solution’s daily operations and management. MOF is designed to guide the operations teams. It provides technical guidance that enables organizations to achieve mission-critical system reliability, availability, supportability, and manageability of IT solutions built with Microsoft products and technologies. MOF guidance addresses the people, process, technology, and management issues pertaining to operating complex, distributed, heterogeneous IT environments.

The two frameworks are complementary, minimizing the time to value — that is, the time between recognition of the need and delivery of the service. Consistency of terminology and concepts between the two frameworks also supports the delivery of a high-quality service.

The two frameworks are also well integrated. For example, the deployment of an IT solution requires knowledge of the solution’s requirements and user controls as well as the system requirements to operate it. MSF and MOF both include guidance for team roles and processes that ensure a successful deployment into the production environment. Throughout development, MSF and MOF emphasize the institution of processes to ensure that the solution, or any change to the IT environment, is built for operability and supportability, and that it meets release requirements.

MOF guidance is based on the direct knowledge and experience of Microsoft, its partners, and consultants in the daily operation of large and small IT environments and execution of software and IT service development projects. Microsoft also incorporates and aligns with acknowledged standards from within the worldwide IT industry, often enhancing and extending generic standards to facilitate their employment in Windows-based operating environments.

For more information on MSF, refer to:
https://www.microsoft.com/technet/itsolutions/techguide/msf/default.mspx

For more information on MOF, refer to:
https://www.microsoft.com/technet/itsolutions/techguide/mof/default.mspx

Migration Project Guidance

The UNIX Migration Project Guide (UMPG)* *provides a general framework for migrating applications, databases, and infrastructure from a UNIX environment to a Microsoft Windows environment. The UMPG is a companion to migration solution guides, which contain project-specific, technical guidance.

The UMPG is organized sequentially at the highest level to represent the IT 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.

For more information on the UMPG, refer to:
https://www.microsoft.com/technet/itsolutions/
migration/unix/umpg/default.mspx

Download

Get the Introduction to the Microsoft Enterprise Platform for UNIX Professionals

Update Notifications

Feedback

Send us your comments or suggestions