Software and security upgrades for existing applications

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.

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?

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.