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.