ROBATZ editorial · · 5 min read
Name the problem you are paying to solve
An old version, a slow page and a difficult release process are three different problems. Rewriting the application is one possible response, but it does not automatically solve all three. Start with the business impact: which customer journeys fail, which changes take too long and which dependencies are difficult to support? Describe the constraint before choosing a replacement stack.
A Rails upgrade addresses framework and dependency compatibility. A targeted redesign can improve a specific workflow. An architectural change may be warranted when the current boundaries prevent the product from evolving. These investments can be sequenced. Treating them as separate decisions often reveals useful improvements that do not depend on a complete rebuild.
Build a compact evidence pack
Inventory Ruby, Rails, key gems, background jobs, databases, integrations and deployment tooling. Check current support status against the official maintenance policy rather than relying on a version number remembered from an earlier project. Record which components are actively maintained and which ones the team has patched locally.
Then inspect the product behavior: authentication, payments, permissions, data exports and any workflow with financial or operational consequences. Identify the automated tests that protect those paths and the gaps that require attention. Include production errors and performance measurements. The assessment should explain where risk comes from, rather than merely produce a long list of outdated packages.
Prefer an upgrade when the product still fits
If the application serves the business and its main problems are dependency age or maintenance friction, an upgrade is a strong candidate. The official Rails guide recommends useful test coverage and incremental version changes, resolving deprecations along the way. It also recommends handling Ruby and Rails upgrades separately. Exact steps depend on the application's starting point and dependencies.
Plan around customer journeys, not only a successful bundle installation. An upgrade should include staging validation, background processing, external integrations and deployment behavior. Keep unrelated feature work limited during the riskiest changes. A clear release boundary makes it easier to identify what caused a regression and decide whether to proceed or roll back.
Require a specific case for a rewrite
A rewrite deserves consideration when a material product requirement cannot be met sensibly within the existing architecture, or when the cost of changing it is demonstrably worse than replacement. Ask for that case in concrete terms. Which capability is blocked? Which options were investigated? How will the replacement reduce the constraint rather than move it into a new codebase?
Include the work that a clean demonstration omits: historical data, permissions, edge cases, customer migration, integrations and operational tooling. Existing behavior may encode rules no longer documented elsewhere. Interview the people who handle exceptions. Their knowledge can be more important to replacement scope than the number of controllers or lines of code.
Compare migration paths, not just development estimates
Ask for at least two feasible paths, such as an incremental upgrade and a staged replacement of one bounded area. Compare time to the first useful result, transition complexity, data risk, support burden and the effect on the product roadmap. Mark assumptions explicitly. An estimate that depends on an undocumented integration should show that dependency.
For a staged replacement, define which system owns each record and how changes stay consistent during the transition. For an upgrade, define the release sequence and recovery point. In both cases, identify who approves the change and how customer support will recognize migration-related problems. The safest plan is specific about the transition, not merely the destination.
Buy a decision before buying the whole project
A useful modernization assessment should leave you with a prioritized risk list, a recommended path, alternatives, an initial delivery scope and an estimate with assumptions. It should also distinguish urgent support concerns from improvements that can wait. Request a small technical experiment when a critical dependency or migration behavior is uncertain.
Agree how you will judge the result: supported dependencies, reliable deployments, fewer production incidents or a specific product capability. Choose measures relevant to the original problem. A new stack is not itself a business outcome, and preserving the existing application is not an objective at any cost. The decision should make future delivery more dependable.
Apply this to your product
Explore our Ruby on Rails development service for scope, deliverables and the decisions to make before starting.