Come on now. It's like being in a car at 80 kph in the direction of a wall and claiming that the trajectory is "just fine" a few seconds before impact. If you couldn't somehow find a way to work around the well-known end of life for Rails 2.3, then you had it coming. There's a point as a business man where you need to invest the money to make more money. In this case, fixing your code base so that it can be ready for the 4, 5 years to come.
No, it's like having a car that you don't mind driving for the rest of the decade (barring any serious accident), as opposed to exchanging it for a new one every 3 years to keep up with the Joneses.
It's more difficult in slow-moving enterprise environments. In our environment, the time from someone saying "we should do this" until it's in production can easily be 3 years.
Then, add the lifetime of use which can span even decades (depending on the application). Long-term managers and architects have seen many, many technologies and methodologies come and go, and treat claims of "you better change that system quick!" with skepticism (doesn't mean it isn't true).
Four to five years of life for an enterprise code base is a blink of an eye. If I proposed a major framework/foundation change for a four year old application, I'd be getting some unpleasant looks.
That's not greed.