Taking over a Ruby on Rails application from another supplier

You are changing the team that supports your Rails application. The outgoing supplier has offered to send the code, and the incoming team is ready to help. Customers still need to place orders, staff still need to work, and the application cannot simply pause while everyone gets acquainted.

The handover needs to establish whether the new team can operate the service, release a change and recover from a problem. Possession of a repository answers only part of that question.

This guide is for directors and technical leads planning that transition. It focuses on the transfer of responsibility; deciding whether to rebuild or improve the application is a separate assessment.

Start with the service people depend on

Before reviewing code quality, establish what the application does for the business. Walk through the important journeys with the people who use it: making a purchase, changing a booking, approving a record or preparing a report.

Ask what happens after the screen says a task has succeeded. An order may need to reach an ERP system. A payment may start a subscription. A report may depend on a background job that runs overnight. Those connections belong in the handover, even when another supplier operates them.

Record upcoming pressure points too: a peak trading period, a supplier contract ending or a scheduled product launch. They affect the order of work and the changes it is sensible to make during the transition.

Confirm account ownership as well as access

An invitation to a code repository does not necessarily give your business control of the service. Identify the owner and administrator of each important account, including who receives billing and recovery messages.

A useful inventory covers:

• Source repositories, deployment pipelines and the version currently running in production.
• Hosting, databases, file storage, background workers and scheduled tasks.
• Domains, DNS, certificates and the accounts used to renew them.
• Payment services, email delivery, external APIs and other integrations.
• Monitoring, error reports, backups and incident communications.
• Credentials and configuration, including who can grant, revoke and recover access.

For each item, record the business owner, operational contact and any transfer dependency. A service may sit in the outgoing supplier's shared account and need a separate migration. That is work to plan, rather than a box to mark complete because somebody has a password.

Use an agreed secure method for transferring access. Keep secrets out of ordinary handover documents and use individual accounts where possible. Arrange changes to shared credentials around verified replacement access so that removing the old team's access does not lock out the new one.

Show that the incoming team can release a change

Ask the outgoing team to demonstrate the existing release process. The incoming team should then reproduce the relevant steps in an appropriate non-production environment, with permission and without triggering real payments, emails or other live actions.

Confirm where configuration comes from, how database changes are applied and which checks run before release. Find out whether production contains fixes that have never been committed to the repository.

A release demonstration should include what happens when something goes wrong. Rolling back application code may not reverse a database migration or an action already sent to another system. Record those limits and agree how the team will recover from the kinds of changes it plans to make.

Do not combine the supplier transition with a major hosting move or rewrite by default. Each additional change introduces more things to verify. Sometimes a move is necessary, but its scope and acceptance criteria should be clear.

Ask for evidence that recovery works

“Backups are enabled” leaves important questions unanswered. What is backed up? Who can access it? What would be lost if the service had to be restored?

Ask for the last recovery test and what it demonstrated. If that evidence is missing, plan an authorised restore into an isolated environment, using appropriate controls for the data involved. Check that the application can use the restored data and files; the existence of a database export alone does not establish that the service can be recovered.

The business should agree what recovery outcome it needs. An internal reporting tool and a live ordering system may have very different tolerances for downtime and lost work. Record the current position and any gap, rather than presenting an untested target as a guarantee.

Connect tests and known issues with business risk

Run the existing automated checks and record the result. Ask which failures are already known and whether any important checks are disabled. Then compare the tests with the journeys the business identified at the start.

The official Rails testing guide describes tests at different levels, including browser-based system tests. For a handover, the practical question is which checks provide evidence about the behaviour your users rely on. A green result is useful, but it cannot demonstrate a journey that no test exercises.

Use support tickets and incident records to fill in the picture. Recurring payment failures, slow reports or manual data corrections may reveal more immediate priorities than a general code-quality score.

Also record Ruby, Rails and important dependency versions. Check the framework against the current Rails maintenance policy, and assess the other components separately. An unsupported component needs attention, but its presence alone does not tell you how large an upgrade will be or whether the application needs rebuilding.

A handover has to include the integrations

When we took over Serious Readers' Rails e-commerce application, the work included more than the storefront. The application connected to an ERP system and a payment gateway, with complex shipping and discount rules.

We addressed unreliable synchronisation with the ERP and repaired bugs and tests in the shipping logic before extending it. Those were specific needs of that application. The useful lesson for a handover is to follow the business process across its systems, rather than assess the Rails code in isolation.

Agree who responds during the transition

Choose a clear point at which responsibility transfers. Before that point, identify who receives alerts, investigates incidents and approves releases. If both suppliers are involved, establish one person who coordinates the response.

Agree the incoming team's support coverage explicitly. A handover does not automatically include continuous monitoring, out-of-hours response or support for every connected system. Unclear expectations are particularly awkward during the first incident.

If the outgoing team is unavailable, record what cannot be verified and use that uncertainty to set priorities. The first task may be recovering authorised access or establishing how the live application was deployed. A fixed completion date is difficult to defend before those dependencies are understood.

Use a short acceptance record

At the transfer point, directors should be able to understand what is ready and what remains uncertain. Keep a record with an owner and supporting evidence for each area:

1. The incoming team has the agreed access, and the business can administer or recover the critical accounts.
2. The deployed application and its dependencies have been identified.
3. The release process has been demonstrated, with recovery limits recorded.
4. Important user journeys, integrations and known incidents are documented.
5. Recovery evidence has been reviewed, with any untested areas assigned for follow-up.
6. Support contacts, coverage and the first priorities have been agreed.

A handover can still proceed with documented gaps where the business understands and accepts them. The record should make those gaps visible, with a plan for resolving them.

Plan the handover around your application

If you are considering a change of supplier, bring the current support arrangement, the reason for the move and any approaching deadlines to the first discussion. A short overview of the application and its integrations is enough to start.

We can discuss the transition through our Rails support and maintenance service, including what needs to be established before we propose the work. Once the service is understood, improvements and new Rails development can be planned against a clearer operational picture.