[consulting] Feasibility

[Kevin Reynen]

I'm currently helping with an upgrade of one of Eric's projects from
4.7 -> 7, so...

+1 to upgradable != built right

This upgrade has more than 750K "records"... mainly nodes but some
custom data thrown in just to make it exciting.  Eric and his team did
a great job designing the structure.  The fact that it's still used
daily is a testament to that, but some of the modules used have either
been abandoned or are no longer the best tool for the job.  In
addition, the clients priorities shifted over the years.

Upgrading from 4.7 -> 5 -> 6 -> 7 now would have been insane.  NOT
upgrading with each release saved the client a lot of $$.  The
migration from 4.7 -> 7 cost far less than the combined cost of 3
upgrades.

You'd get further arguing that if a site is truly "done right", you
wouldn't need to upgrade at all :)

Entities vs. Nodes?  Upgradable == built right implies that keeping
content that doesn't need to be a node defined as a node is "right"
because it can be easily upgraded from a node type with CCK fields in
D6 to a node type with core fields in D7.

The Feeds and Migrate modules have also made the modules and
configuration used before MUCH less important.  It does NOT really
matter if the content has fields created with CCK, custom code, Event
vs. Date, or even flexinode (shudder)... you just need to get it into
an exportable form and remap the fields into something as good or
better.

Feeds now supports retaining the original nid
(http://drupal.org/node/1046916) which makes it much easier to migrate
while the original site is still running.  Adjusting the fields on a
content type and refreshing a Feeds import when you recognize that
something needs to be tweaked is often preferable than starting the
upgrade process over again.

There's really no right or wrong answer to upgrading vs. migrating.
Each site needs to be evaluated based on what it was and what the
client wants it to be now, but using upgradability as a measure of
rightness IS wrong.

- Kevin Reynen

On Tue, Feb 14, 2012 at 1:28 PM, Eric Goldhagen <eric at openflows.com> wrote:
> Another critical issue to keep in mind: the older the initial
> build/the more versions the site has already travelled through, the
> more likely that
>
> a: the "right way" to do things has radically changed
>
> b: modules exist now that are well maintained and stable that provide
> features that might have required custom code in the initial build
>
> c: odd things happen that will mysteriously break an upload and
> require more time to hunt down than to rebuild.
>
> This is especially the case with sites I've worked on that started in
> drupal 4.5 or 4.6. After an upgrade to 4.7 (which commonly was fraught
> with problems) and then to drupal 5, and then to 6 (which if you use
> views means you are moving from views 1 to views 2 and there is no
> upgrade path so you will have to rebuild your views) it is very common
> for even well buit sites to have built up enough cruft to be worthy of
> as least considering a rebuild.
>
> Sites that have little custom functionality built in 6 should have an
> easy time upgrading to 7. Sites built with little custom functionality
> in 5 have a 90% chance of being an easy upgrade to 6. Sites that have
> been through multiple versions tend to have more mysterious problems.
>
> So, it's not always the case that "if it is done right it can easily
> be upgraded." Part of the equation is based in how long ago it was
> done and what "doing it right" meant at that point.
>
> --Eric
>
>
> Quoting Rahul Khanna <rahul at nohup.in>:
>
>> Correct, if it was built right, it can be upgraded nicely.
>>
>> I had to upgrade a 5.x drupal and ubercart installation to 6.x, the
>> upgrade path was clear and easy. Most of it was done right except
>> one module and few theme files (there was db_query in the theme,
>> imagine that), which was not much of a challenge. But when it came
>> to doing the actual job, the new features that came in with 6.x and
>> ubercart warranted a rebuild not an upgrade. The story ended nicely
>> as the client understood. I learned a lesson, if it is a
>> simple/standard drupal installation, upgrade is the path to take,
>> but if it has custom modules and does a specific job, rebuild should
>> be the first consideration.
>>
>> Thanks,
>> Rahul
>>
>> On Tue, 14 Feb 2012 12:27:40 -0500
>> Sam Tresler <sam at treslerdesigns.com> wrote:
>>
>>> Honestly, this is becoming one of my sole biggest issues with Drupal. We
>>> can talk about the learning curve being steep, and rewards being
>>> plentiful all we want. However, when the automatic assumption is that
>>> the site was built wrong in the first place, and (I would hazard the
>>> guess) the majority of sites being built un-upgradable, then I have a
>>> very difficult time recommending it as a good platform to build upon.
>>>
>>> Sure, you can build amazing things on Drupal. But if only a marginally
>>> slim category of rock star developers is doing it in a sustainable
>>> fashion, then what is the point?
>>>
>>> More and more when I find myself in a situation where upgrade is
>>> impossible due poor original build, I step back and re-assess the
>>> client's needs out of a CMS and see if the complexity of Drupal is
>>> something that will ever be in their wheelhouse.
>>>
>>> I'm aware that sounds incredibly negative, but there are only so many
>>> "Drupal Disasters" that I can see without getting some negative
>>> attitude. Although, I do maintain Drupal has an easy upgrade path when
>>> executed properly.
>>>
>>> Regards,
>>>    Sam Tresler
>>>
>>> On 02/14/2012 07:59 AM, Christian Pearce wrote:
>>> >
>>> > ----- "Sam Tresler"<sam at treslerdesigns.com>  wrote:
>>> >
>>> >> From: "Sam Tresler"<sam at treslerdesigns.com>
>>> >> To: "A list for Drupal consultants and Drupal service/hosting
>>> providers"<consulting at drupal.org>
>>> >> Sent: Monday, February 13, 2012 3:52:53 PM GMT -05:00 US/Canada Eastern
>>> >> Subject: Re: [consulting] Feasibility
>>> >>
>>> >> I have found myself in a the middle of an upgrade where I thought it
>>> >> might be easier to rebuild, but only when it was built incorrectly in
>>> >>
>>> >
>>> > That is an excellent point.  We rarely have people come to us
>>> with an upgrade were the site is very well built.  (I am going to
>>> generalize).  Typically people come to us unsatisfied with the past
>>> performance of their existing developer.  When we look under the
>>> hood we see why.  I guess I just assume it isn't going to be well
>>> built.
>>> >
>>> >>
>>> >>
>>> >>
>>> >>>> From: "Sam Tresler"<sam at treslerdesigns.com>
>>> >>>> To: "A list for Drupal consultants and Drupal service/hosting
>>> >> providers"<consulting at drupal.org>
>>> >>>> Sent: Monday, February 13, 2012 11:26:50 AM GMT -05:00 US/Canada
>>> >> Eastern
>>> >>>> Subject: Re: [consulting] Feasibility
>>> >>>>
>>> >>>> " Part of providing value as a consultant is knowing when we
>>> >> should
>>> >>>> and
>>> >>>> when we shouldn't do something for a customer unless they say we
>>> >> don't
>>> >>>>
>>> >>>> care do it our way."
>>> >>>>
>>> >>>> Right. And as a consultant we probably shouldn't be making blanket
>>> >>>> recommendations without assessing the actual situation first.
>>> >>>>
>>> >>>
>>> >>> Right that is why I said "points well taken."  I was simply offering
>>> >> my opinion and thoughts to see what others were.
>>> >>>
>>> >>>> In my experience it is a rare site that actually needs a rebuild.
>>> >> Why
>>> >>>>
>>> >>>> would we bother with an upgrade path at all if that weren't the
>>> >> case?
>>> >>>>
>>> >>>
>>> >>> I am speaking specifically to third party modules that don't upgrade
>>> >> well.
>>> >>>
>>> >>>> These instances stand out in our mind because that's A) usually
>>> >> when
>>> >>>> they call the consultants in, and B) They're a giant PITA. But as
>>> >> far
>>> >>>> as
>>> >>>> 'always being more cost effective to rebuild' I think that is very
>>> >> far
>>> >>>>
>>> >>>
>>> >>> You are paraphrasing me.  I didn't say always.
>>> >>>
>>> >>>> off the mark. And not a good or true impression to leave a client
>>> >>>> with.
>>> >>>>
>>> >>>
>>> >>> So have you ever found yourself in the middle of a complicated
>>> >> upgrade were you thought, huh, might have been better to just start
>>> >> from scratch?
>>> >>>
>>> >>>> Regards,
>>> >>>>      Sam Tresler
>>> >>>>
>>> >>>> On 02/13/2012 11:21 AM, Christian Pearce wrote:
>>> >>>>> Points well taken.  What ruler do we use to decide quickly if it
>>> >> is
>>> >>>> a simple site that is could be upgraded easily? Sort of doing the
>>> >>>> upgrade to see if it works. For example are you using CCK and
>>> >> views?
>>> >>>> If so then no it isn't worth it?  Or how much content do you have?
>>> >>>> Part of providing value as a consultant is knowing when we should
>>> >> and
>>> >>>> when we shouldn't do something for a customer unless they say we
>>> >> don't
>>> >>>> care do it our way.
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> ----- "Sam Tresler"<sam at treslerdesigns.com>    wrote:
>>> >>>>>
>>> >>>>>> From: "Sam Tresler"<sam at treslerdesigns.com>
>>> >>>>>> To: "A list for Drupal consultants and Drupal service/hosting
>>> >>>> providers"<consulting at drupal.org>
>>> >>>>>> Cc: "Christian Pearce"<pearcec at xforty.com>
>>> >>>>>> Sent: Monday, February 13, 2012 11:08:26 AM GMT -05:00 US/Canada
>>> >>>> Eastern
>>> >>>>>> Subject: Re: [consulting] Feasibility
>>> >>>>>>
>>> >>>>>> I'm not sure I agree with this. It depends on what/how the site
>>> >>>> was
>>> >>>>>> built originally. I've upgraded simple sites along that path (5
>>> >> to
>>> >>>> 6,
>>> >>>>>>
>>> >>>>>> then 6 to 7) in less than a day. More complex sites or sites
>>> >> that
>>> >>>>>> weren't built properly in the first place, the assertion that
>>> >>>> rebuilt
>>> >>>>>> is
>>> >>>>>> cheaper may be true. I don't think this is a blanket statement
>>> >>>> that
>>> >>>>>> you
>>> >>>>>> can say until we know more details about the site.
>>> >>>>>>
>>> >>>>>> Upgrading themes is fairly simple if you follow the well
>>> >> published
>>> >>>>>> step
>>> >>>>>> by step guides.
>>> >>>>>>
>>> >>>>>> I guess my main point is "Upgrades are never smooth" is not the
>>> >>>> case.
>>> >>>>>>
>>> >>>>>> Frequently they are, and when they aren't it's generally due to
>>> >>>>>> problems
>>> >>>>>> that need to be fixed regardless of the upgrade.
>>> >>>>>>
>>> >>>>>> Regards,
>>> >>>>>>       Sam Tresler
>>> >>>>>>
>>> >>>>>> On 02/13/2012 10:45 AM, Christian Pearce wrote:
>>> >>>>>>> (Please don't turn this thread into garbage.  Which tends to
>>> >>>> happen
>>> >>>>>> from time to time.)
>>> >>>>>>>
>>> >>>>>>> Hi Amy, I don't want this to necessarily be about you or turn
>>> >> you
>>> >>>>>> off from our list.  So please accept my advanced apologizes if
>>> >> it
>>> >>>>>> does.
>>> >>>>>>>
>>> >>>>>>> I wanted to get people's thoughts on upgrade versus rebuild
>>> >> from
>>> >>>> a
>>> >>>>>> cost perspective.  Seems to me going from 5 ->     7 would
>>> >> require
>>> >>>> going
>>> >>>>>> to 6 first.  Upgrades are never smooth.  Having to go from 5 ->
>>> >>   6
>>> >>>> and
>>> >>>>>> the 6 ->     7 would be effectively paying for 2 upgrades.
>>> >>>>>>>
>>> >>>>>>> What are the pro's of upgrading?
>>> >>>>>>>
>>> >>>>>>> 1. Site content comes along for the ride.
>>> >>>>>>>
>>> >>>>>>> What are the con's?
>>> >>>>>>>
>>> >>>>>>> 1. More expensive then a rebuild
>>> >>>>>>> 2. Might be forced to redo functionality
>>> >>>>>>>
>>> >>>>>>> Seems to me in either case you need to upgrade the theme to
>>> >> work
>>> >>>> in
>>> >>>>>> 7.  And you are more then likely finding replacement modules for
>>> >>>>>> existing functionality.  So if you are already forced to redo
>>> >>>>>> functionality, might as well put the money towards a refresh.
>>> >>>> Further
>>> >>>>>> I would venture to say on small sites it would be more worth
>>> >> while
>>> >>>> to
>>> >>>>>> redo functionality and redo the content by hand.
>>> >>>>>>>
>>> >>>>>>> Please lets have a healthy, no flame, honest and open opinions
>>> >>>>>> discussion.  Also please don't talk ill of Amy's request.  I am
>>> >>>> sure
>>> >>>>>> several non-profits are in her shoes. And I would suspect budget
>>> >>>> is
>>> >>>>>> limited.  Hence my reason for bringing it up.  What is going to
>>> >> be
>>> >>>> the
>>> >>>>>> most cost effect.
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> ----- "Weinstein Amy"<amy at achildrensbraintumorcure.org>
>>> >> wrote:
>>> >>>>>>>
>>> >>>>>>>> From: "Weinstein Amy"<amy at achildrensbraintumorcure.org>
>>> >>>>>>>> To: consulting at drupal.org
>>> >>>>>>>> Sent: Monday, February 13, 2012 9:46:58 AM GMT -05:00
>>> >> US/Canada
>>> >>>>>> Eastern
>>> >>>>>>>> Subject: [consulting] Please post this job listing on the
>>> >>>> mailing
>>> >>>>>> list...
>>> >>>>>>>>
>>> >>>>>>>> Freelance job opportunity with small non-profit (501c3)
>>> >>>>>> organization
>>> >>>>>>>> dedicated to funding children's brain tumor research.
>>> >>>> Experience
>>> >>>>>>>> required includes Drupal 5, 6 and 7.  HTML, SQL, PHP.
>>> >> Position
>>> >>>> is
>>> >>>>>>>> part time and would require upgrade of existing website from
>>> >>>> Drupal
>>> >>>>>> 5
>>> >>>>>>>> to Drupal 7.  Also, transfer of site from existing host to
>>> >>>> Drupal
>>> >>>>>>>> Gardens.  After upgrade is complete, ongoing maintenance (10
>>> >>>>>>>> hours/week) would be welcomed.  Please respond ASAP to
>>> >>>>>>>> amy at achildrensbraintumorcure.org
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> Thanks!
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> _______________________________________________
>>> >>>>>>>> consulting mailing list
>>> >>>>>>>> consulting at drupal.org
>>> >>>>>>>> http://lists.drupal.org/mailman/listinfo/consulting
>>> >>>>>>>
>>> >>>>>
>>> >>>> _______________________________________________
>>> >>>> consulting mailing list
>>> >>>> consulting at drupal.org
>>> >>>> http://lists.drupal.org/mailman/listinfo/consulting
>>> >>>
>>> >> _______________________________________________
>>> >> consulting mailing list
>>> >> consulting at drupal.org
>>> >> http://lists.drupal.org/mailman/listinfo/consulting
>>> >
>>> _______________________________________________
>>> consulting mailing list
>>> consulting at drupal.org
>>> http://lists.drupal.org/mailman/listinfo/consulting
>> _______________________________________________
>> consulting mailing list
>> consulting at drupal.org
>> http://lists.drupal.org/mailman/listinfo/consulting
>>
>
>
>
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting