Migration
|
|
Take a look at some of our migration projects... It is known that newer software - written in more "portable" languages and 4GLs - can be run on differing systems, and that packaged software is usually designed by the manufacturer to run on a variety of platforms. The problem lies with old turnkey software - which may provide vital business needs - and yet which seems to be "tied" to the present hardware and operating system. Sometimes this hardware is so old, that it may be nearly un-maintainable and yet the software - which may not be able to be replaced by standard packages - remains vital for the company’s business. We have developed a methodology and techniques for migrating software from one system to another and this can apply to parts of the total Application, or to the whole system. In order to do this, two things are necessary: You must have tools to migrate software from one system to another. You must have a methodology which - like a "greenfield" software development - starts off with an emphasis on the design of the new target system. Tools The major tool that we use is a product called VAXSCAN which is a pattern matching programming language. We are able to write converters which, in their simplest form, will translate from one dialect of COBOL to another; in their more complex form will translate between one programming language and another - for example from POWERHOUSE to COBOL. We have a growing library of tools developed in VAXSCAN for migrating from one system to another. Methodology Our software migration methodology is based on phases - just like any other project methodology. At the start, especially for full system migrations, considerable emphasis is placed on the Design of the new target system. The target will be described in terms of the new hardware and its operating system environment. The design attempts to produce "interfaces" between existing code on the source computer and the new operating environment of the target system. For example, the old source system may be using simple flat files and on the target these are to become a relational database. As far as possible a series of interface routines are written so that the original (say) COBOL code still makes the same I/O calls, but behind the scenes, the interface routines now result in calls to the relational database. Similarly for user screens - which on the old system may interact directly with the application - now have to be interfaced to a transaction processing system and a completely different form of screen handler. When the design is complete it is formally agreed with our customer. Then some of the source system is made to work on this new target environment "by hand" - only when this is proven - do we start to write converters to automatically migrate the old code to the new system. How it's done Once the Design and Inventory are sorted out, converters are written and the code converted to the new system. A typical working day would then comprise: test the new converted system; find the errors; make changes to the converters and re-run the conversion overnight, so that new testing can begin on the next working day. We try to adopt the principle that we always change the converter to get a perfect result - and never change the code being converted. If we cannot stick absolutely rigidly to this principle, we make changes to the source code so that it "converts correctly". We never change the target code by hand. Inventory Another important item that is done at the start of the project is understanding and formally agreeing the "inventory" of the old software to be migrated. It is not uncommon for this to take a considerable time to derive - many (perhaps most) systems cannot be re-constructed from source code. It is not at all uncommon to find programs which have an executable binary - but no source. Equally programs are found which seem to be not called or used by any part of the system. Most companies have backups - including backups off-site - of binaries of their systems for emergency use; many would find that, were such backups to be lost, they do not have the inventories to re-build their systems from source! This is a vital issue for Year 2000 Testing Software conversion (or migration) projects are dominated by Testing, in that Testing may occupy as much as 50% of the entire project. Testing is done by comparison testing - by comparing test outputs on the old system with those from the new system. Wherever possible, this testing is automated. For example on the batch part of a system there will be such things as "daily run", "weekly run", "monthly run" and so on. Test databases or files, before and after the "monthly run", for example, will be compared between old and new systems. Such comparisons will be automated and every single difference needs to be understood and explained or corrected. For screens, scripts are required that can be run on both systems and these will commonly be in a sequence so that the databases between the old and new systems can be compared from the start and end of the sequence. All differences in databases and all differences in screen behaviour must be understood and explained or corrected. Customer Involvement The processes that we go through and the very large amount of testing undertaken mean that the migrated system is very reliable - at least as robust as the source system. This, however, relies heavily on the involvement of our customer from day 1 of the conversion Project. The Customer must be involved in the Design and must be responsible for preparing the Test material and the customer (as with all software projects) must conduct the Acceptance Tests.
One special area that we have great expertise in, is VAX to Alpha migrations.... |