TL;DR: Key Takeaways
- Harbor Lookout evolved from a developer bench project into a public application serving approximately 8,000 users per day during peak tourist season.
- After roughly 15 years and contributions from more than 46 developers, maintaining the original architecture became increasingly difficult.
- RBA ultimately chose a ground-up rebuild rather than continuing to patch the legacy application.
- The modernization introduced a .NET and React architecture, PostgreSQL, stronger authentication, improved caching, and sophisticated real-time maritime mapping.
- One of the project’s biggest lessons had little to do with technology: discovery and client collaboration are critical because real-world processes rarely behave exactly as software expects.
- The resulting system demonstrates an important enterprise modernization principle: modern architecture matters, but understanding the people, processes, data, and exceptions surrounding an application matters just as much.
Somewhere along the Duluth waterfront, people are waiting for ships.
They may be standing near the Aerial Lift Bridge in Canal Park, watching from home through one of Duluth Harbor Cams’ live feeds, or checking their phones to see when the next freighter will arrive.
During the height of summer, thousands of them turn to Harbor Lookout.
The application tracks vessels moving through the Twin Ports, bringing together live ship locations, arrival and departure information, vessel details, maritime charts, images, cargo information, and alerts into one experience.
But Harbor Lookout wasn’t originally designed to become what it is today.
It began roughly 15 years ago as something much smaller: a project for developers at Duluth-based Saturn Systems, which RBA acquired years ago. The local Maritime Museum needed a better way to share ship information with a community fascinated by the enormous vessels moving through the harbor.
What started as an opportunity for developers to sharpen their skills eventually became a real application supporting a very real community.
And after more than a decade of imagining, it also became a surprisingly good example of what happens when software lives long enough to outgrow itself.
When Useful Software Becomes Legacy Software
Harbor Lookout’s longevity was part of the problem.
Over the years, more than 46 people contributed to its codebase. Features were added. Bugs were fixed. Requirements changed. New requests accumulated.
That’s not unusual for enterprise software.
Applications that successfully support a business for years rarely remain exactly as they were originally designed. They evolve alongside the organization. Eventually, decisions made years earlier begin colliding with requirements nobody anticipated at the time.
Technical debt accumulates gradually until seemingly simple changes aren’t simple anymore.
Nick Manor, part of the RBA team behind Harbor Lookout’s modernization, described maintaining the old application as increasingly feeling like “plugging holes in the dam.” Fixing one issue could expose another somewhere else.
Meanwhile, the Maritime Museum had accumulated a wish list of enhancements and fixes that the existing architecture made increasingly difficult to deliver.
Eventually, the team faced a decision familiar to many enterprise technology organizations:
How much longer do you keep repairing what you have before rebuilding becomes the better investment?
For Harbor Lookout, that point arrived approximately two years ago.
Instead of continuing to patch a system more than a decade old, the team decided to start over.
Rebuild the Foundation, Not the Experience
Starting over didn’t mean throwing away everything that worked.
The existing Harbor Lookout experience was familiar to its users. The goal wasn’t to redesign the application just because the underlying technology was changing.
Instead, RBA sought to preserve much of the recognizable experience while completely rethinking the underlying foundation.
The application was rebuilt primarily with .NET and React. Expensive proprietary database technology was replaced with PostgreSQL to help lower ongoing operating costs. Authentication was redesigned so administrators could use individual accounts rather than relying on the single shared administrator credential of the original system.
The new application was deployed to the cloud while remaining easy for developers to run locally for testing and debugging.
Performance also required a different approach.
Harbor Lookout’s mapping experience isn’t simply placing pins on a standard map. The application combines geographic information from OpenStreetMap with NOAA maritime charts showing shipping channels, channel markers, water depths, and other information needed to understand what is happening on the water.
Rendering that experience requires generating and serving roughly 80,000 individual map tiles across multiple zoom levels. Cloudflare caching was introduced to deliver that information efficiently.
Even the ships themselves changed.
Rather than representing vessels as simple dots, Harbor Lookout can display scaled outlines showing the vessel’s actual position and orientation.
That location comes from the physical world.
RBA hosts an Automatic Identification System (AIS) receiver antenna in Duluth that captures vessel information transmitted over the air. Harbor Lookout can use that data to display speed, latitude, longitude, heading, and movement through the harbor.
The result is a digital application deeply connected to a physical environment.
And that’s also where some of the hardest engineering problems began.
Software Models Are Clean. The Real World Isn’t.
To automate more of Harbor Lookout, the team needed to understand something deceptively complicated:
What exactly does a ship do?
From a software perspective, a vessel’s journey through the harbor can be modeled as a series of states:
Arriving. Arrived. Moored. Shifting. Departing. Departed.
Build the right logic around those states, combine it with live AIS telemetry, and much of the ship’s journey can be tracked automatically.
Except ships don’t always cooperate with the model.
A vessel might enter the harbor simply to refuel and then leave for another destination without ever appearing on the expected schedule.
Other vessels behave in ways the development team couldn’t anticipate until the system encountered them.
Nick described these as the “corner-of-the-box problems” that emerge when a carefully designed software model meets actual behavior.
It’s a maritime example of a much larger enterprise technology problem.
Organizations build applications around how a process is supposed to work. Customers, employees, equipment, data, and business conditions then introduce dozens of exceptions.
Those edge cases are often where modernization gets difficult.
Discovery Is an Engineering Requirement
For Nick, one of the biggest lessons from Harbor Lookout wasn’t about choosing a framework or database.
It was about discovery.
“Even after all these years, the hard part is not the lack of information up front; it’s building the discipline to surface the right questions early.”
A development team can make what appears to be a reasonable assumption about a process or data source, only to discover months later that the information doesn’t exist in the way everyone expected.
By then, the assumption may already be embedded in the architecture.
Correcting it becomes considerably more expensive.
That’s why discovery shouldn’t be treated as the short preliminary stage organizations have to complete before the “real” technical work begins.
It is part of the technical work.
Much of it depends on skills that aren’t particularly technical: asking the right questions, communicating across teams, challenging assumptions, and involving the people closest to the process early enough to identify what engineers can’t see from requirements alone.
Harbor Lookout provided plenty of examples.
One involved something as seemingly straightforward as telling someone when a ship would arrive.
Sometimes Better Software Gives a Less Precise Answer
The original Harbor Lookout displayed specific arrival times.
Technically, that made sense.
Practically, it created a problem.
Ships don’t operate according to a consumer application’s schedule. Weather, harbor conditions, operations, and other variables can change when a vessel arrives.
But when Harbor Lookout displayed an exact time, people treated it like a promise.
When a ship didn’t arrive at that time, visitors would walk into the Maritime Museum and complain to staff.
As Nick recalled, people would essentially ask, “How come that ship didn’t arrive when you said it was?”
The modernization gave the team an opportunity to rethink the experience.
Instead of making the arrival prediction more technically sophisticated, the team changed how it communicated arrival information.
It’s a small design decision with a larger lesson.
Accuracy and precision aren’t necessarily the same thing.
Sometimes providing an extremely precise answer creates a worse experience when the underlying environment can’t support that level of certainty.
Understanding that required more than looking at the application.
It required listening to the people using it.
Not Everything Should Be Automated
Harbor Lookout also exposes another increasingly relevant enterprise question: where should automation stop?
The application can determine a remarkable amount automatically.
Live AIS data can tell the system where a ship is, how quickly it’s moving, and which direction it’s heading. Harbor Lookout can use that information to estimate arrival times and move vessels through different operational states.
Users can opt into text alerts an hour before arrival, 30 minutes before arrival, and around arrivals and departures.
But telemetry can’t tell the whole story.
It may not reveal the specific cargo being carried or exactly where that cargo will be unloaded.
Some of that information still comes from people listening to marine radio traffic. Some comes from relationships Maritime Museum staff have built with sailors.
As Nick put it, “There’s a whole human story behind the fact that we can’t automate all of it.”
Rather than trying to eliminate that human component, Harbor Lookout augments it.
The technology handles what machines can reliably determine while creating a place where human knowledge can add the context technology can’t capture.
For enterprise organizations rapidly pursuing AI and automation, that distinction matters.
The objective shouldn’t automatically be removing humans from a process.
The better question is where technology can remove friction, where it can augment expertise, and where human context remains essential to producing the right outcome.
Modernization Is About Understanding What You’re Actually Rebuilding
Today, Harbor Lookout serves approximately 8,000 individual users per day during the peak tourist season from July 4 through Labor Day weekend.
Its audience includes a particularly passionate community of maritime enthusiasts, or, as they’re affectionately known around Duluth, “boat nerds.”
They can watch a vessel move across Harbor Lookout and then pull up a nearby Duluth Harbor Cam to see the same ship moving through the physical harbor.
They might be watching a modern freighter or a vessel like the Alpena, built in 1942 and still moving through the Great Lakes more than eight decades later.
It’s an unusually tangible software project.
But the modernization story behind it isn’t unusual at all.
Across enterprise organizations, applications built years or decades ago are still doing important work. They’ve accumulated features, technical debt, integrations, workarounds, user expectations, and institutional knowledge along the way.
Modernizing them requires more than replacing an old technology stack with a new one.
It requires understanding why the application evolved the way it did, how people actually use it, what assumptions have become embedded in it, where exceptions occur, and which parts of the existing experience are worth preserving.
The technology matters.
But Harbor Lookout’s story is a reminder that the hardest part of modernization may be understanding the real world the technology is supposed to serve.
Building What’s Next Without Losing What Matters
At RBA, application modernization combines strategy, experience, architecture, data, and engineering to help organizations move beyond aging technology without losing sight of the business processes and people those systems support.
Whether the challenge is mounting technical debt, an application that can no longer scale, expensive legacy infrastructure, or a platform that has simply outgrown its original architecture, the starting point isn’t automatically a new technology.
It’s understanding what needs to change and why.
Explore RBA’s application modernization and custom development services to build a modern foundation around the way your organization actually works.
