Make your own free website on



Our Advanced Technology Migration Methodology is a set of processes and procedures designed to successfully manage all of the critical elements of a large-scale technology migration project whether it is an operating system migration project or an ERP, CRM or other large-scale implementation effort.

The methodology outlined here is specific to a Windows 2000 desktop and server migration.




Advanced Technology Migration Methodology


Under Construction

(please come back soon)


1.    Program Planning

o         Identify all IT and business community stakeholders.

In order for a project of this nature and magnitude to succeed then IT management and business community stakeholders must be involved in the planning and implementation of the project.

o         Determine exact client expectations.

o         Build client and consultant team organization charts.

o         Define roles and responsibilities for all team members.

Each team member must clearly understand his or her roles and responsibilities at each juncture of the project.

o         Create master project plan.

o         Identify all critical success factors.

o         Identify the project critical path.

o         Set team expectations and facilitate a final review meeting.

Communications is crucial to the success of any project, once the plan is established it needs to be clearly communicated to all team members and open to a final review by the team.


2.    Workstation Architecture

o         Collect a comprehensive desktop application inventory.

o         Facilitate working sessions to define architecture goals.

o         Define the workstation reference model.

The workstation reference model (WRM) is a common set of applications that reside on all workstations across the enterprise such as an office suite, anti-virus and remote workstation management software. It also defines security, asset management, policy management, systems management and change control processes.

o         Identify all vertical business units.

o         Define the vertical unit reference model(s).

The vertical unit reference model (VRM) encompasses the workstation reference model layered with applications that are specific to a vertical business unit.

o         Validate the desktop reference models.

Review the WRM and VRM designs with the IT and business community stakeholders. Review and licensing issues, one-off applications that fall outside the VRM. Also identify and address how to handle all local MS Access Databases, MS Excel Data Models and any MS Word Templates, that may be problematic during the migration if upgrading the office suite as well.

o         Identify the human resources that will be used for testing.

o         Determine the desktop hardware requirements for the lab.

o         Publish the workstation architecture and obtain sign-off.


3.    Server Architecture

o         Collect a comprehensive server application inventory.

o         Facilitate working sessions to define architecture goals.

o         Define the server reference model.

The server reference model (SRM) is similar to the WRM in that the common set of applications and processes must be defined across all servers.

o         Identify all functional server groups.

o         Define the functional group reference model.

The functional server group model (FSM) is similar to the VRM, however, in place of vertical business units; the focus is on server functional applications (e.g. SQL Server Model or an Exchange Server model).

o         Design the active directory model.

o         Validate the server reference models.

Review the SRM and FSM with the IT and business community stakeholders. Review any licensing issues, one-off applications that fall outside the FSM.

o         Identify the human resources that will be used for testing.

o         Determine the server hardware requirements for the lab.

o         Publish the server architecture and obtain sign-off.


4.    Lab Planning

o         Allocate a secure workspace for the test lab.

o         Build out the lab server environment.

o         Build out the lab desktop environment.

o         Appoint an appropriate lab manager.

The test lab process sits squarely in the critical path of the overall project. The lab manager must be both a technical specialist and a superior manager in order to assure the lab schedule is adhered to and that lab operations run smoothly.

o         Determine the imaging and deployment processes.

Servers and workstations should be built using some form of imaging technology like Norton Systems Ghost product. Deployment of images also needs to be addressed; options include CD, over-the-wire transfer, ZEN Works or other established distribution vehicles may be used.

o         Determine required links to existing systems.

In many cases access to production systems and data will be required for application testing in the lab. Issues of data security, availability and accessibility need to be addressed and plans need to be put into place that will assure that required data for testing will be available when needed in the lab.

o         Determine the criticality of each application for testing.

Each application should be assigned a criticality index from 1 to 4, where 1 is most critical and 4 is the least critical. Criticality is defined as how important a specific application is to the daily operation of the business and not necessarily the number of users who use the application. For example, one or two users may use the company payroll program, but if it does not work on the new platform, many people will be adversely affected if the application is not thoroughly tested. The criticality index directly determines how thoroughly a program will be tested in the lab.  

o         Use a structured methodology for developing test plans.

Test plans should be developed using well-established processes and procedures whereby each test has a stated purpose and expected result. Test plans designed in an ad-hoc manner, or without consistency will jeopardize the success of the project.

o         Write the test plans for SRM, FSM’s, WRM and VRM’s.

Test plans should be developed as a joint effort between users and technical staff. The users are experts in the manner in which they use an application. They provide a great deal of insight as to exactly which functions are critical to business operations. The technical staffs are experts at knowing what is most prone to cause trouble with an application. Successful test planning must incorporate input from both parties then should be carefully measured against the criticality index for the application in order to determine exactly how an application will be tested.

o         Publish lab execution project schedule.

In order to keep the test lab running near 100% productivity, the lab schedule is both a critical path item and a critical success factor as the test lab process is directly in the critical path for the overall project. Care must be taken to assure availability of hardware, software, network, data and human resources. Commitment to the schedule from senior management is important to assure that users and technical staff make themselves available for test plan preparation and for actual testing in the lab.

o         Facilitate final lab review meeting.

o         Build lab activity tracking database in MS Access.

A database needs to be developed that will track all metrics and issues associated with each application, WRM, VRM, SRM and FSM. A variety of simple reports can give management a clear picture of all open problems and where they stand. The database will be a valuable tool to support the managed implementation team to expedite problem resolution during deployment. The tool will also provide invaluable data to the help desk or support organization in providing post implementation support for the new technology.


5.    Lab Implementation

o         Test the server reference model (SRM).

o         Test the functional server group models (FSM).

o         Test the workstation reference model (WRM).

o         Test the vertical reference models (VRM).

o         Test reference model deployment processes.

The processes and procedures for the deployment of desktop and server images must be tested to assure that there will be no problems during the implementation process. This is especially important if some form of over-the-wire deployment methodology is employed.

o         Test the one-off applications.

o         Test one-off application deployment processes.

o         Judiciously document problems and resolutions.

The MS Access Lab Tracking Database is to be used to track every issue and subsequent resolution for every application and component of each WRM, VRM, SRM and FSM. Once a problem has been opened, it can be tracked through to resolution using this database. The reports generated by the system will enable project management and lab management to clearly identify lab productivity and enable successfully management the project’s project critical path.


6.    Pilot Planning and Execution

o         Define the pilot goals.

Goals for the pilot need to be clearly established and communicated to all team members.

o         Implement all backend and server functionality.

All servers required for the pilot need to be brought online and connectivity to all other backend services needs to be put in place prior to running the pilot program.

o         Identify the pilot group.

The pilot group can be a single vertical business unit or a few users across business units. The choice will depend on the pilot goals. Never choose a user or group of users that if adversely affected will result in business discontinuity or political problems for the information technology group.  

o         Provide sufficient notice and preparation to the pilot group.

Plan a meeting to communicate to the pilot group what is going to occur and when. Make certain that the timing of the pilot program does not interfere with normal business operations for the pilot group.

o         Determine a personality capture methodology.

Users may have saved personal data on their local workstations as opposed to the network. Sometimes it is for security reasons, other times it is in blatant disregard for company computing policies. Nevertheless, a comprehensive plan to capture the personality of each workstation prior to migration must be put into place. This can range from a corporate memo to backup all data to the network by the user, to implementing a personality capture program at each workstation to making an image of each users workstation prior to migration.

o         Assure a comprehensive back-out plan is in place.

This is especially critical for the pilot migration group, in case something goes wrong with the pilot program, a complete restoration of the original workstation must be made possible in a reasonable timeframe in order to assure business continuity.

o         Assure a training and support plan is enabled for the pilot.

Even though the full-scale implementation may be planned for weeks or even months after pilot, a training and support plan needs to be in place to support the pilot users. 

o         Execute the pilot plan.

o         Perform a post mortem analysis of the pilot program.

Once the pilot has successfully been completed a comprehensive review of the lessons learned will be invaluable in fine-tuning the final implementation plan.


7.    Implementation Planning

o         ….

o         ….

8.    Managed Implementation

9.    Training and Support




© 2002 by Leonard Stephen Leffand

Proprietary and Confidential

All Rights Reserved

(Any Duplication Without Expressed Written Consent is Strictly Prohibited)