How Much Does it Cost to Upgrade Rails?

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?

Defining Cost

Before we dive into the potential cost of a Rails upgrade (and what contributes to the final price of a project), let’s contextualize cost and briefly discuss how we’re calculating it for the purpose of this article.

The cost of the upgrade encompasses the entire Rails upgrade project, including preparatory work and support through deployment. This cost is primarily determined by the duration of the project. First, we assess the time required to complete the upgrade, which then allows us to estimate the total cost.

For the purposes of this article, we’re evaluating the cost of upgrading with FastRuby.io. Therefore, the cost is calculated based on how long it takes our experts to complete an upgrade. When evaluating the cost of upgrading in house, the numbers might not directly translate, as the cost then becomes equal to the opportunity cost of taking a team away from your product roadmap for the duration of the upgrade.

So How Much Is It to Upgrade Rails?

There are a number of factors that contribute to the cost of an upgrade. To evaluate how much this kind of project typically costs, we dove into our historical data on projects we have worked on. Check out our Case Studies opens a new window for some of those projects.

We upgrade Rails applications one minor version at a time. However, our engagements typically involve a major jump. To analyze the cost of upgrades, we divided our upgrade projects into 5 different buckets:

• Rails 2.3 to 3.2 upgrades
• Rails 3.2 to 4.2 upgrades
• Rails 4.2 to 5.2 upgrades
• Rails 5.2 to 6.1 upgrades
• Rails 6.1 to 7.0 upgrades

Then we collected the length and effort of each project in the dataset.

Of course not every project we work on covers exactly these versions. For the situations where we had a project that did not have some of the version jumps included in the band, an estimate for the duration of that upgrade, had it happened, was calculated based on the duration of the version jump that did happen and its proportion to the other jumps.

The duration of our upgrade projects is typically calculated in weeks. For the purpose of this analysis, a week is considered to be 60 hours of work (2 engineers working 30 hours each on the project). Below are the ranges of project duration for each bucket:

Based on the length of each project, the cost was calculated with current rates:

The box plot gives us insight into several features within the dataset. Considering all the factors that can affect the length of a Rails upgrade project, we expect to see a relatively high level of variability in the data.

The blue boxes represent the interquartile (IQR) range for each bucket. That is the range of data within the 25th percentile and 75th percentile of the dataset. In other words, of all upgrade projects in the dataset for a given bucket, 50% of the projects’ costs fall within the blue box range. A taller box indicates higher variability in this 50% of data, while a shorter box indicates a more homogeneous set.

The orange line indicates the median value of the data. Boxes with a median line further away from the middle of the box indicate a more skewed dataset.

The “T” shaped lines extending from top and bottom of the boxes (also known as whiskers) represent the minimum and maximum values within 1.5 times the IQR. Longer whiskers indicate a higher level of variability outside of the central 50% of data points, while a shorter whisker indicates lower variability.

The hollow circles indicate outliers. These are values present in the dataset that fall beyond the range of the whiskers, and represent an anomaly.

Considering these results, we can define the range of cost of a typical Rails upgrade project, per jump, as:

It is clear that the cost of upgrading Rails goes down the more recent the target version, with the exception of the jump from Rails 6.1 to 7.0. Two key factors contribute for the discrepancy though:

• Projects in the Rails 6.1 to 7.0 dataset are larger and more complex than their counterparts in the 5.2 to 6.1 dataset
• The jump from Rails 6.1 to 7.0 typically involves also upgrading Ruby from 2.5 to 2.7 (required) and most clients opt to just upgrade to a supported version (> 3.0).

The ranges provide a good idea of what to expect when you are upgrading. For a higher level of precision of how much it’ll cost to upgrade your specific Rails application from your current version to your desired target version, we offer the Roadmap to Upgrade Rails opens a new window , a detailed, in-depth analysis with associated estimates.

In the next sections of this article, we’ll dive deeper into what factors affect the length and, therefore, cost of a Rails upgrade.

What Can Affect the Length (And Cost) of My Rails Upgrade?

There are multiple factors that contribute to the effort required to upgrade a Rails application and thus to its length and cost. We begin by analyzing two key factors that, in our experience, have the potential to make the upgrade project really difficult or really easy: Code Coverage and Code Complexity.

Code Coverage

For every upgrade project we work on, we calculate and analyze the test coverage of the application. Automated tests make the upgrade process a lot smoother, by reducing the manual testing load and, with that, the back and forth between our engineers and the client’s team.

The higher an application’s test coverage, the more the tests themselves are going to tell us, the more certain we are that the pull requests we’re opening related to the upgrade are addressing the right things, and not introducing failures. This streamlines the process of reviewing and merging those pull requests, and reduces the risk of something breaking in production and a shipped change needing to be rolled back.

This doesn’t mean it’s not possible to upgrade Rails if the application has low test coverage. As the boxplot below shows, we have worked with applications with varying levels of coverage:

The blue box represent the interquartile range of coverage of the codebases within each version jump range. This means 50% of all projects analyzed fall within the range defined by the blue box. The orange line indicates the median value of the data and the “T” shaped lines extending from top and bottom of the boxes (also known as whiskers) represent the minimum and maximum values within 1.5 times the IQR. The hollow circles indicate outliers.

You can see, for example, that coverage for projects upgrading from Rails 4.2 to Rails 5.2 ranged from around 82% to around 95%, with no outliers and low variability (very short whiskers). Coverage for projects upgrading from Rails 5.2 to Rails 6.1, however, ranged from around 70% to approximately 88% with a lot more variability in the data and one outlier at less than 20% coverage.

As the graph shows, we have experience upgrading codebases with all levels of coverage. However, it is important to note that, as the test coverage goes down, the level of uncertainty goes up and so does the potential cost of the upgrade. That said, the impact on length can be minimized by high coordination between our engineering team and your QA team.

Code Complexity

To get a good idea of the complexity of the codebase we’ll be working with, we run an in-depth code complexity analysis. We collect a set of key metrics to understand the size and potential complexity of the application, and leverage Skunk opens a new window and RubyCritic opens a new window to get a comprehensive view.

By understanding the proportion of complex files in your application, files with high complexity and low coverage, compared to its size, we have a good idea of complexity and potential challenges we may face when doing the upgrade. This kind of complexity can drive the cost of upgrading up by requiring more time from our team to fully understanding what is going on with a specific module, for example, and how to find a solution for the upgrade, or even more communication and input from your team when it comes to making decisions about potential paths to take.

It is worth noting that complexity doesn’t necessarily relate to application size. There are very large applications that don’t have higher levels of associated code complexity and, although it’ll take longer to upgrade them compared to a smaller application of similar complexity, small applications with very high complexity can actually take longer to upgrade in comparison.

Additional Factors

In addition to complexity and test coverage, specific characteristics of a codebase might make the upgrade effort higher or lower. These can include, for example, usage of monkey patching (and whether these patches are covered by tests or not), number of forked and outdated gems, number of dependencies with incompatibilities, among many other things.

Process-related characteristics, such as review and QA flow, potential blockers, deployment process can also impact the length and cost of the upgrade.

Conclusion

The cost and duration of a Rails upgrade are influenced by various factors. Generally, the upgrade becomes less expensive as your current Rails version approaches the latest one. Additionally, having extensive coverage and less complex modules further reduces the cost.

Although upgrading Rails, be it in-house or with a vendor, can seem like a costly project at first, when considering the costs associated with risk and compliance issues that can arise from running old dependencies in production, the reduction in your team’s productivity and the new features and improvements you’re missing out on and associated opportunity cost, it is a project with a high return on investment.

Interested in getting an in-depth analysis customized to your application and understand what it’ll take to upgrade your Rails app? Send us a message! opens a new window