Computer Integration is Not an Issue to Dissuade Mergers

ATLANTA - from the September 2025 issue of Railway Track and Structures, Editor-in-Chief David Lester writes about computer integration after railroad mergers.

The proposed merger of Union Pacific and Norfolk Southern has brought about the usual wailing and moaning about service meltdowns that can occur when trying to integrate the computer systems of the two merging railroads. In addition, when CPKC integration of the Canadian Pacific and Kansas City Southern systems resulted in some difficulties and customer dissatisfaction (which I’m not minimizing), lots of analysts and observers said that the railroad had “stumbled” and this cast doubt on the approval of the proposed transcontinental railroad and any combinations that may occur in response. I’m sorry, but that’s simply a bucket of hogwash.

         Before I explain further, let me acknowledge that when the supply chain is disrupted by a rail merger, it results in incomplete communication, missed deliveries, lost shipments, increased dwell time, and other problems that reverberate throughout the system. This is a huge headache for everyone and it takes several weeks or months for recovery to occur. Many who read that last sentence will immediately say that “the merger meltdowns resulting from Union Pacific + Southern Pacific and the split of Conrail between Norfolk Southern and CSX took a lot longer than a few weeks or months to recover from –– indeed, it was several years before the disruptions and backlogs were completely cleared. And many of these disruptions are not due to computer system integration but other challenges of integrating to large and complex companies.

         It’s important to point out that the integration of computer systems of different companies during a merger or acquisition is not an easy task. Shippers may respond by saying “I don’t give a damn how complicated it is, I shouldn’t have to put up with it.” Well, yes and no. If shippers are going to benefit from mergers in terms of fewer interchanges, and in the case of a transcontinental mergers, single-line service from coast to coast, some pain will be incurred when merging railroads. And, if shippers benefit from reciprocal switching as a result of a transcon merger and seek other favorable terms, I question if the traditional worries like higher rates and poorer service will materialize. With only two major parties, the two transcons must compete on price and service. As far as service goes, real creativity in train operations can give one railroad an advantage – not an inherent advantage but one through more clever thinking. And, with only two railroads and reciprocal switching available, the two roads will, generally speaking, have a harder time competing on price. Of course, there may be some exceptions to this, but the situation should improve for most shippers.

         Now, back to computer systems. Remember the big service meltdowns in the 1990s? Those were thirty years ago and when you consider how much more sophisticated information technology is today compared to then, it makes sense that those old meltdowns shouldn’t even come to mind, at least as far as computer systems go.

One of the reasons that integration of computer systems is challenging, even today, is that there are few, if any, standards around what types of systems railroads must have. For example, my understanding that the problems CPKC had were due in large part to KCS having an older, less sophisticated, system than Canadian Pacific. I heard one story that said on KCS in recent times, the whole railroad had to shut down for an hour or two so that “the computer” could go through some type of reconciliation process without other changes coming in. Transactions should be completed and logged in real time, and not when the computer “can’t take anymore.” 

         Computer systems, even if you’re using the same hardware and software (which I don’t believe is the case with railroads), can be configured to accommodate different standards and workflow from road to road. So, even sophisticated and modern systems can have trouble integrating if these differences are not identified and planned for before the switch is flipped. The complexity of systems, though, makes this really challenging.

         There’s no doubt that meticulous planning on the part of IT departments and operations teams is absolutely necessary. This kind of planning takes a minimum of two years. This is the case with large, complex organizations in any industry. Take large hospitals and large hospital systems, for example. Planning for a new system to replace or integrate with parts of the old system takes, in most cases, a minimum of three years. Computer system salespeople may tell you differently, but they’re typically not around during implementation or go-live day. Moreover, no matter how well-planned a cutover is, something will always arise that wasn’t thought about during planning. It’s virtually impossible to have a newly live system perform exactly the way it did in a test environment.

         Railroads and shippers must prepare carefully for the integration of computer systems and perform as much testing as possible. Also, if there is any possibility of cushioning the supply chain with extra goods (yes, I know that’s costly) or making other adjustments to allow it to weather problems more effectively, they should be taken. Railroads must also communicate several times a day with shippers around problems that are occurring. Yet, as I said at the beginning, integrating computer systems should be the least concern around deciding to go forward with or approve a merger. Careful planning and execution will minimize or even eliminate issues.