We have started using Drupal as a PHP programming framework (and not just as a CMS). As result, we have many projects running on Drupal (6 or 7).

Typically, after 2-3 years a project gets over and no further development is done on that project. Then, we put that project into a maintenance or dormant mode.

The problem is that at the end of a project, there is hardly any money left for actively maintaining (e.g updating modules/core for security fixes) that project for over a period of say 10 years. And, there is no way that we can ask for maintenance money for a project (this is a sad fact).

So, we were brainstorming what would be the way to maintain Drupal sites securely for say a period of at least 10 years.

Some ideas were:

  1. Convert entire Drupal site into bunch of static pages using some tool (I suspect this might break lot of interactive functionality in Drupal)
  2. Lock down write access to MySQL database
  3. Run dormant Drupal based sites in a Virtual Machine
  4. Block all input fields on a Drupal site including login functionality (i.e make all content publicly accessible)

I also expect that in a period of 10 years following things might happen:

  • A server's hardware might be upgraded
  • A new PHP version might be installed
  • A new MySQL database might be installed
  • A server's OS might not be supported by a vendor for security updates
  • Certain Drupal modules may not be supported or may get deprecated by an other module
  • In the worst case, the required PHP or MySQL versions itself may not be supported by the community

What are the ways/strategies to securely maintain (i.e. keep them running) dormant Drupal sites for a very long period?

  • Just throwing this out there...add read-only to /etc/my.cnf and restart mysql. DB will never change anymore. Apr 22, 2011 at 15:06
  • Even support for an LTS release for you server will only last 5 years at the most - you'd be far better off to have an upgrade plan in place for the sites.
    – HorusKol
    Apr 26, 2011 at 23:56

5 Answers 5


Like you mentioned there are many moving parts about Drupal that can require maintenance, so your strategy should be to remove as many dependencies as you can within your requirements.

If it is not a requirement that your Drupal sites continue as dynamic systems where content can be created, updated, or deleted then you should remove MySQL and PHP by generating static files. There is good documentation for creating static archives of a Drupal site at http://drupal.org/node/27882.

Since you mentioned putting the site into a "maintenance or dormant mode" it sounds like a static solution would be the best for you.

If you require the continual functional use of the site you could consider moving the site to a managed solution. Managed hosting providers can take care of the web and database server, but for further management of the Drupal code you could consider a service like http://drupalgardens.com.


This question is a bit absurd. Drupal itself is barely 10 years old--how many Drupal 1 sites are still running? How many sites are there today, running PHP 1.0 (released in 1995, 2.0 in 1997)? What hosting providers running PHP 1.0 in 1996 are still in business today, dutifully serving those abandoned projects on un-upgraded hardware and software to whomever is still interested?

The internet is not static, nor is the technology it runs on. The best bet of finding sites from 1996 that were abandoned, is to use the Internet Archive Wayback Machine on http://web.archive.org.

I would tell you to completely export everything to HTML and keep it static, but even this is no guarantee (the first Apache HTTP server was only a year old in 1996).

  • 2
    This is all true and important perspective, but the Internet has gotten a lot more stable in that time as well. I think this is a pretty reasonable request these days.
    – greggles
    Sep 20, 2011 at 15:39

As for the DB Layer, MySQL should be upgraded to keep pace with current technology.

As a MySQL DBA, I can see MySQL changing as fast as Oracle can push it. MySQL 5.0 has reached EOL and MySQL 5.1 is soon to follow. You would want support for the latest release MySQL to always be there for you. Of course, you have the MySQL Community to lean on. You also have Percona, who makes tight, faster running, and performance-blinding binaries of MySQL. You even have the up-and-rising company SkySQL, who supports everything MySQL back to 3.23.58.

I would continue the upgrade path of MySQL by means of using another dev server to test the functionality of the Drupal against the MySQL upgrade. Once done, upgrade the "production" dormant MySQL for Drupal.


Why not migrate the sites to a cloud server, and then write the entire server+OS+Drupal_stack+entire_site to a file. As a cloud server, the entire thing is virtual anyway, so the versions of all your software, OS and everything dependant on everything else is wrapped up in a nice shrink wrapped, forever executable file. 'New users' could have a private instance of the site where they do whatever they want with it, because one can always return to a new instance of the original/official backup. You could have a version of the site with 'original user data' as well as one with 'current user data', which could be interesting depending upon what data the sites hold (after 10-15 years).


Actually, there's not a safe way to do this automatically...

bjeavons had exposed good ways to keep the site static, but if you intend to keep the site fully functional in a usual environment, certainly, the best way, is keeping your environment as is, 'freezed', and you will have your site functional for more than 10 years. Any changes in your server, you must be sure to not impact in your site functionality, and if so, you should have an action plan, and this would only be possible creating another server layer, and you should test everything over there before applying it in production to guarantee its fully functionality.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.