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.

With the Ruby 3.3.0 release around the corner, we wanted to share a summary of the changes that are coming in this new version. There are many exciting new features and improvements!

Whether you are working in a legacy Ruby application, or a brand new application, measuring your dependency freshness score can be a positive indicator to understand whether you are staying current or gradually falling out of date.

Dependency freshness is defined as the difference between the currently used version of a dependency and the version that the system would ideally use.

In this article, I will discuss a couple of ways to keep track of how outdated or how fresh your dependencies really are.

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.

By default, Ruby defines many constants and global variables that can be used in the code to get information about the current state of the application and the runtime. In this article we’ll go over most of them to understand what they are and what information we can set and get to simplify our scripts or to debug problems.

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.

One essential tool that we as software developers rely on is known as “test doubles.” These versatile components come in various forms, including dummies, fakes, stubs, spies, and mocks. However, like other power tools, they require careful handling to prevent unintended consequences.

In this post, we’ll explore the strategic use of test doubles at the boundaries of our application, harnessing their full potential while minimizing associated risks.

Most people and companies that we talk to about upgrades assume that we generally help organizations that need to migrate to the latest Rails version.

However, this isn’t necessarily the truth. Instead, we mostly perform Rails upgrades for companies who are all the way back on Rails 3 or 4. To give you a better understanding of how common it is for companies to be on much older versions, this is a general list of our statistics from the past few years.

• Rails 2.3 - 3.2: 5 - 15 upgrades
• Rails 3.2 - 4.2: ~40 upgrades
• Rails 4.2 - 5.2: ~40 upgrades
• Rails 5.2 - 6.1: ~10 upgrades
• Rails 6.1 - 7.1: ~10 upgrades

We generally work with a lot of large, well established companies, so how did these successful companies fall so far behind, and how can you help your company to never need to hire us?

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.