Engineering Note
A Rails upgrade from 5.2 to 8.0+ is not one upgrade. It's a chain of production decisions.
We had a Rails application that had been running for years.
The obvious approach was:
5.2 → 6 → 7 → 8
But the real challenge wasn't changing the Rails version.
It was everything around it.
Old gems.
Deprecated APIs.
Background jobs.
Authentication.
Database behaviour.
Deployment dependencies.
We didn't try to upgrade everything in one release.
Instead, we broke the work into smaller steps:
* Upgraded Ruby first
* Removed unused and outdated gems
* Fixed deprecations before the major upgrade
* Tested background jobs and critical flows separately
* Released each major version incrementally
* Monitored production after every step
The result?
The application moved from Rails 5.2 to Rails 8+ without a major production outage or a complete rewrite.
The biggest learning:
Framework upgrades are technical debt work, but they are also risk management.
The safest upgrade isn't the fastest one.
It's the one where every change is small enough to understand, test, and roll back.
The obvious approach was:
5.2 → 6 → 7 → 8
But the real challenge wasn't changing the Rails version.
It was everything around it.
Old gems.
Deprecated APIs.
Background jobs.
Authentication.
Database behaviour.
Deployment dependencies.
We didn't try to upgrade everything in one release.
Instead, we broke the work into smaller steps:
* Upgraded Ruby first
* Removed unused and outdated gems
* Fixed deprecations before the major upgrade
* Tested background jobs and critical flows separately
* Released each major version incrementally
* Monitored production after every step
The result?
The application moved from Rails 5.2 to Rails 8+ without a major production outage or a complete rewrite.
The biggest learning:
Framework upgrades are technical debt work, but they are also risk management.
The safest upgrade isn't the fastest one.
It's the one where every change is small enough to understand, test, and roll back.