An important lesson I learned while working as a sysadmin was that when you're making operational changes, you do one thing at a time.
Let's say you need to set up a replicated database with failover and monitoring.
First you set up the database (and make sure it works).
Then you set up monitoring (and make sure it works, too).
Followed by replication (which should also work).
And finally, automatic failover (there's a pattern here...)
This sounds obvious, but I've worked with developers that, when given this task, tried to set up the entire thing in one shot. It took them over a month to wrap up, and they didn't have time to properly test it, because they bit off too much in one go.
The same goes for migrations. You work along an incremental plan to move from Point A to Point B, where at every step of the way, the set of things you need to change is small enough to manage, and you have the option of rolling back.
I can't imagine that Github has a tiny codebase, so I could totally believe six months for a zero-downtime Rails 2.x -> 3.0 migration. The next big step (3.0 -> 3.2) will be easier from what they learned in the first step, as will the step after that (my guess is 3.2 -> 4.0).