Next add the practicalities – the task of ensuring that the new system is meets your specific needs, the risk of downtime, the need for training or re-training and, sometimes, the challenge of extricating oneself from a “sticky” system – and the whole task can seem pretty daunting.

But Andy Clason, Navis’ director, SPARCS N4 Serviceability, says: “Despite the risks of making a move from one TOS (terminal operating system) to another, quite often the risks of staying on the current TOS are greater. Some legacy systems run without any technical support. Sometimes they are forced to run on old software that is at risk of failing. Worst of all, failure to move ahead is similar to having an IT department that decides to stay on Windows 3.1 because it’s deemed ‘safe’. Over time, the safety of staying with the known is outweighed by the need to take advantage of new technology.”

Dave Quennell, program manager – logistics, at Jade Software Corporation, says it is easy to assume that replacing a TOS is a major exercise. “This view unfortunately leads to many terminals accepting and continuing to use substandard systems with poor functionality, little inter-operability and high maintenance and support overheads.

“For example, it always amazes me to discover how many traditional TOS vendors still require on-site visits for software upgrades at the customer’s (great) expense.

“The reality is that replacing a TOS can be done with little disruption and, importantly, open the door to significant longer-term cost savings and other strategic advantages.”

Understanding how users feel about their current system and willingness to support change is essential, says Mr Quennell. “There may well be some initial reluctance by end users to change, which can often be put down to a number of things; fear of the unknown, concern that years of use of a particular package will be ‘wasted’, and the feeling that ‘if it ain’t broke, don’t fix it’."

At Navis, Andy Clason says a TOS often has a high number of users, is mission-critical, meaning that the terminal can’t afford downtime or outages from the system, and is often heavily customised to the particular terminal in question.

“The user base can be resistant to change and, even if they aren’t, any change made may require re-training existing staff. The fact that terminal operations continue to be mission-critical means that a terminal’s tolerance for risk continues to go down. Any switch in system functionality presents this risk, and prompts a risk versus reward consideration for the terminal. If the cut-over from one TOS to another causes a four-hour outage, how much revenue will the terminal lose? What if the cut-over causes a four-day outage?”

In addition, he says, for terminals that have built their own legacy TOS, it may be that they have designed their system over time to meet a number of one-off, terminal-specific processes. Sometimes this can be a roadblock to moving to more standard software. “But even with these hurdles, many terminals eventually make the decision to move to a new, more standard TOS.”

The real difficulty in changing the TOS is related to change management, says Chuck Schneider, senior project manager at Navis. He says the sites that have difficulty start with an assumption that the new TOS will do everything that the old one did – and do it in a similar fashion. “This is not the case and it takes the support and buy-in from senior management to push their organisation to leverage the processes and best practices of the new TOS and not try to have the vendor make it work like their old TOS.”

Technically speaking, changing TOS is not that difficult, says Mr Schneider. It takes four key components. First, ownership – there must be a senior person from the client who takes ownership to make sure the migration is successful. This requires active involvement and strong change management skills. Second, a data migration plan is essential to get current data into the new TOS. Third, a well thought-out cut-over strategy is needed. The fourth component is participation from the TOS vendor – “i.e., don’t try this at home”.

The most important factor is to be clear about the overall goal of implementing the new system, says Andy Clason. “What does the terminal hope to achieve by changing the TOS? What will the new TOS provide that the old TOS can’t provide? How urgent is the need for change? Perhaps the terminal wants a more scalable system, or something that’s more user-friendly. Perhaps the terminal wants to centralise operations, and run multiple terminals from a single TOS. These basic goals should drive the rest of the project.”

Rather than trying to compare the functionality of the old TOS with the new TOS, it typically works better to match the operational needs of the terminal to the new TOS directly, he adds. “This allows the terminal to take the best advantage of the new software, rather than simply trying to match existing functionality.”