A legacy Rails fleet, containerized and upgraded

The engagement

William S. Hein & Co. publishes HeinOnline, one of the largest legal-research databases. The work wasn’t on HeinOnline itself, but on the cluster of internal back-office Rails apps that run Hein’s operations - TitlesDB, AccountsDB, and two smaller apps (LegHis and ToolsDB). They were old: Rails 3.2.12 on a Ruby 1.8/2.x-era stack, running on aging bare-metal hardware with hardcoded IP addresses scattered through the code. The client was explicit that they had little Ruby expertise in-house.

The engagement started in late 2023 with a paid code review, became a retainer, and ran through 2025 - 18+ months of sustained work.

What we did

• Containerized the legacy apps in Docker as the emergency first deliverable - got both TitlesDB and AccountsDB booting in Docker images over a weekend when Hein’s hardware was failing.
• Drove the Rails upgrade of the fleet from Rails 3.2.12 toward a modern Ruby 3.4 / Rails 8 stack - the merged “initial testing release” pull requests, then later upgrade branches modernizing form helpers and models to Rails 8 conventions, with nil-safety, CSV/export, and validation fixes.
• Removed hardcoded infrastructure - replaced scattered hardcoded IP addresses with environment variables for DB credentials, base URLs, search endpoints, and API tokens.
• Modernized the app server and logging - moved toward Unicorn, pinned gem versions to resolve Ruby-version incompatibilities, and chased down production logging and template/method errors surfaced during the upgrade.
• Set up monitoring - wired the apps into Sentry so production errors were triaged as they happened.

Stack

• Ruby on Rails (3.2.12 → Ruby 3.4 / Rails 8)
• MySQL
• Docker / Docker Compose
• Unicorn
• Sentry