Last updated February 5, 2014. Created by jojo21 on August 25, 2002.
Edited by Abby805, karolus, Chimos, LeeHunter. Log in to edit this page.

From time to time, there will be minor updates to Drupal core. If the release is designated as a security update, you should apply the update as soon as you can. Otherwise, you may choose to apply the update at any time to receive the bug fixes it contains. There are also major release upgrades; these you may want to apply so you have all the new and powerful features.

Whether or not you apply a major release upgrade is highly individual to the person responsible for that decision. Upgrading to a new major version usually requires a significant investment of time and work, as a lot may have changed between versions. If everything is working great for you, and you don't want to add any of the new features, you may decide to stick with your current major release of Drupal.

About Drupal versions

What's the difference? Major versions (upgrade) versus Minor versions (update)

Before you start updating or upgrading your Drupal installation it is important that you know the difference between a major and a minor version release.

  • A major version of Drupal core is represented by the number before the first decimal. For example Drupal 5.1, Drupal 6.1, and Drupal 7.1 are all different major releases. This is considered an upgrade.
  • A minor version of Drupal core is represented by the decimal. For example, Drupal 6.1, 6.13, and 6.23 are all different minor releases of Drupal 6. This is considered an update.

You can read more about Drupal's version numbering in our Documentation.

Major releases include changes to core and how Drupal functions. New tools, structure changes, how everything works and looks, can be changed in a major version update.

Minor releases fix security issues and newly discovered bugs but include no new features. This is an example of a minor release announcement.

Minor update procedure

With a minor release update; such as from Drupal 7.1 to the latest Drupal 7.x version, you do not have to apply all the updates that have been released between the versions. You can jump directly from 7.1 to that version. See Update Drupal Core.

Major upgrade procedure

A major release upgrade requires you to first update to the current minor release prior to applying the major release update. If 6.19 is the current version of Drupal 6, and your site is running 6.13, you would first need to update to 6.19 and then apply the update to the current major version 7.

You cannot skip major releases when upgrading your site. This means that if you want to upgrade a Drupal 5 installation to Drupal 7, you must first upgrade from Drupal 5 to 6, and then up to Drupal 7.

When performing a major core update on a complex site (ie. from D6 to D7 or D7 to D8), best practice dictates that you replicate all possible configuration (such as modules and settings) on the new site, then use the Migrate API to migrate data. This is especially true when upgrading from D7 to D8, where the database update system (update.php) can no longer be used.

It may also be useful to review the Comparison of Content and User Import and Export Modules.

Contributing upgraded versions of contrib modules

Maintainers of projects on can get assistance from the change records impacting module developers,, and videos from Drupalcons and camps showing upgrading an example pants project.

Upgrading custom modules on your site

Upgrading your custom modules will involve similar tasks as maintainers of contrib modules go through. So that documentation might be helpful. Some changes will only affect your modules, for example module name length requirements.

Keep up to date on security announcements

It is strongly recommended that you always keep your Drupal site up to date with the very latest minor release available, to remove known security vulnerabilities and existing bugs.

Following are some of the most common ways to stay informed:

  • Your website: Via the Update manager (Drupal 7) and Update status (Drupal 6). Drupal can check for the latest release of core and any installed modules and themes. For more details visit the Update manager (and Update status) page.
  • Security Announcements:
    • Security advisories page: All security announcements are published to this page
    • Security newsletter. Log in, go to your user profile page and subscribe to the security newsletter on the Edit > My newsletters tab.
    • Security advisories feed: You can subscribe to the RSS feed of the Security advisories page.

More information about upgrades


  • If you experience problems during your site upgrade, see the Troubleshooting FAQ.
  • Instead of commenting here, please read the module project page and, if necessary, post an issue or post a message in the forums.
drupal-7.11.tar_.gz2.66 MB

Looking for support? Visit the forums, or join #drupal-support in IRC.


Just wanted to note that you could upgrade Drupal using a Patch File.

Full Details Here: Upgrading Drupal with Patch File

You can also download the patch Files here:

Upgrade Drupal Easier

Haven't tried it myself, but having upgraded Drupal the traditional way, the Patch method seems easier.


Thank you for share. This information is useful for me. In the future I will used Drupal for my website.

Update, 15 April 2010: Drush, the Drupal shell now supports updates of Drupal core via the drush update command for minor updates, and drush site-upgrade for major version upgrades.

drush update will do a minor update in-place on your site. Be sure to always work on a development copy, not your live site! Be aware that drush will replace all of your core and module files with clean copies of the latest release, so you should be sure to save any modifications you may have made to .htaccess and robots.txt files, or other customizations.

drush site-upgrade will copy your Drupal 6.x site to a new document root, upgrading it to the next major version in the process. This process might not work perfectly, but if it does fail for some reason, you can always put off your upgrade and try again when a new version is available.

Try it out; it's fast and easy!

Thanks for the Drush update directions. It went well, but I have a couple followup comments:

1. drush dl download the new Drupal version to the root of my existing Drupal root directory, not the "modules" directory as you indicated.

2. I was nervous about overwriting the "sites" and ".htaccess" files so I removed them from the new Drupal core before running the rsync command.

Do I need to delete them, or does your rsync command keep my original "sites" and ".htaccess" files safe automatically?


Fantastic Greg, this is really cutting down on time taken by upgrades. I launched it once and the Google Analytics module reported an error (cannot redeclare...), but then I launched it another time and it just went well.
The themes were somewhat broken, so I recovered them from the backup directory. This worked for an upgrade from D6.16 to D6.20 and a series of 15 modules.

This comment concerns me. Is the Drush upgrade command really and update command?

-ShuaiBaJ @ developing new content

drush pm-update does a minor update of Drupal (e.g. Drupal 7.11 to 7.12) or Drupal contrib modules. The drush site-upgrade command does a major upgrade of Drupal (e.g. Drupal 6.x to 7.x). Note also that the site-upgrade command has moved out of Drush core, and is now located in the Drush Site Upgrade module.

I need to add one important comment. If you copy a new version onto an old version, make sure that you do NOT overwrite your robots.txt and .htaccess files if you have custom ones.

This happened on one of my recent upgrades in Drupal 5.x and I bombed out both files, and my 301 redirects in .htaccess and disallow tags in robots.txt got lost for a month. Was definitely bad for business, so learn from my mistakes :)

Thanks for the tip. I renamed them to .rel, copied over my .htaccess and robots.txt from remote and used WinMerge to compare new and old versions with ease so I could even update those.

....I fell for this myself to my cost - twice. Never again.

Its easy to do, I get ahead of myself and often make similar mistakes

Wade Mc


Block Cache's functionality is part of Drupal 6 core, so you don't need the module anymore. But they use the same table name.

update.php will fail to create the cache_block table if it already exists. (see

Unfortunately, there's no uninstall option for the Block Cache module, so you will need to manually drop the cache_block table.

Suggested fix if you've already upgraded before dropping the cache_block table is to use Devel module to manually run the create table query.

(This is for upgrading from Drupal 5.x to 6.x. Oops, I should have put it on 6.x tutorial page instead. If a kind admin would move it... thanks!)

"If upgrading from one minor release to another, such as 6.3 to 6.14, jump straight to the latest release within that major version."
What does "jump straight to the latest release" mean? Just delete and substitute all the core modules and do an upgrade, or are there more essential steps to make?

I started with Drupal in 2007 and then my life got stuck...

I think the meaning here is to upgrade in one step between minor releases 6.3 -> 6.14, with no need for 6.3 -> 6.4 -> 6.5 -> etc. On the other hand, for distant major releases, intermediate steps are necessary: 4.x -> 5.x -> 6.x.

The other point related to what you say is the not well documented difference between major upgrades and minor updates, which in fact are much quicker and easier. See for example The current UPGRADE.txt lacks instructions for minor updates (6.x -> 6.y).

Hi thanks Juan_g. What I meant is when upgrading from 6.x to 6.y is it enough to ONLY substitute the directories (cgi-bin, includes, misc. modules, etc...), or do we also have to substitute the (some?) FILES in the root (changelog.txt, upgrade.txt, etc...)???

And while I apreciate that you answer indicating what you THINK is needed, I would for once like to see answers from someone who really KNOWS what is the correct thing to do. Too frequently here at Drupal we newbies have to try to solve problems amongst us based on what we think (deduct) might be a solution and too little I see real solutions from the ones that actually know, make or control.

I started with Drupal in 2007 and then my life got stuck...

This is also a very good page on the upgrade from v5 to v6


I'm working on a local host. So, do I need to upgrade as well to 6.19? I have 6.17 at the moment.
All the steps that I have read seem to be dealing with sites that are already live.

Yes, you should upgrade to 6.19, and you should first upgrade a copy of your site, not the site itself, even if it is not yet live. This will make it easier to roll back if something goes wrong in the upgrade.

Take a look at drush; it makes it easy to copy and upgrade sites with the sql-sync and pm-update commands.

You can use this module to determine your contrib module upgrade-ability!

This is an easy way to work out if you can upgrade, been wanting to update drupal for a while... Thanks for the link...


I am stuck in drupal upgrade.
I have site in drupal 6.19 and i want to upgrade it into drupal 7 .
there are some modules in my site which are not found in 7 .
Can any one help me to upgrade drupal 6 to 7.
A step by step guide...

Thanx in advance

Is there any step by step tutorial or video tutorial to upgrade drupal 6 to 7.
Please help....

Have a look at this video. I think it can help you to know more about upgrading process from Drupal 6 to 7.

Doubt is the father of invention..... Hubmesh | download converter

The Minor update procedure section does not tell me anything useful for an update from 7.7 to 7.8. And there are no links to anywhere else that might tell me something useful. Exactly how do you perform a minor update? What steps are involved? I'm sure there are endless forum posts on this topic. And now I am going to look them up. But I an many others would not have to if this page told us what we needed to know.

Thanks for making Drupal better than it was.

Pete Miller (The Captn)


I don't really think I'm that thick! I'm trying to develop a website using Drupal 7 on my Linux server via my Windows XP PC and have come unstuck.

I've uploaded 7.10 and extracted the files. I've run update.php, and getting an error message from a page called 'Drupal database update' with a progress list saying Verify requirements(done), Overview(done)l Review updates(active), Run updates,
Review log, and in the middle 'No pending updates'
•Front page
•Administration pages
That's where everything stops.

The site status page says that 7.10 has not installed. Reading further, I'm told that I need to remove Drupal core files. There are a large number of these, and I suspect that if I move all these folders and files into another folder on my server, a rerun of update.php will miss all the configuration work I did on v7.4.

The overheads in getting to this point in designing a website, that in principle Drupal seems to be appropriate for, do not seem to be worth the time and effort. I have created pages, users, etc, but new theme modules that I loaded don't work either. I don't really want to use somoeone else's look and feel as I have my own header graphic.

Unless there is anyone out there who can help, or convince me otherwise, I would advise anyone starting out with Drupal, to just use Dreamweaver and load forum software or any other type of software. It would be so much quicker!!!


I don't have oodles of experience with minor updates, so this is probably a naive question. I've always backed up the database as part of that process and I realize it's still part of the recommended procedure. practice, do minor updates usually make changes to the database? Do they make schema changes, value changes, both?

The temptation is to only swap out the relevant files in the directory tree and fire the site back up :) (Having an up-to-date database backup of course) Actually the closer I am to a "throw away" site (for testing interaction of modules, my learning, etc.), the more that backup seems dispensable too.

Any thoughts?

i'm interested to know the answer for this question too,
do minor updates make changes to the database schema?

my newest drupal website: Hebergement web

Just a word of warning to back up your .htaccess file before doing a core update.

I updated from Drupal 74. to 7.12

Everything appeared to go well until I ran the update.php file. At that stage I could not access the website and also notices that the url for the pages were dropping the first letter e.g. (ppearance, onfig) etc. This reminded me that I had made a change at one stage to my .htaccess file.

The problem is that when I uploaded Drupal 7.12 is also overwrote my .htaccess file. Luckily I was able to find a copy of my old one (my ftp package did not download it as part of my backup). and replace it.


"Just a word of warning to back up your .htaccess file before doing a core update."

Mick how do you do this backup?


Thanks for the info! What if i update 7.10 to 7.12 ? What is the best procedure ? I already have plenty of files in my database.

I needed to update my implementation, so using the comments on I came up with this procedure, which worked for me:


My Requirement: Update from 7.12 to 7.14
(get latest drupal version from; for me that's
My Website: mysite (
Drupal Core Folder: public_html
My Situation: I've made changes directly to files (or added files)
I have the 'Backup and Migrate' module installed


0. Make a note of all files you've added or modified in 'public_html'. The best appoach to this is probably to keep a running record of all added / modified files (ie as and when you add or modify a file). If you haven't been doing this:
a) Download drupal core 7.12 to a folder (say coreOrig712) on your PC
b) FTP your current site's core files - public_html on - to a folder (say coreMysite712) on your PC
c) Use a tool such as KDiff3 or WinMerge to compare 'coreOrig712' and 'coreMysite712' and mark the files found to be different or new

Note that in general 3 cases exist:
i) Files that have been added
ii) Files you've modified that haven't changed from Vers 7.12 to 7.14
iii) Files you've modified that have changed from Vers 7.12 to 7.14
The treatment for each is covered in Step 11 below.

1. Local PC: Check the update release announcement (Notes on page) on whether update 7.14 includes changes to 'sites/default/default.settings.php'. In this case, there appears to be some changes to the comments, so I'm taking the answer as 'Yes'

2. Local PC: Unzip '' into a folder called 'coreOrig714'

3. Local PC: Since the answer in Step 1 was 'Yes', create a new 'settings.php' file as a copy of the 'default.settings.php' file in the folder 'coreOrig714/sites/default'. Re-apply to this new file the database-specific changes made to the 7.12 version of the 'settings.php' file

4. Log in as an administrator on

5. Click on 'Configuration > Maintenance mode', select 'Put site into maintenance mode', and click on the 'Save configuration' button.

6. Website Host: Backup DB. I used the Backup and Migrate module ('Configuration > Backup and Migrate') - follow the instructions provided in that module

7. Website Host: Backup 'public_html' (I use my FTP client to download these files to my PC). Strictly speaking, you need backups only of files you've directly changed (outside drupal) or added, but better safe than sorry!

8. Website Host: Rename 'sites' folder to 'sitesMysite' (I use my FTP client to do this)

9. Local PC: FTP all the files in 'coreOrig714' to 'public_html' on my Website Host. Select 'overwrite' for the transfer

10. Website Host: Delete the 'sites' folder, and rename the 'sitesMysite' folder to 'sites'

11. Website Host: Now re-make all the changes you had made in Ver 7.12 ('sites' folder clearly excluded):
i) Files you added in Ver 7.12
Add these files again in Ver 7.14, ie copy these files from your 'coreMysite712' backup to your Website Host
ii) Files you modified in Ver 7.12 which haven't changed in Ver 7.14
Copy these files from your 'coreMysite712' backup to your Website Host. Ensure you overwrite the existing files
iii) Files you modified in Ver 7.12 which have changed in Ver 7.14
I understand this case typically includes files such as '.htaccess', 'robots.txt', etc
Re-apply all the earlier modifications (made in Ver 7.12) to the new files in Ver 7.14

12. Go to - this will run update.php. This will update the core database tables


Caveat emptor: This is the first time I've done this, so there may well be mistakes or unnecessary steps. Corrections are welcome!


(sorry, intended for this general topic, not the previous reply)

Hi, I am new in Drupal. Spent hours on comparing solutions on how to minor update.

About update procedure, I saw many differences and from one another both in Youtube and
Even the update procedure that comes in the update overrides the sites folder!

Here is what I came up with (Gathering from many sources) (comments and error identification welcome):
I have following questions. I hope this will help clean the topic a bit for all the community (at least of new members).

Update a Drupal (Minor update)

1) Download new version in a DISTRIBUTION folder
2) Select Maintenance mode in PRODUCTION site
3) Backup everything from PRODUCTION site to a folder outside of root directory, preferably on a local computer.
4) Paste a copy of this BACKUP site to a TEST site

(Update that TEST site first)
5) Activate only core themes in TEST site
6) Disable core and contributed modules in TEST site
7) Remove all old files in the TEST site EXCEPT sites folder
8) Copy DISTRIBUTION Drupal and modules in TEST site EXCEPT sites folder
(Sites is not deleted in DISTRIBUTION because we may need the new settings.php that is within it)
9) If modified in the past, type modifications in the new Robots.txt, htaccess
(from BACKUP to TEST)
10) If the update says settings.php needs modifications:
Copy the DISTRIBUTION update.php (from sites/default folder) and paste in same place in TEST.
With a text editor, go in the file and set customized value lines that were in old version
11) If any, put added tool softwares in Include folder
12) If any, put added scripts in scripts
13) Put favicon (if you have one) in TEST root folder

14) RUN UPDATE.php as user/1 or http://...yourdrupalsitename/update.php
If unable, in TEST, set Sites/default/settings.php : $update_free_access=True
15) Clear Cache
16) Install and enable contributed themes in TEST
17) Enable modules in TEST
18) Verify Status Reports
(including that $Update_free_access= FALSE) IMPORTANT to set it back to FALSE)

19) If everything is good :
You may delete some files : Installxxx, maintainers, changelog, licence, update.
20) Select Online mode on TEST
21) Copy TEST site to PRODUCTION (that was already set to online mode)

Q1) What happens while in maintenance mode, is there a blackout time when there is no file at all in the folder?
(see Q2)
Q2) Also, my idea is to forbid new activity in sites folder after I took a copy of it, so this is why I set Maintenance mode early in the process.
Q3) Some people are making export of their MySQL in phpMyAdmin. Do we need to do that to?
Q4) In some turorials it says make copy of core and database. Do we really need to do something for the database?
Q5) Is there a more simple way if we install a fresh new distribution and include site folder?
Q6) Some are deactivating modules, others, only copying sites folder in new core distribution and run update)!


No, there is a lot of old wrong information about minor updates out there. Minor updates are much simpler than major upgrades. For example, no need to disable modules for minor updates.

See the file UPGRADE.txt that comes with Drupal, for minor updates and major upgrades.

In the case of major upgrades, a good alternative is:

Drupal-to-Drupal data migration