So far, in our pursuit to understand the complex process of MES migration, we have understood the intrinsic and organization specific factors which affect the decision. We have also seen the strategies which may be used to implement the migration and change from the old MES to the new one.
However, to gain a complete understanding on migration it is critical to establish a methodology to plan the migration. So today we will look at the planning process irrespective of the migration strategy selected. The migration planning can be roughly divided into four phases, regardless of the selected migration strategy chose:
Phase 1. Migration Definition
This phase is put into action by the migration team defining the status-quo. A clear understanding on the system as-is is established first, helping the team to understand the pain-points and issues with the current system, along with the target areas where the functionality needs to change. It also helps to understand where the complexities lie in a changeover.
Once a clear understanding of the system and interdependencies is established the definition of the To-be stage can be done. Here, depending on the findings of the earlier stage, it is decided whether an application stays or gets replaced, fully or in part in the new landscape. This is the stage where the flexibility-harmonization trade-off are considered, in case of a corporate and multi-site migration.
This phase ends with defining the migration strategy. Once the strategy is chosen from the main possible strategies, Big-Bang, Phased Introduction or Parallel systems, the team then needs to highlight exactly what needs to change. This includes selecting the applications to change and selecting the intermediate and middleware requirements in-order to achieve the goal (routing/synchronization layers, hardware, data loaders, gateways/bridges, etc.).
Phase 2. Migration Preparation
This is where the legwork begins and execution of all tasks required to enable the migration is performed. Most of the tasks have been identified during the Strategy Definition activity of the Migration Definition phase, being the most typical ones the following:
Phase 3. Migration Execution
This phase begins with the Roll Out and Go-Live stage. Here, the application is rolled out in the sequence established and agreed upon during the preceding rehearsal stage. Simply put, this phase needs to be performed like a Swiss watch. Depending on the migration strategy chosen, there’s typically a downtime at this stage, after which the new functionality becomes available for the users.
Once gone live, the new system needs to be closely monitored, as chances of errors happening is quite high. Typically the IT personnel must be on permanent standby to quickly respond to problems.
Some phases of the execution depend on the selected migration strategy, such as phase-in of new functionality and phase-out (or switch-off) the old MES system.
Finally, there’s the retirement of migration utilities, involving the shutdown and removal of middleware, routing and synchronization layers, gateways, bridges, monitoring and validation software which was developed and introduced for the single purpose of supporting the migration. This activity needs to be well controlled as it carries a high degree or risk.
Phase 4. Migration Closure
This final phase includes performing the tasks necessary to close the MES migration project and ensure all deliverables have been met and milestones reached. Three main stages need to be considered here.
First, archive old MES data. This is mission critical as any data which is not part of the new database but has an operational value, needs to be properly archived. Great care is to be taken to ensure that data is available relevant to the time frame it was captured in, also important is to ensure easy availability for the purposes of analysis and reporting.
Then the new MES functionality can finally be activated. Depending on the migration strategy chosen, this might the first time where it becomes possible to finally take advantage of the functionality the new system brings, which was most likely the ultimate purpose for the migration.
Finally, this phase ends with the Decommissioning of the unused hardware and software, which may no longer be of any use.
In our series on MES migration we have tried to touch all relevant topics on the migration process, highlighting the importance of taking a project approach and considering all the risks and costs involved along with the time required. We also highlighted that the interdependence of organizational systems, the automation provided by the current system and the amount of downtime the operation can bear are other key factors which help decide which strategy to choose for migration. Finally we described the main migration techniques: Big-Bang, the Phased Introduction and the Parallel Systems approach, describing the pros and cons associated with each. Finally in our last article, we addressed the ideal approach to plan and execute the migration, irrespective of the strategy applied.
In summary, it is important to highlight one last time that, sooner or later, depending on the rate of change experienced by your industry segment, the need to migrate to a more modern MES application will become evident. When this happens, we hope our migration strategy frameworks will help you conduct successfully such a challenging project.
For a comprehensive view on MES migration, please do download our white paper here.
However, to gain a complete understanding on migration it is critical to establish a methodology to plan the migration. So today we will look at the planning process irrespective of the migration strategy selected. The migration planning can be roughly divided into four phases, regardless of the selected migration strategy chose:
- Migration Definition - definition of migration scope, target and strategy;
- Migration Preparation - carrying out of activities to enable migration;
- Migration Execution - execution of the migration strategy;
- Migration Closure - post-migration close-down activities.
Phase 1. Migration Definition
This phase is put into action by the migration team defining the status-quo. A clear understanding on the system as-is is established first, helping the team to understand the pain-points and issues with the current system, along with the target areas where the functionality needs to change. It also helps to understand where the complexities lie in a changeover.
Once a clear understanding of the system and interdependencies is established the definition of the To-be stage can be done. Here, depending on the findings of the earlier stage, it is decided whether an application stays or gets replaced, fully or in part in the new landscape. This is the stage where the flexibility-harmonization trade-off are considered, in case of a corporate and multi-site migration.
This phase ends with defining the migration strategy. Once the strategy is chosen from the main possible strategies, Big-Bang, Phased Introduction or Parallel systems, the team then needs to highlight exactly what needs to change. This includes selecting the applications to change and selecting the intermediate and middleware requirements in-order to achieve the goal (routing/synchronization layers, hardware, data loaders, gateways/bridges, etc.).
Phase 2. Migration Preparation
This is where the legwork begins and execution of all tasks required to enable the migration is performed. Most of the tasks have been identified during the Strategy Definition activity of the Migration Definition phase, being the most typical ones the following:
- Setting the systems - including the HW procurements and purchase, installation, configuration of the development, staging and production environments;
- Preparing the new MES - including modeling and customizing the new application;
- Training - training system administrators, power users and user users (although this group can be performed closer to the execution phase);
- Adapting as-is applications - at any layer (presentation, business or data layer) deemed necessary to accommodate the defined migration strategy;
- Migration Applications & Utilities - This activity consists in the development and testing of migration specific applications and utilities necessary to support the migration strategy (Routing and Synchronization layers, Gateways and bridge applications, Data loading & synchronization procedures, Monitoring and Rollback procedures);
- Integrated testing and validation - This activity consists of integrated tests for the adapted applications together with any migration utilities which have been developed - the goal is to make both functional and non-functional criteria of the complete system;
- Migration Rehearsal - includes validating the migration procedure as well as to getting the team familiar with the migration procedure.
Phase 3. Migration Execution
This phase begins with the Roll Out and Go-Live stage. Here, the application is rolled out in the sequence established and agreed upon during the preceding rehearsal stage. Simply put, this phase needs to be performed like a Swiss watch. Depending on the migration strategy chosen, there’s typically a downtime at this stage, after which the new functionality becomes available for the users.
Once gone live, the new system needs to be closely monitored, as chances of errors happening is quite high. Typically the IT personnel must be on permanent standby to quickly respond to problems.
Some phases of the execution depend on the selected migration strategy, such as phase-in of new functionality and phase-out (or switch-off) the old MES system.
Finally, there’s the retirement of migration utilities, involving the shutdown and removal of middleware, routing and synchronization layers, gateways, bridges, monitoring and validation software which was developed and introduced for the single purpose of supporting the migration. This activity needs to be well controlled as it carries a high degree or risk.
Phase 4. Migration Closure
This final phase includes performing the tasks necessary to close the MES migration project and ensure all deliverables have been met and milestones reached. Three main stages need to be considered here.
First, archive old MES data. This is mission critical as any data which is not part of the new database but has an operational value, needs to be properly archived. Great care is to be taken to ensure that data is available relevant to the time frame it was captured in, also important is to ensure easy availability for the purposes of analysis and reporting.
Then the new MES functionality can finally be activated. Depending on the migration strategy chosen, this might the first time where it becomes possible to finally take advantage of the functionality the new system brings, which was most likely the ultimate purpose for the migration.
Finally, this phase ends with the Decommissioning of the unused hardware and software, which may no longer be of any use.
In our series on MES migration we have tried to touch all relevant topics on the migration process, highlighting the importance of taking a project approach and considering all the risks and costs involved along with the time required. We also highlighted that the interdependence of organizational systems, the automation provided by the current system and the amount of downtime the operation can bear are other key factors which help decide which strategy to choose for migration. Finally we described the main migration techniques: Big-Bang, the Phased Introduction and the Parallel Systems approach, describing the pros and cons associated with each. Finally in our last article, we addressed the ideal approach to plan and execute the migration, irrespective of the strategy applied.
In summary, it is important to highlight one last time that, sooner or later, depending on the rate of change experienced by your industry segment, the need to migrate to a more modern MES application will become evident. When this happens, we hope our migration strategy frameworks will help you conduct successfully such a challenging project.
For a comprehensive view on MES migration, please do download our white paper here.
