Services

migration methodology & process

MigrationWare Approach

MigrationWare conversion services are offered from source conversion services only through to complete turnkey solutions.

In the migration world there are essentially 4 methods which can be used to migrate a system. If the systems are found to no longer meet the requirements of business, then a strong argument can be made for the rewrite or package implementation approach. If however, the systems are found to still largely meet the requirements of business, then a system migration is generally considered to be the best approach.

In the arena of system migrations, MigrationWare’s offerings deliver a considerable overall cost saving. These include :

  • Re-hosting projects where COBOL/CICS/JCL is retained on the target platform. The risk and cost of migration is low and investment in staff skills is retained for ongoing system development and maintenance.
  • Legacy Transformation projects where MigrationWare performs cross language translation, database conversion and application re-platforming. 4 GL languages are typically converted to COBOL.
Legacy Transformation
MigrationWare conversion services are sold as source conversion services

Quote Process Overview

On a Client enquiry or following a sales lead MigrationWare typically provides an Initial Rough Order of Magnitude quote (ROM) based on a MigrationWare questionnaire that is completed by the Client.

Should the Client accept then ROM, the Client then identifies and submits the source code and data definitions for analysis by MigrationWare.


MigrationWare’s analysis aims to firm up a fixed price by :

  • Identifying areas requiring customization
  • Establishing any Client specific standards
  • Classifying and quantifying the inventory

The purpose of this phase is to provide the Client with :

  • A fixed price quote
  • An anticipated duration
  • A macro plan
  • Information to justify the Client’s business case and the Client’s ROI

Should the fixed price quote be accepted by the Client, the Client and MigrationWare would engage contractually.

Project Execution

  • Conversion Planning

    On finalisation of a contract a detailed Project Definition Workshop is arranged and the project commences. The finalized Conversion Macro Plan indicating the planned start and completion dates together with the sequence of the Migration Work Packages as well as all other major project milestones is agreed.

  • Application Analysis
    • Analysis and documentation of the application components (e.g. code, programs, procedures, maps, languages, databases, applications)
    • All dependencies/co-dependencies/inter-dependencies of applications/databases are categorised and quantified
    • All unused, duplicate, standalone and missing components are identified
    • Missing components identified are requested from the Client prior to Conversion
  • Customisation
    • All Recode Standards and any database changes are agreed and documented
    • The approach to addressing all in-house or unsupported elements is documented, in order to determine the best method of providing for support of the functionality being sought by the client
    • The scope of the data to be migrated and finalisation of the database sanitising rules are concluded
    • Identify if any of the MigrationWare automated conversion tools require client specific customisation
  • Definition of Migration Work Packages (MWPs)

    Depending on the nature and size of the total program inventory, the inventory may be broken down into smaller manageable sets called Migration Work Packages and each of these may, in turn, be broken down into stages which will have deliverables associated with them.

    The stages into which each Migration Work Package is split are :

    • The Migration Package Planning Stage (Client supplied source code is analysed & inventory finalised)
    • The Migration Input Package Stage (Client supplied source code is converted)
    • The Migration Output Package Stage (MigrationWare clean compiling converted code to be delivered to Client)
    • The Migration Work Package Acceptance Stage (Client testing and acceptance stage)

    After the Conversion Planning Phase, the contract will be reviewed and a final, possibly revised, contract will be drawn up, and signed by both parties prior to commencement of the Conversion Phase.

  • The Conversion Phase

    This process involves the reworking of the source code included in the Migration Work Packages, as well as the related run-time controls from the Source Environment, into a format compatible with the requirements of the target environment, ensuring that when executed in the Target Environment the converted source code will fulfil the same Business Function as the existing systems.

  • The Acceptance Stage

    After the delivery of the Migration Output Package there is an Acceptance Period during which the Client will review and accept / reject the deliverables in accordance with the Acceptance Criteria specified.

  • Testing Approach

    MigrationWare can include testing as part of its offering, though generally the type of testing that MigrationWare would engage in is technical testing: Below is a description of the various forms of testing that MigrationWare can optionally include as part of it service delivery :

    • Technical Testing is defined as a cursory technical test to ensure that the application starts, passes control between programs, passes control between screens and that the target database can be accessed by the application.
    • Unit Testing is defined as when each program (and its dependent programs) for which test data is provided is tested as a standalone unit to ensure correct output e.g.an on-line transaction or a program step in a batch run.