Apps of how many LOCs have you migrated? I have been migrating one and the same Rails app from version to version for around 5 years now, and we are currently

Apps of how many LOCs have you migrated? I have been migrating one and the same Rails app from version to version for around 5 years now, and we are currently at around 50k lines of code. When you are taking about "couple hours of work" and "painless" I can only laugh out loud. Every new minor or major Rails version migration takes several weeks with any larger app, only patch versions can be migrated reasonably smoothly. Migration from Rails 2.3 to Rails 3.0 was a particular catastrophe, it took me more than a month of intensive work, after the switch the application became twice as slow, which turned out to be a regression in the PostgreSQL driver that went unnoticed for a year since Rails 3.0 was first released. Just diagnosing this single issue took me a week of frustration, where I step by step peeled the onion of abstraction upon abstraction, having to profile Rails internals in the end. We are now looking into the Rails 3 -> Rails 4 migration, and it's not much better, after just changing the gems the application won't start, the console won't start, and the tests run into an infinite recursion and explode the stack. I routinely spend a week even to get just those three basic things to start at all, and it was this way even when migrating 1.x to 2.x. After every upgrade of this kind, some gems turn out to be abandoned are not upgraded by the authors to support the newer Rails, and seldom they will work with them without changes. The ones that were updated, often require a separate upgrade procedure of their own, there goes another week. Just fixing all the deprecation warnings will take another one. It's not just strong parameters, a lot of the old routing code does not work, conditions on relations don't work anymore, config settings become obsolete and so on and so forth, 80% of the things that have to be changed are not even in the release notes, for example Rails 4.0 happened to introduce an internal Options class that is visible from every controller and shadows our global Options constant which is the object with application configuration. It does not mean Rails "sucks" or anything like this, but keeping a very nice API while adapting a framework to requirements evolving over the years has the cost of sucking at compatibility, that's just a fact of software engineering. So please lets not pretend the Rails team top priority is ease of long term maintenance and lets put things as they are. If you are not systematically keeping up with newer Rails version, after half a year or 9 months since the last update you won't even receive bugfixes, because they often aren't backported even to the previous minor version. That the 37signals guys threw out their own biggest app and rewritten it from scratch is also telling about their attitude to things of this kind. So Rails is bad at compatibility, in exchange it keeps delivering a really nice API for a wider and wider scope of tasks.