A HOW-TO GUIDE FOR UPGRADING FROM LEGACY SYSTEMS

Jul 31, 2020 // Matthew Wittemeier

Due to issues such as demands stemming from increasingly advanced technologies, the growing impact of increased vessel sizes and attendant container loads, a lack of physical space to store containers, and a desire to simplify complex IT landscapes, many terminals are looking to advance beyond legacy systems and streamline their processes. However, in our conservative industry, many roadblocks are standing in the way of meaningful progress when upgrading from legacy systems. These range from the practical IT challenges to the more human challenges that come.

In our Port Technology paper: Upgrading Legacy Systems in Ports and Terminals, we explore the roadblocks and challenges that are common in legacy-system-replacement projects and pull insights from several key global figures from across the industry that have all been condensed into the “how-to-guide” found below. If you’ve got the time, it is worth circling back to the complete paper to understand how we got to this step-by-step approach.

READ THE FULL PAPER UPGRADE LEGACY SYSTEMS IN PORTS AND TERMINALS

1. Assess the Smart Approach – There are multiple solutions to any problem, including investing in people, software, or hardware. What is the most promising mixture of these elements to improve profit and sustainability?
2. Align Stakeholder Expectations – Do all stakeholders have adequate expectations regarding tasks, costs, and duration of the project? Keep in mind the importance of people and that you’re fundamentally changing human mindsets in addition to the software and hardware systems.
3. Build Your Team – Bring together the right team of first, internal, and then external stakeholders. It is important to recognize that current and, once selected, future vendors have a role to play on the team. It is also possible that you may engage external consultants too. Finally, remember that end-users of the systems should form part of your team as they often have the most insight.
4. Give Yourself Lots of Time – Plan your upgrade long beforehand, determining what elements of a legacy system can be “partitioned” from the whole and judging which elements are functional/non-functional. It is more than likely that you will require external vendor support to get this planning right.
5. Outline Needed vs. Unneeded Functionality – Describe needed functionalities of your system in place and identify missing features for which you are using workarounds. Understand the functions you don’t require anymore – things change. It’s natural that your processes and requirements should change too. Pay special attention to processes that have evolved to enforce old procedures designed around your current legacy system. How would you revise these?
6. Evaluate the Market – Are there standard software systems available which suit your business and processes? Do you need specially customized software? Are there start-ups in the market that can address your challenges? If developing customized solutions is the right route, is an in-house production of the new system a possibility, or is an external vendor better positioned to handle development? When weighing costs of in-house vs. external development, don’t forget to factor in the costs of bringing developers up to speed on your industry.
7. Decide on Your Development Approach – When describing use cases, adapt traditional processes as well. Do you want the perfect system all at once (waterfall or off-the-shelf approach), or do you prefer an earlier, go-live, adding new features successively (agile development approach)? These are very different development/delivery approaches that both have pros and cons. List them out and weigh the benefits of both before you decide.
8. Interfaces and APIs – List all interfaces that are needed to interact with other third-party systems. How do they work now, and what adjustments need to be developed on the interface partner’s side? How can you get competitors to cooperate in a positive and sustainable way? Again, external stakeholders who are part of your team are more likely to work together towards your common end-goal.
9. Involve End-Users Early – Get end-users involved as early as possible and engage them as part of the transition team. Remember that many new software projects are hampered by training end-users on new software. This is especially true when you’re also implementing new processes. As such, allow ample time for training end-users.
10. Start Future-Proofing – Which new technologies will prove essential during the transition, and which should you be planning for in two, five, and ten years’ time? How might these impact your new system? Is it versatile enough to integrate unknown new technologies, or are you creating another “legacy system” scenario?
11. Know Your Roadmap – Usually, there are stakeholders who are more inclined to upgrade the system on a regular basis. Others prefer to avoid the uncertainty upgrades have historically caused. Utilize existing technologies to create a system’s upgrading roadmap and calculate different scenarios. Regardless of your vendor’s (if you went down this path) roadmap, develop your own list of features you see as being important in the short-, medium-, and long-terms and work with your vendor to realize them in your system.
12. Risk Mitigation is Your Best Friend – Spend significant time ironing out potential integration issues before upgrading takes place, and develop a risk mitigation strategy – as inevitably, things will go wrong. Can you manage such an enormous project on your own, or is it advisable to engage additional external assistance for project management?
13. Communication is Crucial – Implement a change management team. Keep the team informed, motivated, and up to date. Internal communication is the key to positive team collaboration, and ultimately, to the project’s success.
14. Test, Test, and Retest – Leverage simulation and/or emulation to test systems and allow plenty of time for lab testing.
15. Take it Slow – Avoid the “big bang” style and a speedy, much-heralded go-live. It can make for good PR when it works out, but it makes for worse PR when it doesn’t, and all too often, “go-lives” don’t” go right.” Make use of a passivated, parallel operation of new components during normal terminal operations prior to an actual go-live.
16. Go-live Isn’t the End – Congrats on go-live! But, remember, go-live is only the start of your new system’s lifespan. System support and maintenance is the next step to get working smoothly. There’s likely always going to be bugs, and an efficient support and maintenance strategy is crucial. In addition, many systems need “fine-tuning” in their first months of operation. Continue to meet with your team and end-users to figure out what you got right, and more importantly, what you didn’t. If a system doesn’t work as expected, end-users will find their own workarounds, and these workarounds are costly in terms of staff-hours and data quality. If you didn’t get some feature right, rework it – after all, you’ve now got a new system that is much easier to change.