|
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@...
|
|
Re: 5.x to 6.x migration timeline, best practices, tips
|
|
Re: 5.x to 6.x migration timeline, best practices, tips
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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
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@...
|
|
Re: 5.x to 6.x migration timeline, best practices, tips
Quoting T L < tloud365@...>:
> 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/
|
|
Re: 5.x to 6.x migration timeline, best practices, tips
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
|
|
Re: 5.x to 6.x migration timeline, best practices, tips
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
|
|
Re: 5.x to 6.x migration timeline, best practices, tips
> 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.
|
|
Re: 5.x to 6.x migration timeline, best practices, tips
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@...> 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@...
|
|
Re: 5.x to 6.x migration timeline, best practices, tips
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.comFunnyMonkey -- Click. Connect. Learn.
ph. 503 897 7160
|
|
Re: 5.x to 6.x migration timeline, best practices, tips
Quoting Andrew Berry < andrewberry@...>:
> 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/
|
|
Re: 5.x to 6.x migration timeline, best practices, tips
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@...
http://mikeyp.net
|
|
Re: 5.x to 6.x migration timeline, best practices, tips
On 18-May-09, at 5:06 PM, Earnie Boyd wrote:
> Quoting Andrew Berry < andrewberry@...>:
>
>> 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
|
|
Re: 5.x to 6.x migration timeline, best practices, tips
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@...>
wrote:
> On 18-May-09, at 5:06 PM, Earnie Boyd wrote:
>
>> Quoting Andrew Berry < andrewberry@...>:
>>
>>> 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
|
|
Re: 5.x to 6.x migration timeline, best practices, tips
Quoting Andrew Berry < andrewberry@...>:
> On 18-May-09, at 5:06 PM, Earnie Boyd wrote:
>
>> Quoting Andrew Berry < andrewberry@...>:
>>
>>> 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/
|
|
Re: 5.x to 6.x migration timeline, best practices, tips
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.
|
|
Re: 5.x to 6.x migration timeline, best practices, tips
Quoting Nathaniel Catchpole < catch56@...>:
> 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/
|
|
Re: 5.x to 6.x migration timeline, best practices, tips
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
|
|
Re: 5.x to 6.x migration timeline, best practices, tips
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@...> wrote:
Quoting Nathaniel Catchpole < catch56@...>:
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.
<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>
|
|
Re: 5.x to 6.x migration timeline, best practices, tips
Quoting Nathaniel Catchpole < catch56@...>:
> 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/
|
|
Re: 5.x to 6.x migration timeline, best practices, tips
Quoting Andrew Berry < andrewberry@...>:
>>
>> <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/
|
smime.p7s (3K) 