The first 30 days of a Ruby on Rails takeover

The handover is complete. Access is transferred, the new team can deploy, and the outgoing supplier has answered their last question. It is tempting to treat this as the end of the transition. It is closer to the start of it.

We have taken over Rails applications from other agencies, from departed in-house developers and from teams that simply ran out of capacity — for clients including Serious Readers, Concordia and ReelLearning. The pattern that follows a successful handover is consistent enough to describe, and it fits into about 30 days. If you have just changed the team supporting your Rails application, this is what those weeks should look like.

Our companion guide covers the handover itself: taking over a Ruby on Rails application. This post picks up where that one ends.

Week 1: understand before changing anything

The first week is about earning the right to change things. A team that starts rewriting code in week one is guessing, and guessing is how inherited applications get worse.

Understand the application. Walk the journeys the business actually depends on — the checkout, the visa application, the daily report — with the people who use them. Every legacy codebase contains decisions that look wrong until you understand the constraint that produced them, so we read the code with questions, not judgement, and write down the system's shape: dependencies, background jobs, integrations, and the areas nobody should touch without tests.

Understand the team. Who on the client side owns the product, who answers operational questions, who signs off changes? The takeover is of a working relationship as much as a codebase.

Define the ways of working. Agree how requests flow, how priorities are set, how releases are approved and how everyone communicates — before the first urgent issue forces the question.

Week 2: make the first safe changes

Prove the pipeline. Verify the CI/CD pipeline is set up and working properly — or set it up where it is missing. A small fix released end to end validates everything: environments, tests, database migrations, rollback. A team that has not released within two weeks of takeover does not yet support your application in any meaningful sense.

Confirm access and visibility. Proper access to the services and tools the site uses — hosting, error tracking, email delivery, payment providers — with credentials rotated from the outgoing team. Install or repair error tracking, monitoring and performance analysis, so problems are seen by the team before they are reported by customers.

Tackle anything urgent. Outstanding security fixes and active issues come first, ahead of everything else on this list.

Weeks 3–4: plan ahead

With the application understood and the safety net in place, the focus shifts from stabilising to steering.

Analyse the larger release map. Where the application is behind on Rails, Ruby or key dependencies, agree the version path now — upgrades are cheaper and safer when planned rather than forced by an end-of-life deadline.

Prioritise what comes next. Review outstanding features and improvements with the client, prioritised by user need and business value, then begin designing and developing the work that matters most — deliberately small, deliberately reversible.

From day 30: ongoing support

After the first month, a takeover becomes a maintenance relationship rather than a project. Our support and maintenance packages work on a drawdown basis: depending on your needs, you draw down a set number of hours each month, which can go towards keeping the system healthy — security patches, dependency updates, monitoring — or towards improving it, delivering the prioritised features that help meet your users' needs and your own goals and ambitions for the software. Our experience is that steady, planned maintenance costs less and hurts less than periodic rescue work.

What good looks like at day 30: the application is monitored, patched and releasing regularly; urgent risks are dealt with; there is a prioritised plan for what happens next; and a named team answers when something breaks. Several of our client relationships have run for years on exactly this basis — our average is around five.

If you are planning a transition, or are partway through one that does not feel like this, our Ruby on Rails support and maintenance service covers takeover and continuing care. Talk to us about your application.