The industry can learn many lessons from Virginia’s successful migration of a terminal with an automated yard system from Navis SPARCS and Express to N4
Migrating a working terminal to N4, or any other TOS for that matter, is a tricky proposition, and when the migration does not go to plan, the results can be dramatic. This was evidenced last year, when the Port of Felixstowe suffered major disruption following its conversion to Hutchison’s nGen TOS, which caused a significant loss of business.
By contrast the Port of Virginia managed to successfully switch its Virginia International Gateway (VIG) terminal from Navis SPARCS and Express to Navis N4. It put all operations on hold for eight hours from 11pm on Friday 11 May 2018, migrated all the data to N4, and then opened for business at 7am on Saturday 12 May. No vessel calls were lost, and there were no truck lines and delays at the gate.
The successful conversion was the result of a two-year project managed by Rich Ceci, senior vice president of technology and projects at Virginia International Terminals. Ceci is well known in the industry, and was IT manager at VIG when it was developed and opened (as APM Terminals Virginia) in 2007. He also led Global Container Terminals’ successful conversion to N4 and an ASC system at GCT Bayonne.
Initially constructed by APM Terminals, VIG was the first terminal in the world to use what was then the Automated Stacking Crane (ASC) module in Navis SPARCS, together with the Navis Express database as its core ‘TOS’. The terminal also had a complete set of process automation systems to identify containers at the landside gate and in the ASC truck exchange area.
The IT environment was complex. When the terminal was opened in 2007, WorldCargo News reported that the terminal had knitted together 13 different inhouse applications and 12 other applications from nine different vendors.
Time for change
In 2016, when Ceci returned to Virginia, the terminal was still using the same technology, but the operating environment had changed. In 2016, Virginia Port Authority (VPA) entered into a long-term lease with VIG’s owners and, as a result, took over all operations at the terminal. The 40-year lease cleared the path for the VPA to expand VIG, while at the same time putting the finishing touches on a similar plan to convert Norfolk International Terminal (NIT) from a straddle carrier facility to the same ASC yard system as VIG.
Expanding VIG and converting NIT to ASCs is a massive project, requiring 60 new ASCs for NIT, 26 more for the VIG expansion, and four RMGs for the VIG rail yard. On the TOS side, the port wanted to have the same IT environment it VIG and NIT. It had been running N4 at the Richmond barge terminal since 2012, and at NIT since 2014.
From a TOS perspective, the least risky approach may have been to develop an area of NIT as an ASC yard with all the new systems first, bed the system in, and then convert the rest of NIT and VIG to the new software environment progressively, but this was not a viable option.
In an interview with WorldCargo News, Ceci explained that Virginia’s cargo volumes were growing, and it did not have the luxury of taking part of NIT offline, waiting for new equipment, and then debugging and bedding in a new TOS. The port needed to convert VIG to N4 without disrupting vessel schedules, and then be able to essentially ‘turn on’ a working TOS and integrated systems at the new ASC blocks at NIT as they are completed one by one, while the terminal kept operating.
Once it was decided to migrate the automation systems at VIG to N4, the project team went through each of the technologies at the terminal, one at a time. Some were upgraded, such as the Nascent gate system, to new generation products. One of the larger changes was from the initial TransCore passive RFID system for identifying road trucks to a new WhereNet active RFID technology, which required replacing all the truck tags in the port.
Importantly, all this work was completed and went live with the SPARCS Express TOS, and was then migrated from Express to N4. This meant all the integration, data access and sharing could be tested fully before go-live. The testing itself was extensive, with the migration team performing more than 280 tests of the full data migration from Express to N4. “Every container was evaluated to the greatest extent possible”, said Ceci, and by the end of the
process, the team knew exactlyhow many minutes the migration would take. “We practiced it so much that it was second nature,” he added.
It would have been possible to run all the terminals off the one instance of N4, which would have saved VPA around US$250,000 in server hardware costs. However, Ceci said that keeping the TOS separate for different terminals
running different levels of technology at different times reduced the risk of an issue at one facility impacting the whole port.
The terminal industry is still getting to grips with the real cost of IT systems for automated and complex terminals, and some operators might struggle to accept the cost of a TOS migration project. There is, however, enough evidence of the dramatic (and sometimes catastrophic) impact of poorly functioning IT systems on the operation.
Ceci said that, to some extent, “fear has provided relief” when it comes to putting pressure on budgets for complex IT systems, but setting the budget is still a challenge. He advises terminals to focus on the work to be completed and the schedule. “If you know how you are going to spend the money, then staying on schedule will take care of the budget,” he said.
This does not, however, mean that the schedule must drive the decision on when to go live. When Ceci came back to Virginia, the target date for the N4 migration was revised to October 2017. As that date approached, the project
was not progressing completely as planned, and approval of the port’s Board of Commissioners was sought and received to extend the timeline. Ceci was clear that if migration could not be completed before 1 December 2017, the project should be delayed until after the holiday season, which pushed the migration into 2018.
In early 2018, it became clear that February was unrealistic and the date was moved to May. Throughout 2018, the port’s volume growth continued, which, said Ceci, “just added more pressure to make sure we got it right”. At key points, a decision had to be made on whether the port was ready, and he stressed that, when making this assessment, it is vital to deal in facts only, and not allow judgement to be clouded by “optimism or pessimism” about
whether the project will succeed.
Part of making sure the decisions about when to go live are driven by a technical assessment, and not other considerations, is making sure that a TOS migration is viewed as a port-wide project right from the start. Ceci stressed
that the whole port, including management, needs to understand and buy into the difficulty of the project and the risks involved, and not believe that the project leader can somehow push through a project that is not ready.
Virginia pulled it off, and Ceci is proud of his team and Navis for the “flawless” result delivered when the transition was made. The only thing that surprised him on 12 May was the level of user support needed for terminal personnel using the TOS after golive. Everyone had been trained in the software, but there remains a period of adjustment when it comes time to put training into practice that is difficult to avoid. Ceci credited Navis and its “allstar team” for bridging this gap by putting enough resources at the terminal to help people put their training into practice and make the transition a success.