LabArchives: Modernizing their app by growing the team that maintain it

The Situation

A trusted product, shaped over years of real scientific work

LabArchives is a leader in electronic lab notebook software, trusted by researchers and educators across the globe. Their platform had evolved steadily over many years, shaped by real scientific workflows and the needs of a growing user base.

That long history was a strength, but it also meant the application was carrying its age. The Rails app was running on version 3.2 LTS, which had served them well but was now far removed from the modern Rails ecosystem. While the system continued to function, maintaining and extending it required increasing effort. Performance limitations, security concerns, and reduced access to modern tooling were becoming harder to ignore.

Just as important, LabArchives already had an in-house development team deeply familiar with the product. Any path forward needed to respect both the existing codebase and the people responsible for it. This wasn’t about handing the app off. It was about preparing it for its next chapter.

The Challenge

Modernizing without losing context or confidence

Upgrading a Rails application of this size and age is never just a technical exercise. Over time, the system had accumulated custom business logic, long-standing dependencies, and decisions made under constraints that no longer existed. Untangling those layers required care, patience, and a deep understanding of how the software was actually used.

At the same time, LabArchives didn’t want their internal team sidelined while an outside group handled the most complex parts of the upgrade. They wanted their developers to be active participants throughout the process, gaining the knowledge and confidence needed to carry the system forward long after the upgrade was complete.

The challenge wasn’t simply to modernize the application. It was to do so in a way that preserved continuity, transferred understanding, and avoided the disruption that often comes with large-scale rewrites.

The Approach

Work side by side, then step back

We began with a comprehensive Rails upgrade assessment, but approached it as a collaborative effort rather than a one-way audit. Working closely with the LabArchives team, we reviewed the codebase in depth, identified risk areas, and discussed tradeoffs together. The goal was to create a clear, shared roadmap toward a modern Rails version, grounded in the realities of the existing system.

Once that plan was in place, our engineers embedded directly with the LabArchives development team. Rather than taking ownership of the upgrade, we worked side by side, pairing on complex tasks and walking through modern Rails patterns as they appeared in real code. Daily communication via Slack, frequent screen-sharing sessions, and regular check-ins helped keep momentum high while ensuring nothing felt opaque or rushed.

As expected, the process surfaced familiar challenges common to long-lived applications: outdated or unsupported gems, limited test coverage in critical areas, and legacy logic whose original context had faded over time. Instead of treating these as blockers, we treated them as opportunities to slow down just enough to share understanding before moving forward.

The Outcome

An upgrade in motion, with the team leading the way

By the end of the initial six-week engagement, the Rails upgrade was well underway. More importantly, the LabArchives team had begun taking the lead on the work themselves, navigating breaking changes, refactoring modules, and making informed decisions with growing confidence.

Seeing that momentum, LabArchives extended the engagement for another six weeks to reinforce patterns, address remaining complexities, and continue building internal ownership. Over time, our role naturally shifted. What began as a close collaboration evolved into a lighter-touch, on-call consulting relationship.

After the initial engagement, the LabArchives team continued the work independently, upgrading the application to Rails 5.2 on their own. That progress reinforced what we had already seen: the team had the confidence and context to keep moving forward.

As the platform continued to evolve, LabArchives later reached back out to work together again, this time through a monthly retainer focused on continued modernization. With the goal of reaching Rails 8 by the end of the year, the work remains a collaborative effort, steadily building on what’s already in motion.

The Second Act

Progress without starting over

This work was never about replacing a system that still delivered value. It was about helping LabArchives give their Rails application a second act, grounded in modern tooling, stronger internal confidence, and respect for the years of thoughtful work already inside the codebase.

By modernizing their platform through collaboration rather than handoff, LabArchives preserved what mattered while creating space for what comes next. Their developers gained the clarity and experience needed to continue evolving the system, and the application is better positioned to support researchers and educators well into the future.

Good software doesn’t need to be rewritten to stay relevant. Sometimes it just needs the right plan and the right partners to help it move forward.