5.x to 6.x migration timeline, best practices, tips
Hello All, I've inherited a 5.x (5.05 I think) site with about 20 contributed modules and one monster custom module (~ 7000 lines), and I'm looking at migrating to 6.x sometime in the next few months. I've looked over the handbook pages and done a little bit of googling with some good success. But I haven't found much info on planning or common pitfalls. So I was wondering if anyone had any suggestions on things to look out for or a generalized timeline? My guess was at least 100 hours to upgrade to 5.18, migrate to 6.12, test the system, and then adjust the theme and api calls. Does this seem reasonable at all? Any thoughts, suggestions, or redirects to resources would be much appreciated. Thanks so much, Tim -- Tim Loudon t: 781.686.6096 e: tloud365@gmail.com
It probably depends on how many of those modules have been ported to drupal 6 already and how much work the custom module would need. Here, coder module and deadwood may be big helps: http://drupal.org/project/coder http://drupal.org/project/deadwood
You can have a look at coder (http://drupal.org/project/coder) and deadwood (http://drupal.org/project/deadwood and http://boombatower.com/tools/deadwood), the first one gives you pointers on how to convert, the second one tries to convert it for you. If all other modules are available for D6 100 seems reasonable From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of T L Sent: maandag 18 mei 2009 01:56 To: development@drupal.org Subject: [development] 5.x to 6.x migration timeline, best practices, tips Hello All, I've inherited a 5.x (5.05 I think) site with about 20 contributed modules and one monster custom module (~ 7000 lines), and I'm looking at migrating to 6.x sometime in the next few months. I've looked over the handbook pages and done a little bit of googling with some good success. But I haven't found much info on planning or common pitfalls. So I was wondering if anyone had any suggestions on things to look out for or a generalized timeline? My guess was at least 100 hours to upgrade to 5.18, migrate to 6.12, test the system, and then adjust the theme and api calls. Does this seem reasonable at all? Any thoughts, suggestions, or redirects to resources would be much appreciated. Thanks so much, Tim -- Tim Loudon t: 781.686.6096 e: tloud365@gmail.com<mailto:tloud365@gmail.com>
Quoting T L <tloud365@gmail.com>:
Hello All,
I've inherited a 5.x (5.05 I think) site with about 20 contributed modules and one monster custom module (~ 7000 lines), and I'm looking at migrating to 6.x sometime in the next few months. I've looked over the handbook pages and done a little bit of googling with some good success. But I haven't found much info on planning or common pitfalls.
So I was wondering if anyone had any suggestions on things to look out for or a generalized timeline? My guess was at least 100 hours to upgrade to 5.18, migrate to 6.12, test the system, and then adjust the theme and api calls. Does this seem reasonable at all?
Any thoughts, suggestions, or redirects to resources would be much appreciated.
Here is what I did to move from 4.7.3 to 6.10: http://for-my-kids.com/Upgrading-Drupal. Be sure to move the contrib modules directory out of the Drupal tree while upgrading the core modules. Others have already mentioned coder and deadwood modules. When using deadwood, take the resulting module as a report of what needs to be done manually; there is a lot left to the user but most of it is documented in the resulting source. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
Earnie, Thanks for the instructions on this. You included the step of going to 5.0 first, then the latest 5.x. I always wondered if this was necessary. Thanks! Mark
Here is what I did to move from 4.7.3 to 6.10: http://for-my-kids.com/Upgrading-Drupal .
Be sure to move the contrib modules directory out of the Drupal tree while upgrading the core modules. Others have already mentioned coder and deadwood modules. When using deadwood, take the resulting module as a report of what needs to be done manually; there is a lot left to the user but most of it is documented in the resulting source.
-- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
On 18-May-09, at 8:37 AM, Mark Shropshire wrote:
Thanks for the instructions on this. You included the step of going to 5.0 first, then the latest 5.x. I always wondered if this was necessary.
AFAIK it shouldn't be; Earnie, can you explain why you did it that way?
My guess was at least 100 hours to upgrade to 5.18, migrate to 6.12
The vast majority of that should be in the 5-6 migration; upgrading from 5.5 to 5.18 should be pretty trivial, assuming the site was built without too many core hacks. --Andrew
Quoting Andrew Berry <andrewberry@sentex.net>:
On 18-May-09, at 8:37 AM, Mark Shropshire wrote:
Thanks for the instructions on this. You included the step of going to 5.0 first, then the latest 5.x. I always wondered if this was necessary.
AFAIK it shouldn't be; Earnie, can you explain why you did it that way?
Because it ensures that all updates marked for 5.x are made since those updates are not carried to 6.x.
My guess was at least 100 hours to upgrade to 5.18, migrate to 6.12
The vast majority of that should be in the 5-6 migration; upgrading from 5.5 to 5.18 should be pretty trivial, assuming the site was built without too many core hacks.
It took me about 2 hours to do mine but all of the modules were 6.x ready. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
On 18-May-09, at 5:06 PM, Earnie Boyd wrote:
Quoting Andrew Berry <andrewberry@sentex.net>:
On 18-May-09, at 8:37 AM, Mark Shropshire wrote:
Thanks for the instructions on this. You included the step of going to 5.0 first, then the latest 5.x. I always wondered if this was necessary.
AFAIK it shouldn't be; Earnie, can you explain why you did it that way?
Because it ensures that all updates marked for 5.x are made since those updates are not carried to 6.x.
Sorry, I guess I wasn't clear. I was curious as to why you did the extra step of 5.0 to 5.x. Are updates being removed within the 5.x releases? If you had a 4.7.x site, wouldn't you want to go from 4.7.11 directly to 5.18? --Andrew
That was I was getting at in my original email too. Thanks for clarifying. On May 18, 2009, at 5:32 PM, Andrew Berry <andrewberry@sentex.net> wrote:
On 18-May-09, at 5:06 PM, Earnie Boyd wrote:
Quoting Andrew Berry <andrewberry@sentex.net>:
On 18-May-09, at 8:37 AM, Mark Shropshire wrote:
Thanks for the instructions on this. You included the step of going to 5.0 first, then the latest 5.x. I always wondered if this was necessary.
AFAIK it shouldn't be; Earnie, can you explain why you did it that way?
Because it ensures that all updates marked for 5.x are made since those updates are not carried to 6.x.
Sorry, I guess I wasn't clear. I was curious as to why you did the extra step of 5.0 to 5.x. Are updates being removed within the 5.x releases? If you had a 4.7.x site, wouldn't you want to go from 4.7.11 directly to 5.18?
--Andrew
Quoting Andrew Berry <andrewberry@sentex.net>:
On 18-May-09, at 5:06 PM, Earnie Boyd wrote:
Quoting Andrew Berry <andrewberry@sentex.net>:
On 18-May-09, at 8:37 AM, Mark Shropshire wrote:
Thanks for the instructions on this. You included the step of going to 5.0 first, then the latest 5.x. I always wondered if this was necessary.
AFAIK it shouldn't be; Earnie, can you explain why you did it that way?
Because it ensures that all updates marked for 5.x are made since those updates are not carried to 6.x.
Sorry, I guess I wasn't clear. I was curious as to why you did the extra step of 5.0 to 5.x. Are updates being removed within the 5.x releases? If you had a 4.7.x site, wouldn't you want to go from 4.7.11 directly to 5.18?
My sanity is the only reason. I didn't try directly to 5.18. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
The only reason to upgrade from 5.x to 5.latest-stable would be if there's been schema changes in a minor version. This is very rare, but sometimes necessary - however it's easy to check by comparing system.install between 5.0 and 5.18 to see if any new hook_update_N() has been added. Nat
On 18-May-09, at 8:37 AM, Mark Shropshire wrote:
Thanks for the instructions on this. You included the step of going
to 5.0 first, then the latest 5.x. I always wondered if this was necessary.
AFAIK it shouldn't be; Earnie, can you explain why you did it that way?
Because it ensures that all updates marked for 5.x are made since those updates are not carried to 6.x.
Quoting Nathaniel Catchpole <catch56@googlemail.com>:
The only reason to upgrade from 5.x to 5.latest-stable would be if there's been schema changes in a minor version. This is very rare, but sometimes necessary - however it's easy to check by comparing system.install between 5.0 and 5.18 to see if any new hook_update_N() has been added.
Really? Then why is it documented practice? <quote reference="http://drupal.org/upgrade/"> 1. Upgrade to the latest minor version in the major version you're currently on (e.g. if you are on 5.5 and want to upgrade to 6.10, and there is a 5.12 version out, upgrade to 5.12 first). </quote> -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
On 19-May-09, at 12:29 PM, Earnie Boyd wrote:
Really? Then why is it documented practice?
<quote reference="http://drupal.org/upgrade/"> 1. Upgrade to the latest minor version in the major version you're currently on (e.g. if you are on 5.5 and want to upgrade to 6.10, and there is a 5.12 version out, upgrade to 5.12 first). </quote>
I assume in this case it's so that if there are any API-changing fixes in the point release, they are more easily dealt with than during a full upgrade. --Andrew
Quoting Andrew Berry <andrewberry@sentex.net>:
<quote reference="http://drupal.org/upgrade/"> 1. Upgrade to the latest minor version in the major version you're currently on (e.g. if you are on 5.5 and want to upgrade to 6.10, and there is a 5.12 version out, upgrade to 5.12 first). </quote>
I assume in this case it's so that if there are any API-changing fixes in the point release, they are more easily dealt with than during a full upgrade.
Yes, hook_update_N for the current release is not carried forward to the next major release. So, you might miss something important like a variable change, a new table column, a new index, or whatever the change may be if you don't upgrade to the latest point version first. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
Because changing those instructions to "Do a diff between all the core .install files to check for schema changes between the release you're currently on and the latest stable release, if there have been any updates, upgrade to the latest stable first, if not, proceed directly to 6" wouldn't make any sense to 90% of people? Nat On Tue, May 19, 2009 at 5:29 PM, Earnie Boyd <earnie@users.sourceforge.net>wrote:
Quoting Nathaniel Catchpole <catch56@googlemail.com>:
The only reason to upgrade from 5.x to 5.latest-stable would be if there's
been schema changes in a minor version. This is very rare, but sometimes necessary - however it's easy to check by comparing system.install between 5.0 and 5.18 to see if any new hook_update_N() has been added.
Really? Then why is it documented practice?
<quote reference="http://drupal.org/upgrade/"> 1. Upgrade to the latest minor version in the major version you're currently on (e.g. if you are on 5.5 and want to upgrade to 6.10, and there is a 5.12 version out, upgrade to 5.12 first). </quote>
-- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
Quoting Nathaniel Catchpole <catch56@googlemail.com>:
Because changing those instructions to "Do a diff between all the core .install files to check for schema changes between the release you're currently on and the latest stable release, if there have been any updates, upgrade to the latest stable first, if not, proceed directly to 6" wouldn't make any sense to 90% of people?
I'm fine with that except that there isn't a real need then to bring it up here, IMO. It only takes a matter of a few seconds to upgrade to the latest version. It would take me just as long to prepare and read the diff which is manual work where I might get it wrong. -- Earnie -- http://r-feed.com/ -- http://for-my-kids.com/ -- http://www.4offer.biz/ -- http://give-me-an-offer.com/
On May 18, 2009, at 11:25 AM, Andrew Berry wrote:
On 18-May-09, at 8:37 AM, Mark Shropshire wrote:
Thanks for the instructions on this. You included the step of going to 5.0 first, then the latest 5.x. I always wondered if this was necessary.
AFAIK it shouldn't be; Earnie, can you explain why you did it that way?
The update system as it is designed is technically capable of this, but managing updates for one release to the next (i.e. 5 to 6) is hard enough on core developers, and there is no testing done on major version skip-updates (i.e. 4.7-6) and consequently no support for that. -Mike __________________ Michael Prasuhn mike@mikeyp.net http://mikeyp.net
and one monster custom module (~ 7000 lines), and I'm looking at migrating to 6.x sometime in the next few months.
7K? Wow.
So I was wondering if anyone had any suggestions on things to look out for or a generalized timeline? My guess was at least 100 hours to upgrade to 5.18, migrate to 6.12, test the system, and then adjust the theme and api calls.
It's a very tough call when you consider that you have 7K lines of code that you aren't familiar with it. One note I can share is that you definitely must examine each contrib module's upgrade instructions--many *require* that you first upgrade them to the latest/last 5.x version before moving to 6. And they mean it. ;) Good luck.
Thanks for all the great tips y'all! I will definitely look into deadwood--hadn't heard of it and it's got such a catchy name. On the 7k, it's one of those things where they were like "yeah...you're gonna want to take care of that at some point." I was hoping to upgrade first and then remove some of the code either through core functionality or improved contribs--views 2 for example :). Expect another dev mailing list request in a couple of months on how to refactor monster modules. I don't think there was much/any core hacking, but there was some contributed module hacking "somewhere". Seriously though, it's working software made by really nice, really busy people. They recognize the limitations of the current state and want to take the time to migrate and create more maintainable software now. I've slung far smellier code before (I've got a BA in English), and besides, this way I get to perfect my svn diff skills. Thanks again y'all, Tim On Mon, May 18, 2009 at 2:40 PM, Fred Jones <fredthejonester@gmail.com>wrote:
and one monster custom module (~ 7000 lines), and I'm looking at migrating to 6.x sometime in the next few months.
7K? Wow.
So I was wondering if anyone had any suggestions on things to look out for or a generalized timeline? My guess was at least 100 hours to upgrade to 5.18, migrate to 6.12, test the system, and then adjust the theme and api calls.
It's a very tough call when you consider that you have 7K lines of code that you aren't familiar with it. One note I can share is that you definitely must examine each contrib module's upgrade instructions--many *require* that you first upgrade them to the latest/last 5.x version before moving to 6. And they mean it. ;)
Good luck.
-- Tim Loudon t: 781.686.6096 e: tloud365@gmail.com
T L wrote:
On the 7k, it's one of those things where they were like "yeah...you're gonna want to take care of that at some point." I was hoping to upgrade first and then remove some of the code either through core functionality or improved contribs--views 2 for example :). Expect another dev mailing list request in a couple of months on how to refactor monster modules.
The jump from Views to Views2 has the potential to save you many lines of code. The simple reality of how relationships work in Views2 can save you hours. Two other thing you should look at: 1. How much, if any, markup/php is contained within custom blocks or node bodies? 2. How is the theme structured? Both of these areas can provide ways to become more efficient upon upgrade, and additional complexity in these areas can complicate the upgrade. Cheers, Bill -- Bill Fitzgerald http://funnymonkey.com FunnyMonkey -- Click. Connect. Learn. ph. 503 897 7160
participants (10)
-
Andrew Berry -
Bill Fitzgerald -
Earnie Boyd -
Fred Jones -
Mark Shropshire -
Michael Prasuhn -
Naheem Zaffar -
Nathaniel Catchpole -
Peter Droogmans -
T L