An important aspect of every IT project, and one would almost be inclined to say THE most important aspect of them is risk management.
Risk management of migration projects in particular has proven to be very debatable and difficult:
1) because most people only encounter such projects once in their career – hence there is not a lot of firsthand experience to fall back on;
2) given the previous statement, most people want to apply intuitively the principle of “divide and conquer”
Divide and conquer in this context means migrating parts of a mainframe, subsystems let’s say, piece by piece, learn from experiences, and move on to the next one. Allow me to share our experience at Anubex on this topic, and counter-intuitive as it may sound: …..this is potentially a recipe for failure!
You can do it this way, should do it even this way, but only when 2 key conditions are fulfilled:
1) the subsystems are nicely “encapsulated” with no direct common data sharing, and
2) the entire scope is still large enough – and this can easily be 10 to 20 million lines of code per subsystem.
When these criteria are not met, the following scenario will unfold:
1) temporary interfaces will be required, these are bridges between not migrated and already migrated pieces of the application, and this in order to keep the integrity or consistency of the applications intact;
2) there will be months lost in building and testing these obsolete interfaces - effort and time that are a pure waste, once the project is completed;
3) as more and more subsystems are migrated, more time and effort are required to build new interfaces and to update existing ones;
4) at the end more time will be spent in maintaining these interfaces than in completing the actual migration.
Conclusion:
While the idea of using subsystems was to reduce the risks of the project, the opposite happens and more risk gets introduced. The “dived and conquer” approach has now become the main reason for excessive costs, time and ultimately project failure.
To address this issue, we at Anubex have created a process, a methodology, combined with automation that allows us to migrate the application many times: in an iterative way we go through the cycle of
1) transforming code and converting data,
2) testing, and
3) tuning the tools
There are other video’s available with details on the process – Migratonomy, automated conversion and so on. Check them out!
During for example a 12-month project, we execute this iteration multiple times every day,
· At the beginning of the project to test to what extend the transformed code compiles, for example,
· or testing to what extent every program is functionally correct later on in the project,
· testing the correctness of the integration with the new scheduler works for the entire batch chain later during Integration Testing to the end of the project,
· And on and on
You get the picture: we transform code and convert data, we test, we find differences and we correct the tools, again and again, and at the end of the project we have gone through this process a few hundred times.
This means that we have gone through the process – mind you – of converting the entire application, subsystem, or the entire mainframe – a few hundred times: no artificial subsystems, no temporary interfaces, no unnecessary risk, duration or costs!!! When the moment is there to put the migrated system in production the process is well known, documented and risk free which ensures a go live without issues.
Some call this approach a Big Bang and find it scary. At Anubex, we have been involved in more than 100 migration projects, and we know this is the best way to do it
