Conversion Plan (draft 0.1)


There shall be three phases of this project to ensure minimal disruption to production during business software application update. The first phase shall be known as piloting, which is developing an UI interface using Microsoft Dynamics for the CRM portion of the Lotus Notes applications and Microsoft Exchange for the emailing portion. The piloting system shall run parallel to the production system that is Lotus Notes. The second phase is to convert the back-end, DB2 to Microsoft SQL 2012 and placing Lotus Notes into read-only mode, while the new system becomes the production system. The third phase is to retire the legacy DB2 and Lotus Notes system gracefully.



Our current production software is becoming outdated, whereby it lacks performance, intuitive user interface, integration with modern communication tools, reporting, analytics, and overall productivity enhancements that a current generation software can provide.

1.1      Purpose and Scope

The database system, DB2, in conjunction Lotus Notes shall be converted to Microsoft SQL, Exchange, and Dynamics. This change will enable programmers to create a system that meet the demands of current business processes with agility. Also, cost of support for a more main-stream software will be lowered as the talent pool for Microsoft SQL, C#, programmers is vast. More importantly, software development must constantly satisfy the demands of the work flow and business logic to create business advantages as compared to the industry.

1.2      Points of Contact

Vice President: My Boss’ Boss

Assistant Vice President: My Boss

1.3      Project References

Our software developer consultant shall produce a portfolio consisting of successful completion of projects with similar technologies and requirements… {include the resume of project consultant’s history and projects}

1.4      Glossary

This section contains a glossary of all terms and abbreviations used in the plan.  If it is several pages in length, it may be placed in an appendix.


This section provides an overview of the aspects of the conversion effort, which are discussed in the subsequent sections.

2.1      System Overview

This section provides an overview of the system undergoing conversion.  The general nature or type of system should be described, including a brief overview of the processes the system is intended to support.  If the system is a database or an information system, also include a general discussion of the type of data maintained, the operational sources, and the uses of those data.

2.2      System Conversion Overview

This section provides an overview of the planned conversion effort.

2.2.1     Conversion Description

This section provides a description of the system structure and major components.  If only selected parts of the system will undergo conversion, identify which components will and will not be converted.


If the conversion process will be organized into discrete phases, this section should identify which components will undergo conversion in each phase.  Include hardware, software, and data as appropriate.  Charts, diagrams, and graphics may be included as necessary.  Develop and continuously update a milestone chart for the conversion process.

2.2.2     Type of Conversion

This section describes the type of conversion effort.  The software part of the conversion effort usually falls into one of the following categories:


  • Intra language conversion is a conversion between different versions of the same computer language or different versions of a software system, such as a database management system (DBMS), operating system, or local area network (LAN) management system.
  • Inter language conversion is the conversion from one computer language to another or from one software system to another.
  • Same compiler conversions use the same language and compiler versions. Typically, these conversions are performed to make programs conform to standards, improve program performance, convert to a new system concept, etc.  These conversions may require some program redesign and generally require some reprogramming.


In addition to the three categories of conversions described above, other types of conversions may be defined as necessary.

2.2.3     Conversion Strategy

This section describes the strategies for conversion of system hardware, software, and data.    Hardware Conversion Strategy

This section describes the strategy to be used for the conversion of system hardware, if any.  Describe the new (target) hardware environment, if appropriate.    Software Conversion Strategy

This section describes the conversion strategy to be used for software.    Data Conversion Strategy

This section describes the data conversion strategy, data quality assurance, and the data conversion controls.    Data Conversion Approach

This section describes the specific data preparation requirements and the data that must be available for the system conversion.  If data will be transported from the original system, provide a detailed description of the data handling, conversion, and loading procedures.  If these data will be transported using machine-readable media, describe the characteristics of those media.    Interfaces

In the case of a hardware platform conversion – such as mainframe to client/server – the interfaces to other systems may need reengineering.  This section describes the affected interfaces and the revisions required in each.    Data Quality Assurance and Control

This section describes the strategy to be used to ensure data quality before and after all data conversions.  This section also describes the approach to data scrubbing and quality assessment of data before they are moved to the new or converted system.  The strategy and approach may be described in a formal transition plan or a document if more appropriate.    Conversion Risk Factors

This section describes the major risk factors in the conversion effort and strategies for their control or reduction.  Descriptions of the risk factors that could affect the conversion feasibility, the technical performance of the converted system, the conversion schedule, or costs should be included.  In addition, a review should be made to ensure that the current backup and recovery procedures are adequate as well as operational.

2.3      Conversion Tasks

This section describes the major tasks associated with the conversion, including planning and pre-conversion tasks.

2.3.1     Conversion Planning.

This section describes planning for the conversion effort.  If planning and related issues have been addressed in other life-cycle documents, reference those documents in this section.  The following list provides some examples of conversion planning issues that could be addressed:


  • Analysis of the workload projected for the target conversion environment to ensure that the projected environment can adequately handle that workload and meet performance and capacity requirements
  • Projection of the growth rate of the data processing needs in the target environment to ensure that the system can handle the projected near-term growth, and that it has the expansion capacity for future needs
  • Analysis to identify missing features in the new (target) hardware and software environment that were supported in the original hardware and software and used in the original system
  • Development of a strategy for recoding, reprogramming, or redesigning the components of the system that used hardware and software features not supported in the new (target) hardware and software environment but used in the original system

2.3.2     Pre-Conversion Tasks

This section describes all tasks that are logically separate from the conversion effort itself but that must be completed before the initiation, development, or completion of the conversion effort.  Examples of such pre-conversion tasks include:


  • Finalize decisions regarding the type of conversion to be pursued
  • Install changes to the system hardware, such as a new computer or communications hardware, if necessary.
  • Implement changes to the computer operating system or operating system components, such as the installation of a new LAN operating system or a new windowing system.
  • Acquire and install other software for the new environment, such a new DBMS or document imaging system.

2.3.3     Major Tasks and Procedures

This section addresses the major tasks associated with the conversion and the procedures associated with those tasks.    Major Task Name

Provide a name for each major task.  Provide a brief description of each major task required for the conversion of the system, including the tasks required to perform the conversion, preparation of data, and testing of the system.  If some of these tasks are described in other life-cycle documents, reference those documents in this section.    Procedures

This section should describe the procedural approach for each major task.  Provide as much detail as necessary to describe these procedures.

2.4      Conversion Schedule

This section provides a schedule of activities to be accomplished during the conversion.  Pre-conversion tasks and major tasks for all hardware, software, and data conversions described in Section 2.3,Conversion Tasks, should be described here and should show the beginning and end dates of each task.  Charts may be used as appropriate.

2.5      Security

If appropriate for the system to be implemented, provide an overview of the system security features and the security during conversion.

2.5.1     System Security Features

The description of the system security features, if provided, should contain a brief overview and discussion of the security features that will be associated with the system when it is converted.  Reference other life-cycle documents as appropriate.  Describe the changes in the security features or performance of the system that would result from the conversion.

2.5.2     Security During Conversion

This section addresses security issues specifically related to the conversion effort.


This section describes the support necessary to implement the system.  If there are additional support requirements not covered by the categories shown here, add other subsections as needed.

3.1      Hardware

This section lists support equipment, including all hardware to be used for the conversion.

3.2      Software

This section lists the software and databases required to support the conversion.  It describes all software tools used to support the conversion effort, including the following types of software tools, if used:


  • Automated conversion tools, such as software translation tools for translating among different computer languages or translating within software families (such as, between release versions of compilers and DBMSs)
  • Automated data conversion tools for translating among data storage formats associated with the different implementations (such as, different DBMSs or operating systems)
  • Quality assurance and validation software for the data conversion that are automated testing tools
  • Computer-aided software engineering (CASE) tools for reverse engineering of the existing application
  • CASE tools for capturing system design information and presenting it graphically
  • Documentation tools such as cross-reference lists and data attribute generators
  • Commercial off-the-shelf software and software written specifically for the conversion effort

3.3      Facilities

This section identifies the physical facilities and accommodations required during the conversion period.

3.4      Materials

This section lists support materials.

3.5      Personnel

This section describes personnel requirements and any known or proposed staffing, if appropriate.  Also describe the training, if any, to be provided for the conversion staff

3.5.1     Personnel Requirements and Staffing

This section describes the number of personnel, length of time needed, types of skills, and skill levels for the staff required during the conversion period.

3.5.2     Training of Conversion Staff

This section addresses the training, if any, necessary to prepare the staff for converting the system.  It should provide a training curriculum, which lists the courses to be provided, a course sequence, and a proposed schedule.  If appropriate, it should identify by job description which courses should be attended by particular types of staff Training for users in the operation of the system is not presented in this section, but is normally included in the Training Plan.

Leave a Reply

Your email address will not be published. Required fields are marked *