The first phase is where the parameters of the conversion project are established. This phase includes defining the overall data conversion scope; the assumptions and constraints that frame the conversion project; conversion entrance and exit criteria; high-level conversion milestones; project roles and responsibilities; and data exchange method and procedures.
Analysis and Design Phase:
The conversion begins by analyzing legacy data and MCSJ Modules through review of available documentation and access to data and applications where available. There are three major subcomponents of analysis and design. These address overall conversion process, the data conversion rules, and the conversion architecture and infrastructure.
Conversion Process Analysis:
This entails a holistic view of the conversion project lifecycle and considers how the data conversion will be executed once the requirements are defined and agreed on by both parties. The conversion execution flow considers how source data is provided to the conversion process; points at which data owners have visibility to data quality, when corrections to the data are performed, quality control check points, and how converted data is supplied to the target application.
Data Mapping Analysis and Design:
The principal output of data analysis and design is a Data Mapping Document that records data conversion rules and establishes a detailed link between source system(s) and the target system at the table and field level. The conversion rules must be detailed, unambiguous, and executable, and will include a description of any data manipulation, filtering, parsing, formatting, etc. required for a successful data migration. The data mapping document, the fundamental design document for all other aspects of the data conversion project, will also include a code dictionary, default values, and the disposition of data to be archived, converted and/or entered by hand either during data conversion or post-implementation. Additional profiles and reports provide information about source data cleanliness, quality, and completeness. These reports are instrumental in the data analysis, design, and data cleansing. Edmunds & Associates works very closely with subject matter experts of both the source and target applications and the end customer’s business process and data owners in attempt to ensure that the data will be converted successfully.
Conversion Framework Analysis: Considers such issues as data volume, data exchange requirements, security requirements to support conversion and how the conversion tools will be configured to execute these requirements. In addition resource allocation for the migration process will be estimated, such as number of processing computers, database environments and network infrastructure.
Edmunds & Associates conversion tools are configured to execute the agreed to conversion requirements defined in the Analysis & Design Phase. Quality control tests are developed to assess quantifiable and qualitative parameters to verify that the results of the conversion process were executed per the design. In this phase one or more test conversions are run internally to ensure the conversion engine and processes return the expected results. Any issues are resolved and the test is performed again as required. Additional requirements may be discovered during the build phase that alters the original design plan. Any changes should support the accuracy and correctness of the conversion data and minimize scope creep.
Test and Refine Phase:
Prior to the final go-live conversion, it is recommended that all the key stakeholders participate in one or more mock or simulated conversions during which source data is collected and run through the entire process, the target database is loaded and data reports generated as necessary. There are three primary reasons to execute mock test conversions: (1) Simulation of the final conversion process from start-to-finish confirms the overall time requires and allows for resolution of conversion/ deployment issues in advance of the final conversion (Go-Live). This is most critical on large-scale conversions or projects that have tight time constraints on system cutover. (2) Conversion of real data gives the process owners visibility into how the data will appear in the target application so that conversion and source data problems can be identified and resolved. (3) Mock conversion will validate “sample” converted data for the conversion team supporting design and testing of the target application/database. The conversion team refines the conversion tools and process as appropriate based on feedback from the data owner and the target system implementation team. The purpose, number, timing, and input/output content of mock conversions to be done will be determined on a case-by-case basis by the conversion team, the target system implementation team, and key customer stakeholders. However, execution of mock conversion must not put the overall conversion project at risk.
During test and refine phase, the data owners address those data issues that need to be corrected or enhanced in the source application and provide status updates to the conversion team. Data corrections are usually required if the existing source data cannot be loaded, or if once loaded, it will adversely affect the functionality of the target application.
The final or Go-Live conversion is defined as the last data extracted from the source systems, which results in the converted data populating the final production version of the target application at the end of the overall project. Once this data is extracted from the legacy source system(s), those system(s) must be frozen to allow for final data assurance validation and to allow data integrity throughout the conversion and verification process. Any changes to the legacy systems after the data is extracted cannot be included in the conversion and will have to be re-entered into the post production application (usually through manual entry).Click to edit this text...