I'm a freelance Drupal developer who loves enabling organizations switch to free and open source software.
Working at the VRT I've had the pleasure of upgrading Toyinima from Drupal 4.6, 16plus.be from Drupal 4.7 and Studio Brussel from 5.1 to the newest Drupal 5.3. These were core-altered installations with a lot of custom and contribute-altered modules. I started of by dividing the non-core modules between those still in their original state to a "contrib" directory and those that were either completely custom or altered in a "custom" directory, to get the following tree structure:
/sites/all/modules/contrib
/sites/all/modules/customI must admit updating the custom modules went a lot faster than I imagined. Drupal 4.6 took by far the longest time with upgrading the forms to the FormAPI as well as updating the theme. What took the most time for all three sites was identifying the alterations done to core, what they were doing and how this could be moved to the modules and templates. The developers did a fine job documenting their changes to core, which made things a lot easier. Some of these changes were patches offered in the d.o issue queue (not necessarily by the module maintainers) as quick bug/security fixes, like this issue for the event module.
Two things to remember:
Upgrading Drupal is not a scary task. People refrain from upgrading because they fear it might fail and break their site. Keep your head cool and make an index of changes that need to happen: divide your modules in altered and non-altered versions, identify any changes made to core and take it one step at a time. There's plenty of good documentation to help you and people in the forum and on #drupal-support are waiting to help you on your way.
Once again, please don't alter core, don't even suggest altering core as a quick fix. The time you win by "fixing" the issue in this manner is lost twice when upgrading later.
Continue reading »