You can update Drupal 6 and the contributed modules, but you are never finished. Just like the song version by the Eagles, the next time you check status, there will be a version or contributed module that is already in need of an update. If the site uses a large number of contributed modules, the updating job is never done. This unfortunately means that a developer’s job with a site is never done as well. Clients don’t like Drupal maintenance charges, and developers don’t like maintaining test sites and code bases after the site is launched.
I manage a number of Drupal installations. The only similarity between the sites is the core code, the contributed modules and installed text editors vary from site to site. I have looked at multisite installations, but that seems to not work well on shared servers, and may require some tricky DNS work. Multisite installations appear to work best in site-sub sites configurations.
Most of the Drupal sites I build, the client wants the development to end at launch. I routinely put into the letter of agreement on each Drupal project at least 3 months of initial maintenance for training, etc.
With Drupal, those hours for training and small fixes, often rapidly get eaten up with doing version upgrades and contributed module updates. With three of my most recent installed Drupal sites, I had two version upgrades and more than 26 contributed module updates for security in the first 3 months.
Frankly, I am finding that the best method is to allow one day each month for updates and upgrades. I first do any upgrade and then test it on the test server. This means I have to keep the test server going after site launch and keep the build configurations similar. Then test the module and site to ensure that any changes are stable and work for your site configuration. Be sure to check the error report as problems with the database may be indicated.
There are 17 steps in the upgrade instructions on Drupal – http://drupal.org/node/29161 and 9 steps for modules – http://drupal.org/node/672472 – both of these are certainly the safest methods. It is also the most time consuming. There are some simpler, but riskier methods – http://drupal.org/node/816600 – especially if you are upgrading/updating a number of sites. This method upgrades only the core files that have changes in the date stamp and can be installed on top of your already installed base. I found that it works well and simply.
As I learned a couple of years ago, do not update a theme if you have modified the CSS file, graphics or php templates directly. If you make changes to the CSS use a custom theme file for those changes, give graphics unique names and if you modify a template file rename it. Otherwise those changes will be lost in an upgrade.
The question is should developers continue to upgrade/update after the site is launched? The answer is yes and no. If the upgrade is a security upgrade or update, then make the change. If the update is a bugs and fixes for a module, then make the change if time allows. An additional consideration is whether the optional module is part of the page building such as with CCK, views and panels. Here changes can be catastrophic to your page look, so be extra careful.
If all possible, do not leave a Drupal site without an admin. If you plan to leave, after site building and configuration, then train the client’s personnel in how to perform these tasks.
Like in the song, you can check out (of doing more upgrades and updates) to a site after launch, but you can never leave (the security concerns) behind.




