Ruby on Rails and software upgrade services

Move an important upgrade off the backlog

A framework is reaching the end of support, a dependency has a security advisory or an integration requires a newer API. Your team needs to make the change while continuing to deliver the product roadmap.

We help scope and carry out upgrades to existing applications, including framework and language versions, dependencies and related integrations. We review the stack and the intended outcome first to confirm where we can help and what else the upgrade may affect.

This can be a defined engagement alongside your existing team. We agree responsibilities for the upgrade, release decisions and support afterwards, so you know who owns each part of the work.

Rails upgrades for an application already in use

A Ruby on Rails upgrade can affect gems, application behaviour, background jobs and the services connected to it. We review Ruby and Rails compatibility together, identify dependencies that need updating or replacing, and investigate deprecated behaviour before planning the sequence of changes.

For an older codebase, the work may need intermediate version steps and additional tests around important workflows. We agree the target version using the application’s requirements and current support information; a larger version number alone is not a delivery plan. The assessment identifies what is known, what still needs investigation and which changes belong in the upgrade scope.

This service covers the upgrade and its handover. Continuing ownership of maintenance, monitoring and new features can be agreed through Ruby on Rails support and maintenance.

Establish the upgrade path before estimating delivery

The gap between current and target versions is only part of the work. Test coverage, custom code, third-party libraries, hosting constraints and connected services all affect the approach.

An initial assessment can cover:

• the current versions, support deadlines and reason for the change;
• compatibility of dependencies, APIs and any proposed target versions;
• critical workflows, automated tests and areas needing additional checks;
• data or infrastructure changes needed alongside the application upgrade; and
• release constraints, access requirements and responsibilities across teams.

We use the findings to agree a sequence of work, estimates and acceptance criteria. Where uncertainty remains, we identify the investigation needed before committing to a delivery plan.

Test, release and hand over

1. Make the required changes: update the agreed components, resolve incompatibilities and review changes with the people maintaining the application.
2. Check the workflows that matter: combine automated tests with agreed QA and integration checks. Rehearse data changes where they form part of the scope.
3. Plan the production release: agree approvals, timing, backups, recovery options and post-release checks with your team. Any expected interruption is part of that plan.
4. Leave a maintainable system: document the versions and changes, known issues and follow-up work, and agree who supports the application after handover.

A version update may address known vulnerabilities or compatibility problems, but wider security and operational requirements still need their own assessment. Our technical assurance approach sets out how we agree those responsibilities.

Upgrade experience alongside an existing engineering team

For Easol, we upgraded its application from Rails 6.0 to 6.1 while its own developers focused on other roadmap features. We worked within the team’s delivery practices, joining stand-ups, sharing progress and transferring knowledge. The version change introduced image variant caching for more efficient image serving.

That is one example of a defined upgrade within a wider product programme. Your application may need a different path; we assess the existing platform before recommending a target or a migration.

A defined upgrade or ongoing maintenance?

Does an upgrade mean rebuilding the application?

Not necessarily. We assess whether the existing code and dependencies can be brought forward, and explain any parts that need substantial change. A recommendation to replace a component or rebuild should follow that evidence and the business constraint.

Can you guarantee an upgrade without downtime?

We establish the release constraints with your team. Database changes, integrations and infrastructure may require a planned interruption. The proposal should make those risks and recovery options clear; we do not assume every application can be upgraded without downtime.

What should we prepare for an estimate?

Current Ruby and Rails versions, key integrations, the deployment process, test coverage and any support deadline are useful starting points. Where those details are incomplete, an initial assessment can establish the scope before implementation is estimated.

If you need a particular upgrade delivered and handed back to your team, we can discuss a focused scope. If updates are repeatedly deferred or there is no clear maintenance owner, an ongoing support arrangement may be more appropriate.

Explore support and maintenance for ongoing ownership, or Ruby on Rails support and maintenance for a Rails application. For an initial upgrade conversation, share the current stack, the business reason for the change and any known deadline; a complete specification is not required.