I want to develop our Drupal site on one domain, let's say domain1.com. I then want to transfer the mysql database to another server, which is domain2, change the base url for Drupal, and hit the ground running on domain2. Is this possible? Is it more complicated than what I already mentioned, if so?


meba’s picture

I have done this several times, it's easy...

styro’s picture

Barring any hardcoded domain names users have pasted into comments etc

New to Drupal? | Forum posting tips | Troubleshooting FAQ
Example Knowledge Base built using Drupal

cobbjbc’s picture

Thanks for the quick responses!

ebw’s picture

have foo url, blah db, want bar url, blat db
0. stop apacheN (2 in my case)
1. dump db, in my case mysqldump blah > blah.sql
2. tar up foourl/docroot > url.docroot.tar
3. edit httpd.conf create vhost bar
4. edit bar.tld zonefile, minimally add a record, reload bar zone
5. edit blah.sql, s/foo url/bar url/g > blah.sql
6. create blat db, load blat tables < blah.sql
7. untar foourl/docroot > barurl/docroot
8. make local edits, e.g., sites/foourl -> sites/barurl, the two one-liners in defaults
9. start apacheN (2 in my case)
10. point browser at bar url, restart heart, grit teeth
11. fix broken clean urls, recall /?q= for various points on admin tree
12. start smiling.

signature left on blank check, reward if found

sja1’s picture

Some things you might have to do in order to get everything working properly once you move your site from test to production:

- Clear the cache table: By this I mean drop all the rows in the cache table. You can use PHPMYADMIN, just click the "Empty" tab when viewing the cache table. If you don't do this, there is a good chance some pages will not show properly, even if you have the cache turned off.

- Set up cron: Don't forget to set up cron for the new website.

- Move the download directory: If your download directory is outside the drupal directory, or outside your html root directory (recommended if you have the download method set to "privat" in /admin/settings) don't forget to copy this directory to your production machine. You will then have to go to /admin/settings and change the path specified for your download directory in the Filesystem Options section. While you're at it, check to make sure the path specified for your temp directory exists on the new host (if you're using the default /tmp directory, there's probably no change needed)

- Update data in banner table: If you use the banner module, in 4.6 at least, it stores the absolute path to the banners in the path column of the banner table. You need to go into this table and modify this data so that it is pointing to the production files, not the development ones.

- Update data in the file table: Some modules store absolute paths in the file table as well in certain situations. Check the file table, and if you see there are some absolute paths, you need to modify them to point to the correct location on the production file structure.

- Set error handling option: If you have "Error reporting:" (Error handling section in /admin/settings) set to "Write errors to the log and to the screen" on your development domain, you should consider changing it to "Write errors to the log" on your production system

sja1’s picture

If you use the image assist module, and you select the "html" radio button instead of the "filter" radio button when you insert the image, you will be inserting absolute paths to the images (If I remember correctly) into your pages. This means you will probably have to manually modify all the image tags inserted in this way when you move your site to production (i.e. go live). To avoid this problem, the easiest thing to do is leave the "filter" radio button selected.

sja1’s picture

Paths to user pictures in the "users" table also use absolute paths, so you need to change them as well. The good news is that you can easily change all the entries at once with the following Sql:

- Login into mysql: > mysql -uUser -pPassword
- Specify the new database: mysql> use YOUR_NEW_DATABASE_NAME;
- Run these sql statements to update paths in the users, banner and files tables.
mysql> update users set picture=(REPLACE(picture,'OLDPATH','NEWPATH'));
mysql> update banner set path=(REPLACE(path,'OLDPATH','NEWPATH'));
mysql> update files set filepath=(REPLACE(filepath,'OLDPATH','NEWPATH'));

Here, replace OLDPATH and NEWPATH with just the part of the path that needs to be replaced. For example, if your original path is something like: /var/www/vhost/your-OLD-domain/httpdocs/etc..., and the new one is /var/www/vhost/subdomains/your-NEW-domain/httpdocs/etc...,

Then your sql would look like this: update users set picture=(REPLACE(picture,'your-OLD-domain','subdomains/your-NEW-domain').

if anybody knows of any other tables storing paths that would need to be updated when moving your site, please post them here in a reply.

venkat-rk’s picture

Great tips:-)

But, what happens if you want to use the same database? Just move the install files?

For example, in 4.6, you could create the site on a subdirectory and then move the whole stuff to root and everything would work. In 4.7, because of the base url changes, this won't work, so killes and other experienced drupal developers have suggested creating the site on a subdomain (test.domain.com) and then moving it to root.

saltspringer’s picture

I'm in the same situation; I built a site in a subdirectory, thinking that I could move it to the root and carry on - I seem to remember doing that successfully with an earlier version of Drupal.

Apparently not.

Right now I have just put a referer file in the root pointing to the subdirectory, and it seems to be working okay, but I wonder what is the proper way of moving a site from a subdirectory to the root?

zacamjo’s picture

I developed a Drupal 5.1 site in a subdir (domain.tld/stage). When they were ready to launch, literally all I had to do was move the files out of the subdir and into the public_html root. I backed up the db and all site files first (just in case), then made the move and much to my surprise everything worked fine. Only took a few minutes.

I also hadn't created an image gallery within the site, so that could've been a problem. But everything else went so smooth I was amazed.

stanbroughl’s picture


joshua_cohen’s picture


Lil Devil’s picture

Using a subdirectory on the production machine sounds much easier.

1. Create your test/development site in a subdirectory of the production site, e.g. www.example.com/drupal/

When ready to move the development site to production:

2. Backup, backup, backup!

3. Change the $base_url line in settings.php to remove the /drupal/ part.

4. Drag all folders and files sitting in /drupal/ to the root of www.example.com.

5. If needed, create a .htaccess file that will redirect old urls to new urls, or use drupal's url aliases feature for this. If you really plan ahead well, this can be done as part of step 1 above.

Lots of discussion on this route here.

.carey’s picture

Has anyone moved their subdirectory site to the root directory (on the same domain) using version 4.7.x?

It seems to me there is some confusion on here as to whether or not this is possible with 4.7.x.

venkat-rk’s picture

I think it was advised not to use subdirectory on the same domain as the paths would be a problem (something about 4.7 using absolute paths, I think) and wouldn't be updated unless one used a script.

I remember Killes advising the use of a subdomain for development as this wouldn't have the paths problem when it was moved to the root on the same domain.

.carey’s picture

Well this sucks for me because I've been working on a site for months now and it's in a subdirectory. I did it that way because I read somewhere on here that it was easier that way.

...And just recently I read this for creating a test site, which says put the files in a subfolder, and this on how to go live by moving to root...

So I'm still confused as to what the final verdict is for 4.7.4 in a subdirectory (domain.com/site) and moving it to root.

So what should I do? Any suggestions on what I can do to make it as painless as possible to move it to root? I'm too far along to turn back now.

Lil Devil’s picture

Well I had zero problems when I moved from a subdirectory to root. At the time I had most of the core modules active but only 3 or 4 contrib modules. Since then I've added probably a dozen more.

I haven't really read all the posts warning of subdirectory moves, so I can't say where the problem might be. Maybe some of the contrib modules don't handle the move well?

.carey’s picture

That's quite encouraging. Is it safe to assume your site was 4.7 before the move? (BTW, I checked out your site...interesting....Trash can.)

Lil Devil’s picture

I started with 4.7.3 installed into a subdirectory via Fantastico (yeah I've read all the warnings since then)

After I evaluated Drupal and decided it would work for me, I moved it to root as described above.

Then I added some more contrib modules.

Then I manually upgraded to 4.7.4. I'm hoping this manual upgrade has negated any issues that may have been due to the Fantastico installation, although I must say I haven't noticed any problems.


On a related note, I'm currently in the process of moving another of my sites to Drupal. This time I manually installed directly to root, but I'm playing some games in the .htaccess file to make Drupal appear to be in a subdirectory while the original default files (index.htm) are still used in root. Once the new site is ready for release, I'll just edit the .htaccess file to "move" Drupal to root. After a little more experimentation, I'll write this up as a separate thread.

venkat-rk’s picture

vcarey, I think you would get better answers if you get on to the drupal IRC support channel and post this question. I don't want to mislead you either.

I think it may not be as hopeless as you think:-)

.carey’s picture

Yeah, I should do that. But there is one small problem. I've never used an IRC in my life and don't have the foggiest idea what to do to get on it. Care to lead the blind?

venkat-rk’s picture

I was exactly in the same situation. Basically, you need to download an IRC client. A google search should help. I used mIRC for Windows.

Once you install it, I think you need to subscribe to #drupal-support channel after entering irc.freenode.net as the server. That's it. You will be logged into the channel. Of course, it takes more of fiddling around with the settings than I have described here.

But, if I was able to do it, anyone can:-)

rdodds’s picture

I have just tested to see if i can transfer my drupal install to a new domain. It appears to be working mostly, but it has a few quirks. For example, when i try to log in as the administrator, it attempts to log me in to the old site. If I'm using explorer, i find myself logged in to the new site when i hit 'back'. In firefox, i can hit back then input my details again, then it logs in successfully. Something similar happens when i hit 'logout', and it takes me to the logout screen of the original site.

Can anyone give me some help with this, please?

venkat-rk’s picture

May be it's just the browser cache? Try clearing it out to see if it helps.

Previously user Ramdak.

spyderpie’s picture

I did the same thing and got the same results you are ... In my case, I totally forgot to change the $base_url in the settings.php file. it was still pointing to the old site .... did you check yours?


skromta’s picture

I'm planning to update a site, to do that my plan was to download current database from the production site (no changes will be done) and do all testing/customization on a development site and then upload it to the production site.

What I don't know is if the versions of MySQL used plays any difference, the production site it's v4.1 and on the dev site it v5.x?

Would it work to go from 4.1 => 5.x => 4.1?

(I'll be moving from Drupal 4.7 to 5)

zoon_unit’s picture

Depending on the default ini settings of your Internet provider, you can run into a problem. I'm running a snippet of code that has problems with Mysql 5, so I switched to 4, and my site broke immediately. I finally tracked this problem down to the base_url setting in settings.php.

If you run into this problem, simply uncomment the base_url line in sites/default/settings.php, and then all should be well.