Upgrade an old Rails app when its data model still matches how the business works, even if the code is messy, the tests are thin and the versions are years behind. Consider a rewrite only when the core model no longer fits the business, or the platform itself has to change, and even then replace it piece by piece rather than in one cutover. If you are unsure, the honest first step is a short audit, not a decision.
This guide is the decision: which situations point to an upgrade, which point to a rewrite, and the questions that settle it. For how a stepwise upgrade actually runs, see Upgrading an old Rails app without a rewrite.
Upgrade or rewrite: the short answer by situation
| Your situation | Likely answer |
|---|---|
| Several Rails or Ruby versions behind, but the app does what the business needs | Upgrade, one version at a time |
| Few or no tests, and every change feels risky | Upgrade, adding tests around critical paths first |
| Gems pinned or forked because upgrading one breaks three others | Upgrade, replacing abandoned gems as you go |
| The previous developer has left and nobody knows the code | Take over and audit first, then decide |
| One area, such as billing or an integration, is badly built but the rest is fine | Upgrade, and rebuild that one area |
| The core data model no longer matches how the business works | Consider a rewrite, replaced piece by piece |
| The business has to move off Rails for a reason outside the code | A planned replacement, with the old app kept running until each piece moves |
Messy code, old versions and missing tests are reasons to upgrade carefully, not reasons to rewrite. They are the normal state of an app that has been earning money for years.
Why a rewrite is usually the riskier choice
A rewrite throws away years of business logic. Every edge case the old app handles, including the ones nobody wrote down, has to be rediscovered and rebuilt before the new app can replace it. Meanwhile the business still needs new features, so the team either pauses them or builds them twice.
A stepwise upgrade keeps what works and modernizes the framework underneath it. Each step is small, tested and reversible, and the app keeps serving customers the whole time. Martin Fowler's description of the strangler fig approach makes the same point for replacements: change a system gradually and you deliver value earlier and learn as you go.
When a rewrite is the honest answer
- The data model no longer fits the business, and every new feature fights it.
- The product has changed so much that most of the old app is no longer used.
- The platform itself has to change for a reason outside the code.
Even then, a rewrite rarely needs to be a single cutover. Replace one area at a time behind the existing app, move users over as each piece is ready, and switch the old part off only when the new one has proved itself.
Seven questions that settle it
- Does the data model still describe how the business works today?
- Which flows make money, and are any of them covered by tests?
- How many Rails and Ruby versions behind is the app, and are those versions still supported?
- Which gems are abandoned, pinned or forked?
- Is the problem the whole app, or one or two areas?
- Can the business pause new features for the length of a rewrite?
- Who will own the app after the work is done?
If the answer to the first question is yes, an upgrade is almost always the better path. If the answers to the second and third are "none" and "many", start with tests and a version audit, not a rewrite.
Not sure which side your app falls on? Bring the Rails and Ruby versions and a short description of how it is deployed to a Systems Discovery Call. We will tell you whether it needs an upgrade, a partial rebuild, or something else.
What to ask anyone who proposes a rewrite
- What, specifically, in the current data model does not fit the business?
- How will existing behavior, including undocumented edge cases, be found and kept?
- What happens to feature work while the rewrite is underway?
- When does the first part of the new system go live, and can it run alongside the old one?
- Why would an upgrade plus rebuilding one or two areas not solve the same problem?
A good answer names real limits in the current app. A weak answer talks about old versions, messy code or missing tests, which an upgrade handles.
How we approach it
We read the code before recommending anything. A written assessment covers the current Rails and Ruby versions, gem dependencies, deprecations and the riskiest areas, then we agree on the upgrade order and what to test first. Each version step ships as a small, tested increment while the app stays live, and the same team keeps the app current afterwards so the next upgrade is routine. Zentap, a Rails platform serving 20,000+ real estate agents, is one we work on long-term. Details are on our Rails upgrade page. If the previous developer has left, start with our Rails app takeover page, and if the app is already failing, see Rails rescue: signs your app needs one.
Common questions
Is it cheaper to rewrite an old Rails app than to upgrade it?
Rarely. A rewrite has to rebuild everything the app already does before it can replace it, while an upgrade keeps that work and changes the framework underneath. The cost of an upgrade depends on how far behind the app is, its tests, its gems and how easy it is to deploy small changes.
Can we upgrade first and rewrite parts later?
Yes, and it is often the best order. An upgraded, tested app is much easier to change, so rebuilding one area later is smaller and safer than a full rewrite now.
What if the app has no tests at all?
Start with a small set of high-level tests on the flows the business cannot afford to break, such as sign-up, checkout and billing. That is normal for older apps and should not push you toward a rewrite.
How do we keep it from falling behind again?
Schedule upgrades against the Rails and Ruby support dates and give one team ownership of the platform. Our Ruby on Rails maintenance and support page covers what that looks like.
Next step
If someone has proposed a rewrite and you are not sure it is justified, book a Systems Discovery Call. It is 45 minutes on your application, its versions, and what the business depends on. You leave with a clear view of the upgrade path and what to do first, whether you hire us or not.
Farooq Ch
Nov 2026