Is there any crazy way to change Arrow? Maybe start taking reservations after a certain date ? Call it transition date. Could the opening page send any reservation request to either the old system or the new one ? Same when making a telephone reservation. Computer systems completely separate. For riders changing reservations across the transition date manual agent input will be required. Same for bonus points.
If only it was that simple.
In most 'working system' upgrades/replacements, what is typically done first is a very detailed, thorough examination of every program & system being replaced by someone very knowledgeable in the 'old' system design, hardware limitations that had to be dealt with, and so on. 'Catching' the subtleties such as data passed between concurrently running programs via absolute addresses are just some of the fun and games to deal with. And, of course, if there ever WAS any written documentation about the old programs, it's long gone or so woefully out of date it's useless. Hopefully, the assembler (or any other language) programmer had extensive documentary comments in their programs. Sometimes that's the best documentation. Other times, it's laboriously read through code, line after line, and determine what it's doing and how it relates to everything else. Of course, all that gets written down in case they unexpectedly drop dead. (I had a co-worker die in a car accident that took the group I was working in several months to figure out what he left behind, etc)
THEN that knowledgeable person, if not also knowledgeable in the new hardware/software environment, must essentially perform a Vulcan Mind Meld into the new system design person(s), then look over their shoulder to ensure that the same functionality and 'tricks' will exist in the new system.
THEN it comes time to design various data transfer methods to take the data from the old system to the new. One of the strangest data formats I encountered were files with 16-BIT dates (7 bits for 2 digit year (0-128), 4 bits for month (0-16) and 5 bits for day (0-32))! Data storage had to be absolutely minimized due to slow and low bits-per-inch tape drives as well as disk drives. I've seen 'screaming' fast IBM 7090s' wait in SECONDS while the single head of a multi-platter disk drive comes out of the platter, slowly moves up or down several platters, then extend the head into the platters and wait for the rotational delay to get some data. In later years, 'data cells' (strips of computer tape hanging from a wheel and being individually selected to be read, similar to a jukebox) on an IBM 360/75 system cause it to spend considerable time idling ('wait' light) despite having 8-10 jobs in the mix. The 'tighter' one could compact the data, the better. As a result, various data extract/conversion programs have to be designed and written to transfer the data from the old system to the new.
Perhaps the biggest data conversion I ever wrote was while at a 'Baby Bell'. I had to extract everything for each customer (in their semi-unique CRIS systems) in each billing cycle from the IMS 'hierarchical' database and populate the marketing DB/2 relational database that had several trillion rows of data on it. It also required data extraction programs on all the 'exchange' computers (switches) to identify their capabilities and the 'area code + prefix' (NPA/NNX) for various needs in the DB/2 data base. Oh...and it had to run on/link to/extract from roughly a dozen mainframe 'images' spread across 5 states! Needless to say, I spent countless hours with the chief CRIS programmer to learn the ins and outs of 'telephony', and then pick the brains of the DBA for the DB2 data base. Fortunately, the chief CRIS programmer and myself were part of the database design team, although not a part of the daily design discussions. It took well over a YEAR just to write and fully verify that data conversion! There's far, far more to 'Ma Bell' than POTS...Plain Old Telephone Service.
