Technology

Ruby on Rails Support, Upgrades & Modernisation
one version at a time, with tests that show nothing broke.

For businesses whose Ruby on Rails application has fallen versions behind, often to Rails 3, 4 or 5, and whose developer has moved on. We take over the code, keep it supported, upgrade Rails and Ruby in steps, and say plainly when a rebuild is the better answer.

More about this service

We are an Australian team working remotely with businesses in the United States, the United Kingdom, New Zealand and Australia. Every engagement starts with a scoped technical assessment, so the estimate that follows is based on your code and your data.

  • Assessment A scoped technical review before any estimate
  • 18+ yrs Building business software
  • Independent No licence commission, no reseller agenda
  • US UK NZ AU Australian team, working remotely
Australian owned and operated

Built here. Your data stays here.

  • No offshore development. Everything is written by our own team in Australia. Nothing is subcontracted overseas.
  • Your data stays onshore. Hosted in Australia, on infrastructure you own, under Australian law.
  • Every state, not just ours. Perth, Melbourne, Sydney, Brisbane, Adelaide and everywhere between.
Ruby on Rails developers

Built quickly, worked well, and never upgraded

Rails let a small team build a real business application in months, which is why so many booking systems, marketplaces, customer portals and internal tools were built with it. Many were written by an agency or a single developer, launched, and then left on the version they started on.

Read more

Rails moves quickly. Each release series gets security fixes for two years, so an application on Rails 3, 4 or 5 has been without them for a long time, and so has the Ruby underneath it. The obstacles are practical: add-on libraries, called gems, that were abandoned, few or no automated tests, and a hosting setup only the original developer understood. Each has a known answer.

Our Ruby on Rails developer service is for businesses in Perth, Melbourne, Sydney and Brisbane. It covers three kinds of work: code fixes and updates, migration to a modern technology stack, and ongoing maintenance and support.

Three ways forward for a Rails application

Most applications need the first, then the second.

  • Keep it and support it

    The application stays on its current Rails for now. We take over the code, get it running on our machines as it runs live, fix faults, make changes and close the security holes that can be closed without an upgrade. This buys time. It does not bring back security fixes.

  • Upgrade Rails and Ruby in steps

    The same application is brought forward one release at a time, which is how the Rails project itself says to do it. Tests are written first, gems are updated or replaced along the way, and each step goes live before the next begins. It ends on a Rails that still gets security fixes.

  • Replace it in stages

    Where the code has been patched beyond repair, or the business has outgrown what the application was designed to do, sections are rebuilt as a modern application one at a time against the same database.

What we do with Rails applications

Six kinds of work. Most engagements are two or three of them.

  • Rails maintenance

    Faults fixed and changes made in existing models, controllers, views and background jobs, including code somebody else wrote.

  • Gem audit

    Every gem in the Gemfile listed, with whether it is still maintained, has a successor, or blocks the next Rails version.

  • Rails and Ruby upgrades

    The application moved up one Rails release at a time, with Ruby upgraded separately, until both are on supported versions.

  • Test coverage

    Automated tests written around the work the business relies on, so each upgrade step can be checked before it goes live.

  • Hosting and deployment

    The application moved off a server or hosting plan that cannot run a current Ruby, with a repeatable way to release new code.

  • Staged replacement

    Sections rebuilt one at a time against the same database, where the design no longer fits the business.

Supporting it, upgrading it and rebuilding it are different projects

Each trades cost against how long the result will last.

  • Stay on the old Rails

    Lowest cost, and a holding position only. The application is understood and looked after, but its Rails and Ruby get no security fixes. Acceptable for a while for an internal tool behind a login. Not for anything that takes payments or holds personal details.

  • Upgrade to a supported Rails

    Almost all the code is kept, and staff see the same screens. The application ends up on versions that receive security fixes. The cost depends on how many releases behind it is and how many gems have to be replaced. After that, staying current is routine work.

  • Rebuild it

    Right when the design is the problem, not the version. It takes longest and carries the most risk, because every rule in the old code has to be found again. A rebuild can still be in Rails. The framework was rarely what went wrong.

What a Rails assessment looks at

Rails the framework is current. The risk is in the version gap, the gems and the tests. The version and support facts are from the Rails and Ruby projects.

  • Which Rails version

    The Gemfile.lock file in the code records it. Rails 8.1 is the current series, with security fixes listed until 10 October 2027. Rails 8.0 was listed until 7 November 2026. Rails 7.2 and everything older is out of support. The gap is the size of the upgrade.

  • Which Ruby version

    Rails 8 needs Ruby 3.2 or newer. Ruby 4.0 and 3.4 are in normal maintenance, 3.3 gets security fixes only, and 3.2 reached the end of its life on 1 April 2026. Every Ruby 2 version is long past it. Ruby and Rails are upgraded separately.

  • The source and its history

    Whether the code is in a repository you control, such as a GitHub account in your name, or only on the live server or in an agency account. Also whether what is in the repository matches what is running, which is not always the case.

  • Gems

    Every add-on library in the Gemfile. Some were abandoned years ago. Paperclip, once the usual gem for file uploads, is deprecated in favour of the Active Storage feature built into Rails. A gem with no version for the next Rails stops the upgrade until it is replaced.

  • Changes between versions

    Each release removed things old code relies on. Rails 4 changed how form input is accepted. Rails 7 requires a new way of loading code. Webpacker, the JavaScript tool older Rails versions installed by default, has been retired. The assessment lists which of these apply to you.

  • Tests

    Whether automated tests exist and whether they still pass. The Rails upgrade guide says good test coverage comes before an upgrade. Where there is none, tests around the important work are written first.

  • The database and background jobs

    PostgreSQL or MySQL and its version, plus the jobs that run in the background or on a timer through tools such as Sidekiq, Resque or Delayed Job: emails, imports, invoices and reports. They are the part most often forgotten in an upgrade.

  • Hosting, integrations and security

    Where it runs, whether that is Heroku, a cloud service or a single server, and how new code reaches it. Also the payment, email and accounting services it calls, and how logins and passwords are handled. Old integrations often use methods the other side has since switched off.

A Rails application years behind, and the developer who built it gone?

Call 0425 531 127 or Request a Rails assessment

What the assessment needs from you

A fixed-scope piece of work with a written result: the options, the risks of each, and a staged estimate. No production data is sent by email. We agree a secure way to share it first.

  • Versions

    The Rails and Ruby versions if known. The Gemfile.lock file in the code records the Rails one.

  • The code

    Where the code is kept, who owns that account, and whether it matches what is live.

  • Gems

    Any paid or private gems, and the logins or licence keys they need.

  • Hosting

    Where it runs, who has the logins, and how a new version is released today.

  • The database

    PostgreSQL, MySQL or another, its size, and how it is backed up.

  • Tests

    Whether automated tests exist, and whether anybody has run them recently.

  • Integrations

    Payment, email, accounting and other services the application talks to.

  • What is hurting

    The two or three problems that started the conversation.

  • The way back

    How long the business can run on the old system if a cutover has to be reversed.

How it runs

From assessment to a supported application

Done remotely, with meeting times agreed to suit your time zone.

  1. Technical assessment

    We read the code, establish the Rails and Ruby versions, check every gem and the hosting, and look for security faults. You get written findings and options, with the risks of each and a staged estimate.

  2. Take it over

    The code is put in a repository you own and made to run on a copy that matches the live application. Until that works, no change is safe.

  3. Tests first

    Automated tests are written around the work the business relies on, and urgent security faults are fixed on the current version.

  4. Staged upgrades

    Rails goes up one release at a time and Ruby separately, each stage with its own scope and estimate. The warnings each version gives are cleared before the next, and each stage goes live on its own.

  5. Comparison and user testing

    Each stage is run on a copy of live data, and your staff test the work they do every day.

  6. Cutover and support

    Each release is planned with a way back. We watch the first days of live use, then keep the application on supported versions so it does not fall behind again.

What people ask us about Rails

Is Ruby on Rails still supported?

Yes. Rails is actively developed, and Rails 8.1 is the current series. What is not supported is old Rails. The Rails project gives each series security fixes for two years, so Rails 7.2 and everything before it, including Rails 3, 4, 5 and 6, no longer receives them.

Can we go straight from Rails 4 to the latest version?

Not safely. The Rails upgrade guide says to move one minor version at a time, so that the warnings each version gives can be dealt with before the next. In practice that means a series of small releases, each one tested, and not one large jump.

Our application works. Why upgrade?

Because of what is underneath it. An old Rails and an old Ruby receive no security fixes, hosting companies retire the old versions, and the services your application connects to keep changing. The longer the gap, the larger the eventual upgrade.

Should we upgrade or rebuild?

Upgrade, in most cases. The application already holds years of business rules that work. A rebuild is right when the design no longer fits the business, or the code has been patched until nobody can follow it. The assessment says which, with reasons.

We have no automated tests. Is that a problem?

It is common, and it is the first thing we fix. Without tests, every upgrade step is a guess. We write tests around the work the business relies on, such as taking an order or raising an invoice, so each step can be checked. They stay useful long afterwards.

Do you take on code written by somebody else?

Yes. That is the normal case. A Rails application that needs this work was usually written by an agency or a developer who can no longer be reached. Rails applications follow strong conventions, which makes an unfamiliar one easier to read than most.

Do you provide Ruby on Rails developers in Perth, Sydney, Melbourne and Brisbane?

Yes. We are an Australian team and we take on Ruby on Rails work for businesses in Perth, Sydney, Melbourne and Brisbane, and elsewhere in Australia. Most of the work is done remotely, by video call and screen share, with secure access to a copy of your system. The service is the same in every city: code fixes and updates, migration to a modern technology stack, and ongoing maintenance and support.

How does this work from the United States, the United Kingdom or New Zealand?

Remotely. We are based in Australia and do not have offices elsewhere. Discovery is done by video call and screen share, with meeting times agreed to suit your time zone. Confidentiality, who can reach your systems and where your data is held are agreed in writing before work starts.

What does it cost?

The assessment is a fixed-scope piece of work with an agreed fee. The estimate for anything after it comes from what the assessment finds, in stages, so you are not asked to commit to a whole project on a guess.

Tell us about your Rails application

What the application does, the Rails and Ruby versions if known, where it is hosted, and what is forcing the question. Include your country so we can suggest meeting times. Please do not send production data.

Prefer a quick chat? Call 0425 531 127. We answer the phone in Perth.

Kasun Wijayamanna, founder of HELLO PEOPLE

Kasun Wijayamanna, founderYou deal with Kasun from scope to delivery. No account managers and no offshore handoff.