The approach you have mentioned sounds incredibly risky, and a debugging / support nightmare! Assuming you have good tests in place, I think you're better off to upgrade from 1 -> 2, 2 -> 3 and then 3 -> 4.
Start by reading the release notes and the upgrade instructions from each of the major releases. Based on your knowledge of the application, that would be a good place to start thinking about what sort of issues you're likely to face. I think the only sensible scenario for running both apps side-by-side is for testing purposes. Take a copy of your prod database and replicate this into a staging environment that you can test against. This is likely to be far more efficient than a rewrite from scratch approach, but the key is to minimise risk by doing lots of testing. If you haven't already, make sure you have an issues list and good version control! One of the big issues you're likely to run into is the Ruby change. If you have old code written for 1.8.6 (or even older!), you will find you will have to make some changes to get it to play with Ruby 2.x. Again, reading the release notes and migration instructions will be invaluable. Do it piece-by-piece so it's manageable. Good luck! Kind regards, Timothy. On 31 January 2014 09:03, Russ Silva <li...@ruby-forum.com> wrote: > I'm working on a Rails 1 application. We'd like to upgrade it to Rails 3 > or 4, but Rails 1 is so old that we think it would take a total rewrite > to upgrade. There are management and budget issues with a total rewrite. > We wouldn't be able to deliver anything until the entire rewritten > application was finished. > > So, we are searching for creative solutions to the upgrade problem. One > idea is to start rewriting the application in Rails 4 and run it > alongside the Rails 1 application. As features are added to the Rails 4 > version, the same feature in the Rails 1 version could be taken offline. > Users would see a mix of the two versions. Some pages would be served by > Rails 1 and others by Rails 4. > > This would require both the Rails 1 and Rails 4 versions to use the same > database. > > So my question is, will this work? What problems with this approach > should we be anticipating? We know it isn't a perfect solution, but > we're hoping it's good enough to drive the project forward. > > -- > Posted via http://www.ruby-forum.com/. > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rubyonrails-talk+unsubscr...@googlegroups.com. > To post to this group, send email to rubyonrails-talk@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/rubyonrails-talk/6105907de4cc645c399d0e9a7cae3e4a%40ruby-forum.com > . > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-talk@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CABLJ1DKTP0kRPUQtjDjc3xncOnU-Jv_RXseiO84JoikuV8tLtA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
