Starting the Migration Project


Initiation of a migration project involves confirming its intentions and deliverables, and provides a starting point for subsequent activities. Ideally, the project would have been initiated before assessment and analysis have taken place. However, it is only after the analysis activities that you can determine the full picture of what needs to be done. Even if a project startup did take place before the assessment stage, it is essential to revisit startup activities following assessment and analysis.

Project startup enables you to:

  • Explain and clarify the planned intentions and deliverables of the project, so that you can manage the expectations of the project stakeholders.

  • Ensure that the requirements are well defined and bounded; otherwise , other application elements may be drawn into the migration, causing it to overrun .

  • Confirm objectives and timescales for the migration, so that you can manage expectations, recruit appropriate resources, and allocate tasks as necessary.

It is quite possible that a number of migration projects are identified; for example, one for back-end databases and one for specific user - facing applications. In this case, the project startup enables each project to be defined and any dependencies to be identified so that the migrations can take place as independently as possible.

The end of the initiation phase is marked by the completion of the first milestone where the migration team and the customer agree on the overall vision and scope of the project. The vision is the complete view of what the solution can be ” the refinement of the original idea. On the other hand, the scope establishes restrictions on the vision to establish what can be accomplished within the constraints of the project. In a way, creating the vision and determining the scope are opposites, but both pieces are required for a successful project.

For migrations from UNIX to the Microsoft Windows operating system, the vision is having an existing UNIX application work on the Windows platform. The application may include compiled application-specific code and libraries that are used by the application. Many UNIX procedures also include scripts that tie parts of the application together into an overall process. Part of defining the vision is determining which parts of the overall process must be migrated now, and which can be done later.

Choosing a Project

The business case for the migration is based on output from assessment and analysis; this enables you to investigate migration options and decide on a suitable approach. The business case can now be used to agree on the goals for the migration, selecting from any alternatives that might still exist (for example, whether a package should be bought). This maps onto the envisioning phase of a software development project, where the team decides on the direction of the project (the vision) and determines its exact goals in the form of a vision/scope document. You can assign success criteria to each goal, agreeing on these with the project stakeholder or user representative to provide a basis for agreement when the project is complete.

The sponsor of the project begins this process by establishing a clear understanding of who the customer is and who the end users are. The customer pays for the migration, and the end users use the ported application. The customer may be a person or persons in management who have an interest in the project, or the customer may be another group within the corporation that wants to see the results of the migration process. The end user may or may not be in the same organization as the customer. For example, the customer may be information technology management that is interested in cost savings, while the end users may be engineers or help desk personnel.

A number of activities may take place during the project, such as:

  • Deploying tools and building a development and/or a pilot environment.

  • Testing the migration or porting techniques by selecting a large enough source base and a complex enough build environment.

  • Running a prototype or pilot to verify the migration approach, to test tools and procedures, and to build confidence in the planned solution.

Each activity has a bearing on overall success of the migration process. In particular, you should handle prototyping activities carefully . Prototypes set the tone and expectations for the rest of the migration. For this reason, it is very important that the experience be positive and successful for the organization. A prototype project should be initiated as a test case for the larger migration project; this enables you to affirm that the staff, techniques, and procedures are all up to the task.

The vision/scope document ensures that everyone on the team shares and understands the goals of the project. This allows each team member to work effectively toward the project s successful completion. Each team member can make his or her own decisions without consulting other team members or slowing progress with time-consuming meetings. While it may seem like overkill to have a detailed project framework for what may amount to a very simple project, keep in mind that the project may set the stage for larger and more complicated efforts. Any tools, environments, and procedures you use have a lifetime beyond the migration itself, because they must support the application after it is ported.

Confirming the Scope

A primary deliverable of the planning phase is the functional specification. This document describes the requirements to be met by the migrated application and the way that these requirements are to be achieved. This may be as simple as getting the code to compile and run or it may involve extensive modifications to the source. Because the specification provides a foundation to measure results against, the importance of documenting the operational details of the planned application cannot be overemphasized.

Creating the scope of the effort includes determining which pieces should be converted and the way that the conversion is to take place. Options include using migration tools to run the scripts as is, converting to a platform-independent language such as Perl, and porting the working pieces to run in a Windows scripting or compiled language. The team must determine whether the application must be maintained on both platforms. If so, this somewhat restricts the choices and the ability to take advantage of Windows platform features.

The scope of your project ultimately depends on the resources you have available to complete it. Accordingly, there are a variety of ways that you can envision the scope of the migration, for example:

  • Do you merely want to see if the applications can be installed and launched properly? Or do you want to check further for specific functionality and performance?

  • Do you want a thorough investigation of any problems? Or does it suffice just to make note of them and move on?

  • Do you want to test every application currently running on the UNIX platform? Or do you want to focus only on the top-priority applications?

After the functional specification is compiled, you can review it against the vision/scope document for scope creep (that is, expansion of the scope). It is important to confirm that the specification does not go beyond the vision/scope that the team agreed to. Otherwise, the project is in danger of not being delivered within the time and budget constraints.

If the functional specification extends the vision/scope document, the teams must invoke change management procedures to determine whether the changes are required and whether the project can be extended. Otherwise, after all of the teams agree on its content, the document should be signed by the team leaders .

Setting Expectations and Deliverables

Confirmation of the scope and the functional requirements on the migration project are only two facets of the initiation triangle; the third facet involves setting the expectations of the team and the customer. The actual deliverables and other less tangible results combine to make up the expectations for the project, the lack of which can doom a project to failure. When the customer or management is expecting one thing and the team delivers another, astonishment is usually the result. It is advisable to have all parties agree on what the project will and will not accomplish.

The best way to ensure realistic expectations from both sides is to set out the success criteria for each deliverable. You can do so by considering the functional requirements in the specification and defining measurable criteria against which the requirements can be judged. These criteria may be straightforward, such as ensure message can be communicated between system A and system B, or they can be more complex, involving a series of steps. It may not be possible to determine criteria for every requirement ” for example, scalability and availability requirements are notoriously difficult to gauge. However, you should have reasonably complete coverage of all of the requirements, and you should agree on these with the appropriate stakeholders.

The success criteria that you define should link back to the objectives set for the project. Perhaps your organization is experiencing lower returns on its information technology investments as well as rising administrative costs, or perhaps your personnel are tired of administering multiple platforms and want to simplify the environment. Whatever your situation, the success of your project depends on being clear about your organization s specific needs and objectives.

As a group, you can agree on the criteria for success that allow you to determine whether an application can be feasibly migrated to Windows. Each application to be migrated to Windows should demonstrate feasibility (pass or fail) in four areas:

  • Feature/functionality . The application must have the same features and functionality on the Windows platform as it does on UNIX. This test focuses on the primary features and functions, as defined by the users and their specific criteria.

  • Multitasking . The applications identified need to operate in an environment conducive to user multitasking. During testing, additional applications should be launched to check the ability of the application to share processor cycles.

  • Interoperability . You may need to demonstrate that Windows users and UNIX users can coexist on the network, exchange files, and otherwise collaborate on projects without the burden of a complicated file-conversion process.

  • Performance . Compared to their speed on UNIX, applications must run as fast, if not faster, on Windows. You can measure performance using benchmarks where possible, or base tests on subjective analysis where no benchmarks are available.

Delivery of an agreed set of criteria marks the end of the initiation phase and the beginning of the project itself.




UNIX Application Migration Guide
Unix Application Migration Guide (Patterns & Practices)
ISBN: 0735618380
EAN: 2147483647
Year: 2003
Pages: 134

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net