When upgrading from Rails 3.0 to 3.1, one of the common issues we face is the breaking change in ERB syntax for helper methods. This change impacts form_tag, form_for, content_tag, javascript_tag, fields_for, and field_set_tag.

The main issue is that these helper methods in Rails 3.1 now require the use of <%= %> to output content, whereas in Rails 3.0 (and earlier), they used <% %> without needing to explicitly output the form content. This change is not backward-compatible, and applying it across a large codebase can be quite tedious when we are using our method of dual booting an application to do an upgrade.

In this article we will explore a few possibilities we have uncovered in the past few years while doing these upgrades.

Ruby on Rails has a new maintenance policy and it can be a bit confusing as to what it means for both new and existing Rails projects. In this blog, we are going to summarize all the details, changes and important dates to help your team plan your next upgrade.

Let’s take a look!

While working with a client, we noticed that they had two Gemfiles: one with gems specifically for development and local references to a gem, and the other with a reference to a resource on GitHub. They wanted to switch between the local installation of the gem and the external GitHub reference based on whether they were in development or production. This approach worked well for their needs; however, our team was concerned that one downside was the difficulty in maintaining two separate Gemfiles. In this article, we will discuss an approach to creating conditional Gemfiles for development.

This article is part of our Upgrade Rails series. To see more of them, click here.

This article will cover the most important aspects that you need to know to get your Ruby on Rails application from version 7.1 to version 7.2.

Did you know that we love using the Dual-Boot technique for our Rails upgrades? We rely on the next_rails gem to help us with dual-booting our Rails applications. This gem does more than just enable dual-booting; it also helps us identify outdated gems, check Rails compatibility, find the minimum compatible Ruby version for a target Rails version, and more.

Sounds interesting? Keep reading to learn more about the features of the next_rails gem.

This guide is for you if you have an internal gem and you don’t know if you need to upgrade it or don’t know what steps to take to upgrade it. We’ll cover everything you need to know in this post about upgrading internal gems.

Ruby on Rails is a powerful web application framework that has evolved over the years, with new versions bringing in features, improvements, and security updates. As your application matures, keeping it up-to-date with the latest Rails version becomes crucial. However, the prospect of upgrading an entire Rails application can be daunting. In this blog post, we’ll explore whether it’s possible to upgrade your Rails application in increments and how to go about it.

Rails progression emphasizes simplicity and productivity. Through versions, Rails integrated tools, enhanced performance, and adapted to industry standards, keeping a focus on developer happiness and efficiency. ActiveModel::Error is an example of that. On this blog post, we’ll dive into the evolution of this object.

As we mentioned many times, at FastRuby.io we like to use the Dual-Boot technique during upgrades to quickly test the same code with the current and the next version of what we are upgrading. We usually talk about dual-booting Rails versions but this can be used to upgrade Ruby itself too. We have to make some changes to adapt the technique, and we’ll explain the basic changes in this article.

Starting in Rails 7.1, Docker files are added by default in new applications, but Docker has been popular for Rails development for many years before that. At FastRuby.io, we use the Dual-Boot technique when we work on upgrades, and using that approach when an application uses Docker requires some extra steps to keep a great development experience.

Maintaining an up-to-date Ruby on Rails application is crucial for performance, security, and feature enhancements. However, finding the time for a full-scale upgrade can be challenging. In this blog post, we’ll explore practical steps you can take to delay a Rails upgrade when you don’t have the immediate bandwidth but want to set the stage for a seamless process in the future.

Every year, Ruby enthusiasts anticipate the December release of a new Ruby version. At the end of 2023, Ruby 3.3 was released and you can read this article to learn more about the new features and improvements it brings. This makes it a good time to start considering if your application is due for an upgrade.

Upgrading your application can sound complicated and difficult, but it doesn’t have to be. Below, we will discuss how to identify when to upgrade your Ruby version and the steps necessary to complete a smooth and successful upgrade.

One of our biggest goals as a company is to aim for transparency and honesty when evaluating a project for an upgrade. We understand that the decision to hire an outside vendor versus doing it in house becomes a difficult one. To provide confidence and a clear path to completing an upgrade, before we even begin a project we invest time in doing a thorough investigation of the project to provide the most accurate and detailed game plan for an upgrade.

In this blog, we are going to break down our Roadmap service and explain how it can be used to guide you and your team to making decisions when it comes to upgrading your application.

You just finished upgrading your app to the latest Rails version and you made the decision to never stay behind and always be ready to upgrade as soon as possible… But how can you do that?

In this article we’ll explain how the Dual-Boot technique can be used to test the app against Rails’ main branch, to catch problems and warnings before a new version is released.

If you are upgrading a Rails application, you may come across the configuration of load_defaults in the config/application.rb file.

In this article, we will learn more about what to do with this configuration when working on a Rails upgrade.

In the first article of this series, we discussed How Much Does It Cost to Upgrade Rails based on our historical data working on over 100 upgrade projects. In this article we’ll discuss how to minimize the cost once you’ve decided to move forward on an upgrade so your team can continue to focus on valuable product feature or roadmap work.

Working with our team of experts to upgrade your Rails application allows you to stay compliant and take advantage of the benefits and security updates of a supported version, while also letting your team focus on revenue-generating initiatives. Still, it can be a significant investment, especially, as we covered in the previous post, if your project requires a high level of manual QA, for example.

There are, however, ways to reduce the time (and therefore cost) it takes to upgrade your Rails application when working with an external team. In this article, we’ll cover a few different strategies. Does it mean you can’t upgrade unless you do all of this? No, it doesn’t. Being an Agile team allows us to adapt to your process and workflow and work with any team to get the upgrade done. However, employing at least one of these strategies can make your upgrade more cost-effective.

Upgrading a legacy Rails application often presents challenges, especially when migrating from Rails 4 to 5.

One significant evolution lies within the ActionController::Parameters class, Rails 5 removes the Hash inheritance which breaks application behavior. If you want to be prepared for that, keep reading this post.

You’ve decided you need to prioritize upgrading Rails. Maybe it’s a compliance issue, you’re running a version that has reached EOL and need to upgrade to a more current one. Maybe you want to benefit from some of the new features more recent versions provide. Maybe you’ve noticed the old Rails version is getting in the way of your team’s productivity. Or maybe it’s something else.

Whatever the motivation may be, upgrading Rails can be a significant effort. As such, one of the key things to consider is how expensive will it be to get you from your current version to your target version. Regardless of whether you plan to handle the upgrade in house or outsource, how long it’ll take and, therefore, how much it’ll cost, are the key questions to answer.

We have invested more than 30,000 hours in total in upgrading Rails applications, having completed more than 100 upgrade projects. In this article, we’ll leverage our historical data and what we learned to help you answer this question: How much will this cost?

In this blog post, I detail my journey upgrading a client’s Ruby from version 2.7 to 3.0. While some of the approaches I took may be tailored to their specific needs and might not directly apply to your situation, they offer insights into one possible path for upgrading Ruby, particularly in scenarios with limited test coverage.

This article is part of our Upgrade Rails series. To see more of them, click here.

This article will cover the most important aspects that you need to know to get your Ruby on Rails application from version 7.0 to version 7.1.

When working on upgrades, we use the Dual-Boot technique so we can gradually update the app to work with the current version and the next one.

Eventually, the upgrade is done and the app is ready to drop the old version, but how do we handle that process? What are the steps between one upgrade and the next?

If you have ever upgraded Rails from 5.2 to 6.0, you might have run into issues with changes that had been made to the value of ActionDispatch::Response#content_type between the two versions.

If you have been lucky, you might not have even noticed there was a problem until Rails 6.0, after coming across this deprecation message:

Rails 6.1 will return Content-Type header without modification. If you want just the MIME type, please use `#media_type` instead.

What happened with ActionDispatch::Response#content_type between Rails 5.2 to 6.1? In this article, we will go into some background to learn what this method does, look at the differences in ActionDispatch::Response#content_type’s return value between the several Rails versions, and how you can fix the problem if you come across it in your codebase.

When you upgrade a Rails application from Rails 6.1 to 7.0, you may suddenly see a lot of changes in the schema.rb file and wonder where those changes come from and how to deal with them.

In this post, we look at what those changes are, and how to deal with them when upgrading a Rails application.

At FastRuby.io, we don’t always run rails app:update in our process to upgrade Rails apps.

It might seem like a sacrilege - after all, that’s why the task was created, to make upgrading Rails as painless as possible, right? But we have found while upgrading dozens of applications that running rails app:update isn’t the best idea in all situations.

In this article, you will learn what rails app:update does, when it should not be used, and how to upgrade your Rails app without it.

Note: In Rails versions before 5.0, rails app:update was called rake rails:update.

If you are using the i18n gem with Ruby 3.0 or are planning to upgrade Ruby to 3.0 while using the i18n gem, this blog post will cover a gotcha that can be tricky to understand.

Are you considering an upgrade for your Rails or Ruby application, but you’re concerned about low test coverage? Don’t worry! In this post, we’ll explore effective strategies to address the risks associated with low test coverage. By implementing these strategies, you’ll be able to upgrade your application with confidence. Let’s dive in!

Imagine having the ability to deploy the next version of Rails in a dual booted application on your Heroku staging server or review app before deploying it to production. This capability can help you avoid bugs and downtime in your live environment. In this blog post, we will guide you on how to deploy a Rails upgrade to a staging environment, allowing you to thoroughly test it before it goes live.

You are upgrading a Rails application. You finished fixing a deprecation warning and it’s not present anymore. You continue working on other tasks and one day you find out the deprecation is back in the codebase. New code was added using the deprecated behavior, but it was not detected and now it needs to be fixed again…

How can you prevent that from happening and, at the same time, let the team know?

Upgrading from Ruby 2 to Ruby 3 can be a challenging task, especially when your Rails application relies on ActiveJob with Sidekiq. In the process, you may encounter cryptic ArgumentError exceptions that make the upgrade seem daunting. By following along you’ll be well-equipped to avoid some of the hurdles that come your way.

After upgrading your application from Rails 3 to Rails 4, you might start seeing the following deprecation warning if you are using the readonly option in an association.

DEPRECATION WARNING: The following options in your Company.has_many :users declaration are deprecated: :readonly. Please use a scope block instead. ...

In this blog post, we’ll discuss in detail what the readonly option is and how to handle the deprecation warning.

Recently, while working on a Rails 6.1 to 7.0 upgrade, we encountered the following deprecation warning regarding changes made to ActiveRecord::Relation’s merge method:

"Merging (#{node.to_sql}) and (#{ref.to_sql}) no longer maintains both conditions, and will be replaced by the latter in Rails 7.0. To migrate to Rails 7.0's behavior, use relation.merge(other, rewhere: true)."

In this article, we will talk about the expected behavior of merge, how it has changed and what to do in order to use the new behavior if you find yourself looking at this deprecation.

Recently I got to work on a task that included understanding how to test JavaScript requests with RSpec. One thing that I found missing during my time researching solutions was organized and detailed documentation explaining the solutions based on the version of Rails and RSpec the application runs on.

Ruby on Rails is a popular web application framework that is constantly evolving with new versions being released frequently. While upgrading to a newer Rails version can bring new features, better performance, and security patches/improvements, it can also be a challenging task.

In this blog post, we will discuss 7 common mistakes made while doing Rails upgrades and how to avoid them.

Since 2017 we have been focusing on upgrading Ruby on Rails applications. It’s been quite a fulfilling learning process as we continuously improve our workflow best practices, and internal tooling.

In this article I will go into detail to explain how we determine the best approach to create the roadmap for a successful upgrade project.

Gems are a central part in a Rails application, they help us add new functionality to our apps so we don’t have to reinvent the wheel, but also allows us to extract code to better organize the codebase and to share logic between multiple apps. In many cases, we have custom made gems, and we need to ensure they will work properly with the two Rails versions we run when we use the Dual Boot technique during upgrades. But… How do you dual boot the gems?

At FastRuby.io, we recommend using the Dual Boot technique for upgrades. This requires us to generate a Gemfile.next.lock file that will be used to boot the app with the next version or Rails. In this article we’ll share 2 techniques to generate this file: the faster one and the safer one.

At OmbuLabs, one of our specialities is upgrading Ruby on Rails applications through our specialized service called FastRuby.io. In this post, I want to share with you some of the things that I’ve learned while working on my first Rails upgrade client project as a less experienced Rails developer.

This article is part of our Upgrade Rails series. To see more of them, click here.

This article will cover the most important aspects that you need to know to get your Ruby on Rails application from version 6.1 to version 7.0.

Zeitwerk is the code autoloader and reloader that was integrated with Rails 6. Beginning in Rails 7, it will be the only codeloader option. As a result, upgrading to Zeitwerk will be an important step in getting your application ready for the next version of Rails. In this article, we’ll talk about upgrading your Rails 6 application from classic to zeitwerk mode.

In case you are not familiar with us, FastRuby.io specializes in Ruby and Rails upgrades. Over these past 10 years we have had the opportunity to perform dozens of upgrades for our clients, which has given us all sorts of experiences. A common scenario that we experience is when the upgrade isn’t straightforward and we can’t just upgrade the Ruby or the Rails version directly.

We often find ourselves in a situation where we need to upgrade one or more dependencies before we can actually upgrade Ruby or Rails itself. For instance, if your want to upgrade your app from Rails 5.x to 6.x and the application still uses Paperclip to manage your file attachments, first you’ll need to replace that gem because Paperclip was deprecated in favor of Active Storage after Rails 5.2 was released.

This was the case for one of our clients that has been doing upgrades with us for a few years now. In this article I’m going to share the mishaps found by the team and the strategy that we adopted to migrate their huge volume of attachments over to Active Storage while still keeping Paperclip active until the migration was finished.

This article is part of our Upgrade Rails series. To see more of them, click here.

This article will cover the most important aspects that you need to know to get your Ruby on Rails application from version 6.0 to 6.1.

Ruby 3.0 was released on December 25th 2020. We can now enjoy the great new features of this version, such as performance boost (we talked about that in this recent article), ractors for concurrency, fiber schedulers, and type checking.

If you already have an application running in production and want to be able to use such benefits you’ll need to upgrade your Ruby version.

This article will cover the most important aspects that you’ll need to know to get your Ruby application from version 2.7 to 3.0

One of the steps we recommend taking when doing an upgrade for any Rails version is to dual boot the application with your current Rails version and your next rails version.

This is important because it allows you to quickly run the test suite for both versions, having dual booting available allows you to debug and also revert to your current version in a much simpler fashion.

However, sometimes changes that you make for the new version of Rails may not be compatible with your current version of Rails. This means that you will need to use a few different techniques to get both versions to be able to use the dual booting and run smoothly.

Welcome to our series of Rails upgrade miniguides. Here you’ll find links to all of the relevant posts to help with an upgrade.

Sometimes you will be caught between a rock and a hard place. For example: You really need to upgrade your Rails application because Heroku is discontinuing your stack in two weeks so you don’t have the time to write an entire test suite.

Sometimes the situation will be that your boss really needs you to upgrade Ruby or Rails to use a version that gets security updates and they won’t allow you to write tests beforehand.

This article will explain how to ship a Rails upgrade project without a test suite. If your application has no tests, you will learn how to upgrade without having to write tests first.

This article is part of our Upgrade Rails series. To see more of them, click here.

This article will cover the most important aspects that you need to know to prepare your Ruby on Rails application for working on an upgrade.

If you’re a developer you know the reasons why you should be using the latest Rails framework. You understand the implications of performance gains, dependency issues and unsupported versions.

But these big picture benefits get lost in translation when talking to non-technical executives. What they need to know is the business case for an upgrade, how the work will translate into increased revenue.

So, here is an article to use or forward to communicate why an upgrade should be a priority. We also wrote an article on the more technical reasons if you are interested.

When upgrading a Rails application, you might find that sometimes functionality is extracted from Rails and moved into a new gem. These gems are called shims, and they will basically allow you to keep using an old functionality, once the core API takes that out. You can also find shims in form of monkey patches. In this case it’s functionality that you develop to make your migration easier.

In this article I will list some of the functionality of past versions of Rails that was extracted into gems.

Having a clear idea of how much test coverage your Rails application has is really important. Especially if you are planning to upgrade to a newer version of Rails. A good test suite will tell you if your application is working as it did before the upgrade.

At FastRuby.io, we recommend having at least 80% of your application covered before attempting to upgrade. A number lower than that would require you to make a lot more manual testing to ensure that the application is properly working after the upgrade. If your application doesn’t meet that number, we suggest to first spend some time improving the test suite before starting the upgrade.

In this article, I’ll show you how you can measure your test coverage using SimpleCov.

A quick note before starting: SimpleCov doesn’t work in projects with Ruby 1.8.7 or lower. If that’s your case, you can try rcov.

Rails upgrades can be done in many different ways. Depending on the application that you want to upgrade, some ways make more sense than others. There are factors that determine which Rails upgrade strategy is the best for your case, like how big your application is, or how frequently changes are pushed to the master branch. In this article I’ll be covering two common Rails Upgrade strategies so you can decide which one is the best for your application.

Deprecation warnings are a common thing in our industry. They are warnings that notify us that a specific feature (e.g. a method) will be removed soon (usually in the next minor or major version) and should be replaced with something else. Features are deprecated rather than immediately removed, in order to provide backward compatibility (a solution that works in both the current and the future version), and to give programmers time to implement the code in a way that follows the new standard.

In this guide we’ll show you what the workflow is that we use at FastRuby.io to address deprecation warnings when we upgrade Rails applications.

We know that there are many challenges involved in a Rails upgrade project. Depending on how big your application is, how old your Rails version is and how well structured your code is, it can be difficult to perform that job and keep your sanity. If you don’t find a reliable and trustable process to guide you from version X to version Y, you can end-up in a nightmare.

The good news is that here at OmbuLabs, we have been upgrading Rails applications for over 10 years now and this gave us a know-how to define a process that has proven to be very effective. And today I want to share Our Rails Upgrade Process with you.

Technology evolves quickly. When you first created your Rails application, it’s likely you did it using the latest version of Rails. As time passes, however, new Rails versions come out and your application becomes more and more out of touch with the latest version. But why is this important? Why does it matter?

There are several different reasons to upgrade your Rails application. In this article, I’ll list what we consider to be the most important ones.

Migrating from Protected Attributes to Strong Parameters in a Rails project can be a huge step of the upgrade process. Especially when we are upgrading a large application. This guide is meant to help you tackle that step faster and with a lot less pain.

We recently collaborated with Amitree on a Rails upgrade for their application which “is an AI assistant for email, integrated deeply within Google and Microsoft’s products and is in heavy use by real estate professionals” and were able to speak to them about their experience with OmbuLabs.

An outdated Rails application doesn’t happen overnight. In FastRuby.io we work with a lot of clients who have outdated Rails applications and we help them upgrade to a newer Rails version. In this article I share some things that you could start doing to avoid falling out of date.

Over the years we have seen a significant increase in the demand for Ruby on Rails upgrades. That’s why a few years ago we decided to launch FastRuby.io, our Ruby on Rails upgrade service.

When we receive an inquiry via FastRuby.io, the first thing we like to do is schedule a call with the potential client to get more details about their app.

This article is part of our Upgrade Rails series. To see more of them, click here.

This article will cover the most important aspects that you need to know to get your Ruby on Rails application from version 5.2 to 6.0.

Next week the Rails community is having the biggest event of the year, the Rails Conf 2019. We participated in previous editions of this conference but this time we have the honor to be on the speakers side of it. We’ll be teaching you what we’re best at: Rails Upgrades.

In this article I will explain how you can dual boot your application in your local environment and your continuous integration (CI) service. I hope that this will help you get ready for the next stable release of Rails.

This article is part of our Upgrade Rails series. To see more of them, click here.

This article will cover the most important aspects that you need to know to get your Ruby on Rails application from version 5.1 to 5.2.

This article is part of our Upgrade Rails series. To see more of them, click here.

This article will cover the most important aspects that you need to know to get your Ruby on Rails application from version 5.0 to 5.1.

This article is part of our Upgrade Rails series. To see more of them, click here.

This article will cover the most important aspects that you need to know to get your Ruby on Rails application from version 4.2 to 5.0.

This article takes a look at some of the changes to the ActiveRecord::Dirty module between Rails 5.1 and 5.2.

If you’re running Rails 5.1, you may have already seen some of the deprecation warnings related to the API changes contained in it. Most of them are behavior changes, and there are some new additions as well.

To better understand these modifications, we’ll take a look at sample projects in Rails 5.1 and Rails 5.2.

This article is part of our Upgrade Rails series. To see more of them, click here.

This article will cover the most important aspects that you need to know to get your Ruby on Rails application from version 4.1 to 4.2.

This article is part of our Upgrade Rails series. To see more of them, click here.

This article will cover the most important aspects that you need to know to get your Ruby on Rails application from version 4.0 to 4.1.

This article is part of our Upgrade Rails series. To see more of them, check our article title The Rails Upgrade Series.

A previous post covered some general tips to take into account for this migration. This article will try to go a bit more in depth. We will first go from 3.2 to 4.0, then to 4.1 and finally to 4.2. Depending on the complexity of your app, a Rails upgrade can take anywhere from one week for a single developer, to a few months for two developers.

This is part of our Upgrade Rails series. We will be covering the most important aspects that you need to know to update your Ruby on Rails application from version 3.1 to 3.2.

This is part of our Upgrade Rails series. We will be covering the most important aspects that you need to know to update your Ruby on Rails application from version 3.0 to 3.1. If you are in an older version, you can take a look at our previous article.

This article is the first of our Upgrade Rails series. We will be covering the most important aspects that you need to know to update your Ruby on Rails application from version 2.3 to 3.0.

There are already quite a few guides in the wild to help with the upgrade of Rails 3.2 to Rails 4.0.

The official Rails guide for upgrading from Rails 3.2 to 4.0 is very thorough. With the recent release of Rails 5.0, apps currently in production running Rails 3.2 should probably be updated to any stable Rails 4 release as soon as possible.

There is even an e-book about upgrading from Rails 3 to 4, which serves as a useful guide to make this upgrade easier, and also helps understand the advantages & disadvantages of this new (soon to be old) version.

However, if you’re using any non-standard gems, you’re mostly on your own. Some gems stopped being maintained before Rails 4 was released, as was the case with CanCan, a well known authorization library. After many open pull requests were left unmerged, CanCanCan was released. It is a community driven effort to have a semi-official fork of CanCan. It serves as a drop-in replacement for people who want to use CanCan after upgrading to Rails 4.