Mitch M. • Frank, I have been involved in a number of successful migrations off the mainframe. The major issue is cost. These are typically smaller environments that don't need the capabilities of the aminframe any longer. One of the major issues was how to be successful at getting the existing core applications to a new environment with the least amount of impact on the user community. It can be done, but it requires significant planning and the right partners to do the migrations. I have been told consistently that the major issue in deciding who to partner with for the client is choosing a company that has a proven, verifiable solution.

Unfortunately, I have also been in situations where we have had to "pick up the pieces" from a previous vendor who failed. It is important that the client look at a PROVEN solution with a TOTAL package. You can't just convert the programs and think you will be successful. You have to consider the data, the access to the environment, what packages need to be replaced, the risk involved, etc., etc., etc.

Juan D. • Frank, I have been involved in migrations off the mainframe, too. All of them to the AS/400, and the reason, always, "cost". Same as Mitch said.
Best regards.

Scott H. • The prime time for people to have migrated off the mainframe was in the 90s when the Y2K issues came. Usually cost is the overriding factor in all cases.

* how much would you save in TCA costs by platform migration.

* how much is the cost of manpower to migrate...(and by extension, how long will it take to migrate)

* how much(and how long) will it cost to run parallel systems during a conversion.

* how much is the TCO during the conversion and after the conversion..

* how much is it costing you now

* how much would modernizing in place cost you

* what business value do you gain by migrating...(and will it be worth the money)

* who/how will this be financed...

* are there other mitigating costs that may be incurred... (increase in power consumption.. increase of cooling needs, other equipment(peripherals, cabling, disk, etc..))(including upgrading of UPS/battery/generator... air conditioning)

If a company does not anticipate these cost factors... you most likely are looking at a disaster waiting to happen....

All these things are even before any of the TECHNICAL issues come into play.

The modern mainframe now has specialty engines, p-blades, and x-blades... If any company is FIRMLY planning to migrate off the mainframe... it probably behooves them to use the zbx process.. and convert their stuff safely and without a forced march approach...

Right now, union pacific is trying to do a mainframe migration project... that Joe Clabby has looked into....

http://www.clabbyanalytics.com/uploads/Union_Pacific_Final.pdf

Robert F. • Smaller companies with lower processing demands and several other lower demands are the ones which are more likely to successfully migrate from the mainframe - that also includes those which probably didn't need to go to the mainframe in the first place. Some of the most successful migrations I have been told were to the AS400 platform. large companies which really do need the power and resourcs of the mainframe - well good luck - you are probably not going to make a successful migration. The 90s being the best time to have migrated? I doubt that As a consultant, I have been at hundreds of companies (all mainframe) and if and when it was discussed, the general reaction was 'not now' . I have never seen a successful migration off the mainframe. I have seen several that were in process for years and never made it. If a company has been on the mainframe since the 60s or 70s, it probably has too much invested in localy written systems with insufficient documentation to migrate properly. These systems were and are running 'mission critical' operations. It is not like buying a new car. It is more like a brain transplant - not in my ligetime.

Geoff D. • The whole "downsizing" idea that was recommended by some IT guru in the States and followed blindly by many organisations in the 90's (sorry - I don't remember his name) had one fundamental flaw; he (like many others) failed to see that the Mainframe was actually a massive file-server at a time when many people were extolling the virtues of UNIX/LINUX for MI and Datawarehouse. I seem to remember this particular person made a short statement on the 10th anniversary of his original "Emperor's New Clothes" theory along the lines that many organisations got it wrong and probably shouldn't have taken that route after all. Unfortunately some were unable to go back and suffered the consequences.
When all is said and done, in my opinion the Mainframe has passed the test of time with flying colours as it has constantly evolved and not relied on the reputation and successes of it's past glories. It is now the most secure, stable, reliable, powerful, versatile, scalable and mature architecture to entrust your entire IT infrustructure to.

Frank T. • Our survey includes questions on migration challenges. If you haven't already taken it, I encourage you to take a few minutes to answer a few questions. Participants get a copy of the results, so you can see what others claimed were the biggest challenges, among other interesting data results.

Please also feel free to forward the survey link on to others. Again, participants get a copy of the results as a thank you.

http://bit.ly/pEsOWx

Pierre F. • There are two distincts problems : Data and Traitments.
For the Data, it is not difficult to convert IBM DB2 DATA to ORACLE DATA. So the differences are not very important (dates formats or other formats to change a little), and your datas come from an IBM computer to a UNIX computer by tapes.
For the Traitments, you often need to find a Transaction Monitor on UNIX (TUXEDO ?) to replace the IBM CICS or IMS Transaction Monitor, for instance. And it is a bit more difficult to convert your traitments. It is long and expensive but you can do it. It is possible also to convert your IBM JCL to a UNIX script.
For your programs written in Cobol, we can often find Cobol Compilator, as Microfocus for instance, on other platforms (Windows, UNIX) with some small adaptations.
Of course, it is easier to convert from an IBM computer to another IBM computer (as AS/400 or other).

(But some big companies in France wanted to downsizing their legacies platforms twenty years ago but don't want it anymore. Than, they need also to centralize their traitments for consolidation and control. Some of them wanted also to change their BULL GCOS8 platform for UNIX platform, and finally they decided to convert their BULL GCOS8 platform for IBM Mainframe Platform for the legacies applications, besides UNIX platforms for news applications.)

Luca P. • During my 30 years in the IT I've been involved in a number of migrations of different kinds (even "TO" mainframe from GCOS as well as Pierre) and in different roles. What you need is essentially two things: connectivity for data migration and a reasonable technical choice for the target platforms. I suggest forgetting how the things are currently. Plan as you were starting up regardless what the source environment is.
About "How to make it" a migration is analogous in some way to a "major release". The good practices suggested by ITIL's Release Management can surely help.
Add some good project management and, of course, have the stakeholders onboard and the game is done.

Robert F. • Luca, I've been in it for 46 years. To me the biggest problem is still first getting the 'correct' version of the source code used to create the currently running production executable code (you might be surprised at how many installations connot find most of the correct code and the proper version - you have to do this first) and then have the people with the right skillset (at least the programming language and the right business knowledge) to extract the business rules that are built into the code. You can't trust the documentation (if it exists) 100% although if it is current it can help and you can't trust the comments in the code itself (again if there are comments and they are correct and contrary to what some people have said and think, COBOL and other higher level languages are NOT self documenting. This is at best a very time consuming and sometimes (most times?) very challanging task. Tehn you have to write the specifications for the new code for what ever language the new platform will need and then code and test (and I mean real testing with the user community - parallel testing with the identical data (making a copy of the data currently being used and porting it to the new platform is usually easier, but does sometimes present some problems (simple flat data files are generally fairly easy - relational database data is generally fairly easy, some other structures are potentially very difficult). It is extremely time and money intensive and to some degree it may be a moving start and a moving finish. Yes, it has been done. Sometimes it has been done almost 100% correctly. That 'almost' can put the company out of business.

Hemanshu W. • Way back before Y2K days , there was this company which because of DB2 cost wanted to go Oracle way , After doing work for 3/4 months , it abondoned effort , there was considerable problem to convert to Oracle , Date format being different , Procedure implementation being different , SQLCODE values being different and many more , any one changing over has to do considerable work /cost associated with to migrate off ansd on top of that uncertainty in performance for large database systems

Luca P. • Robert, I really trust you as I've found situations like the one that you describe even when the developers were still in. This is the reason why I think that one should concentrate on the data only and redesign everything about the processes. In general one of the most comon target platforms when a big company decides to leave the mainframe is SAP. In that case I suggest forgetting the old code. All that you need from cobol sources are Data Division and Working Storage section to understand what data has to be migrated. Don't waste time converting old programs. Setup the new environment and migrate gradually process by process. Avoid big bangs and go for phased approaches when possible.
In cases like GCOS-->Mainframe the alternative may consist in writing "code converters". This is how my team (I was one of the members actually) approached a migration of that kind: take the original sources and translate the GCOS into ANSI or even CICS. Same for JCL. We took 3 months from start to finish. It was 1987.

Robert F. • Luca, If there is a proper conversion program and it works properly that would be an ideal way to moave things off the mainframe and get setup on a different platform. The problem is that in all the years that I have been involved in attempts to migrate to different platforms from the mainfram (35 years and I have been in this business for 46 years). I have NEVER encountered a single program or set of programs which have successfully and correctly transferred all the code. I've been involved in dozens of migration attempts for different clients and as I said, the Total Success rate was zero. Yes, many if not most of the programs/systems I have seen claimed to be able to transfer 'everything' and most were successful on a portion of the code to be transferred, but not a single one was able to do wverything completely correctly. You are correct about the data. in almost all cases, that is the one item that can usually be transferred to other platforms correctly. I have done it manually and with products many times. The problem is that I have not seen a single program or system which can convert all data of all types (there are literally dozens of different 'database' structures in use on the mainframe from flat files (usually easily done) to VSAM files (often easily done, but there have been many problems) to database systems which are in two groups (relational databases create data in proprietary formats, but the data can usually be ported (there is a saying SQL is SQL) and while there are some differences, they can usually be handled. Other database systems are another story. Dome are doable within reasonable time and cost while others are almost as difficult as porting the business rules from some programs. It depends on a lot of different issues. It is almost never a 'slam dunk' situation.

Robert F. • Hemanshu, Conversion from DB2 to Oracle should be one of the easist to do, but you are correct. It is not also so. Oracle has implented some things which are outside the SQL standard as has IBM. They are all little tweaks which can be overcom, but do take some additional time. There may be one or two which make the transition from DB2 to Oracle impossible, but I have never heard of any of them, and I have been working with both products extensively since the early 80s for Oracle and the mid 80s for DB2. The data is usually more straightforward and easy to transfer. The programs using the SQL databased range from the moderate to the vey difficult to port.

Luca P. • Robert, I've never meant "all the code" It always require manual modifications. It's only that most of the modifications are always the same and can be automated by conversion at strings level. In my experience the use of REXX has been the key. Another example was a JCL migration from VSE to MVS in 1989.

Robert F. • Luca. that depends upon the company and its previous personnel. I do not agree that most of the modifications are always the same. That might be true in some companies, but I have been a consultant at more than a hundred over the years and I can guarantee that the 'style' at each is different. Yes, there are tools that can help, but you still have to find the 'correct' source code and verify it really IS the correct code. You still have to extract the business rules from that code because some of that code cannot be converted by any tool in existence. I have seen so many failures of the 'quick fix' that I know that it can't be done to even a sufficient degree to make a big difference let alone 100%. In some companies, perhaps it can, but they are the minority. There is so much undocumented and uncommented 'stream of concousness' code out there that it is impossible. Migrating JCL from VSE to MVS is not really that hard. There are enough similarities between the two operating systems that it is frequently fairly easy. You do have to be careful because there are a few 'gotchas', but not many. I have done it myself and shown others how to do it for a lot of JCL (tens of thousands of lines of JCL). We were even able to write programs to do some of it, but not all. Some had to be done manually. Do you think there are a lot of people out there who have enough experience and knowledge in both VSE and MVS to make it a slam dunk? I don't.

Luca P. • "Most of the modifications are always the same" is in terms of code (if what is compiled matches the source code). A READ command in GCOS cobol can always be translated into an EXEC CICS READ. You can decide to transform a COMP-8 field into one of the ANSI packed formats and you'll likely use the same format in all the programs. I'm not thinking to any semantic. That's why I say that you can make the 80 or 90% of the modifications automatic, but for the rest you have to work manually.

But the two examples, GCOS-->Mainframe and VSE-->MVS are not significant. VSE and MVS are not so different as well as the two COBOLs. What I really want to say is that with migrations from Mainframe to Distributed platforms (i.e. SAP) you can make them easier if you implement the new and migrate the data only. Forget the original code and it will become just question of data interfaces.

Jose Carlos de O. • I also was involved in a lot successfull migrations to and from SystemZ. I dont want to use the word MainFrame anymore because it do not reflects the new reality of SystemZ architeture. When we compare some single cost, IBM SystemZ solution is much more expansive. But, when considere all other invonved costs in many cases you will be surprised with the cost. The problem is that some new generation CEOs want to proof your concepts and makes your company agree that it migration will make the company reduces cust. The mathematic shows the number we want to show.

What I can say is. On ´90´s the successfull indices was very big. Today´s it indice is very low. We must take attention when working on it.

Hemanshu W. • The Problem with Any Application is Domain Knowledge & Functionality required by users , When Companies have very large applications , only handful of long time employees only understand the intracacies of these mainframe applications functions , dataflow and finding the dependency and impacts of any change is mind boggling and even more so to say that functionally migrated system is identical to the original one and when it comes to testing on Past datasets to match results on Billions of records , most IT professional have serious problems to match results and identify the reasons for differences , and only actual users that too experienced once can give the detailed and special areas to check for functionality test , it then becomes multi-year projects , with Backlog on applications development .. Companies need to focus on IT Applications and not on Hardwares/OS behind them.

Robert F. • Luca, You cannot f'forget the original code'. The original code may very well (usually does) have business rules that are vital (often 'critical') to the way the business runs and the way it operates. The business rule imbedded in code are very often the only place the business rule is available (no documentation and no commenting). Yes, many thing can be 'translated', but if you lose the business rules embeded in the existing code, you effectively change how the business operates and doing that can put the business out of business.

Luca P. • Deciding to implement SAP or just being conformant to SOx changes the way the business works. Rules are less eternal than program codes and a migration can be the opportunity to make some clean-up. What were best practices yesterday may be no longer "the best" today as the world changes and the business who wants to survive has to model itself on the real world. Then if a rule is embedded in the code it should be in the employees minds too and you can apply these rules to any new solution without having to decode the old algorhythms. The reason why I have mentioned the years of my two "old style migrations" is that today I wouldn't take the same approach.