Really the D6 step in the middle doesn't have to "work" at all if you
aren't going to push it live. The middle step is just so that your
data migrates as best as it can. All the display code, etc. that uses
the data doesn't have to work right, and that means much less to test
and fix. None of the D6 code will still be in use when the D7 site
goes live anyway, and I believe that the total work needed will be
lower this way in the majority of cases even after accounting for
problems you might have discovered in D6.
Use latest D5, update.php, switch to D6 core and latest modules where
possible, update.php, switch to D7, update.php. You're correct that
many modules will not support a direct 5->7 upgrade path, and often
you need to use the newest D5 branch to successfully migrate to D6.
A lot of your site is going to break, but that's unavoidable and at
least it won't break twice. The best reason for moving to D6 now and
pushing it live is if you *really* need something that D6 offers and
can't wait a few more months, but chances are good that you moved to
D6 long ago if that was the case.
If your site is D5, I'd also consider using the opportunity to just
build a new site instead of trying to migrate. Lots of things that
made sense in the D5 era have been completely replaced now, and you're
already going to be doing a ton of work and testing. The data you
want to keep can be imported (nodes, etc.).
- Ken Winters
On Jan 7, 2010, at 12:02 PM, Karen Stevenson wrote:
You can of course do both at the same time, first jump from 5 to 6,
make sure things are working right, and then jump from 6 to 7. But I
just want to clarify, in case there was any confusion, that you
can't just 'skip' the in-between version. And you can skip pushing
it live but you can't skip testing it. And if you need to do it
anyway, IMO it is actually easier to do it now, make sure everything
is working smoothly in version 6, and then do the 6->7 jump later.
There are many modules (like CCK) that will need to be upgraded from
5 to 6 before jumping to 7, especially when there are data updates
and schema changes involved. It's time-consuming to write and test
update hooks, it's a huge burden on developers to keep updates
working for even one version back, let alone two. CCK had massive
changes between version 5 and 6, we had to drop any support for
taking people from 4.7 straight to 6, and even then were many
situations where the upgrade didn't immediately work smoothly and
admins had to do some tweaking or get help with site-specific
issues. There will be even more massive changes from 6 to 7. We're
committed to creating an upgrade path from 6 to 7. There will be no
one writing or testing upgrade paths from 5 to 7.
The other issue is that D5 is less and less well supported as time
goes by, so you may be stuck for support until you are ready to jump
to 7, whereas support for D6 is good.
As you point out you can avoid re-writing your custom modules for
the in-between version, assuming your site works well enough without
them to test other module upgrades. If you have a lot of custom code
that may be a valid reason. But all the changes from D5 to D6 are
mostly still needed and used in D7, so you still need to figure out
what they are.
I personally think any time you save in one place by skipping a
version will be made up elsewhere in time spent figuring out what
broke and how to fix it, but each to his own on that issue :)
Karen
On Thu, Jan 7, 2010 at 7:57 AM, Ken Winters <[email protected]>
wrote:
Actually I would say that doing 5->6->7 all at once is a valid
approach. You cut down on testing, since
you have one fewer live push. You also don't have to worry about
replacing a module twice (first doing
a difficult to transition to 6 and then months later rewriting it
again -- just rewrite it in 7 once).
- Ken Winters
On Jan 7, 2010, at 2:22 AM, Csuthy Balint wrote:
On 8:59 PM, Ad wrote:
website owners don't have any reason left to step over from 5 to 6.
If you are not a Drupal development company, then you have to switch
from Drupal 5 to Drupal 6 now. There is no excuse for not doing it.
--
Karen Stevenson
Lullabot.com
