[development] Getting rid of core hacks for drupal upgrade to happen. Need tips on the process.

[Yuval Hager]

On Thursday 01 April 2010 17:35:52 Laura wrote:
> So consider wiping the code base entirely (not the database, though) and
> re-implementing in Drupal 6. If your D5 hacks did not result in
> alterations to the database structure, you can simply perform a stock D6
> upgrade process and then implement through contributed modules and a new
> or refactored theme the various end results those hacks were trying to
> achieve. This way you can embrace what D6 offers first before resorting to
> coding up custom module implementations.

This is really the only viable option. I have been "burned" on such a project 
just recently. 

We quite quickly understood (and communicated to the client) that a complete 
wipe and re-implementation would be around the same price for the client, but 
will create a beyond compare higher quality product. However, the client have 
invested a lot of money in the D5 hacks crapware, that they were having a hard 
time deciding to wipe that completely. It was pure politics based decision, 
but c'est la vie.

The approach we took was to diff the whole thing, as you suggested ('diff -
aurwp drupal-5.2 drupal-5.2-hacked' if you are on linux)  and study carefully 
all the differences. It is quite reasonable that core tables where hacked too 
(they were in my case), some even beyond any chance of cleaning up. 
That project went on for 7 months. The goals to stabilize the site (it crashed 
every two hours), make response time reasonable, and clean up the code base. 
The last task was the least important, and sometimes, I just had to keep the 
hacks in there, for reasons of cost vs. gain.
At project end, the client received a bit less of what he should have had 7 
months ago - a (mostly clean) Drupal 5.x install, with clean CCK, views, 
panels and a few other central modules. With this, the client could work 
further and start building features on top of that - but I am not involved any 
more there.

So before you dive in, if you are in position to, consider to make this a make 
D6 or break decision to the customer. Depending on the amount of hacking done, 
but you'll probably spend hours on hours just to bring stuff to work as it 
should have in the first place. If you can't make it a clean D6, then good 
luck - you'll need all the luck you can get. 
Don't forget the other parts of core that do not ship with it - views and CCK 
were probably hacked too - as well as any other module in your project. From 
looking at the code I found that hacking core is a bit like stealing. If you 
don't get caught in the first time, you are tempted to continue on and on, 
until you really can't stop.

--yuval