NOTE: Please check the comments for relevant information and move this page to the Archive when content has been incorporated into the Upgrade guide.

Preparation:

1) Turn OFF Clean URL's function

FTP Steps: (for downloading and uploading Drupal program files)
Going to assume you have one and know how to use an FTP Client. FileZilla is free and popular. This is pretty easy stuff and you probably already know most of it. If you don't know it: I DO “not” recommend transferring site as your first lesson with FTP'ing.

NOTE: Do not delete old site until you are 200% sure new site is ok.

  1. Download all the Drupal program files from OLD site, to local Hard Drive, using FTP program. (Don't worry about mySQL files yet)
  2. Be sure to get .htaccess too (it's a Hidden File that can be found by checking the View Hidden Files Box on FTP Client.
  3. Edit settings.php and cron scripts to reflect new site.
  4. FTP files to new site

phpMyAdmin Steps: (for mySQL export and import)
We're going to assume you know how to use phpMyAdmin for the basic stuff. This is pretty easy stuff and you probably already know most of it. If you don't know it: I would “not” recommend transferring my site, as my first lesson with phpMyAdmin.

NOTE: Do not delete old site until you are 200% sure new site is ok.

Export:

  1. Find database in phpMyAdmin
  2. Click the Export Tab (we're going to do a dump of data to local hard drive)
  3. In the “Export” box – check “select all” and be sure the radio button is checked for SQL
  4. Check the “Structure” and “Data” boxes
    (this ensures that both the structure of the database and the tables, and the content you have on site - is with you!)
  5. Check “drop table” (so that if the new site is installed already, you can install database on top of that. "drop table" simply ensures that if the table exists - it will be replaced by the one you backed up.)
  6. Check “complete inserts” ( to make sure it does not miss anything when rebuilding the site )
  7. Check “Send” box (this makes the data go to a file instead of the screen)
  8. You can modify the File Name if you wish. (don't recommend deleting anything that might be in the file name box already – just add something to it. I usually add MonthDay – Mar09)
  9. You can check “compression” if you so desire.
  10. Click the “GO” button and you will soon see a pop-up asking you where to save file.

Importing: (with phpMyAdmin)

  1. Find NEW database with phpMyAdmin
  2. Click the tab SQL (just like when you are adding a module)
  3. Go to the “Or Location of the text file:” (just like you would for adding a module)
  4. “Browse” to local hard drive and find file.
  5. Click “GO”
  6. It's going to take a few minutes for everything to come over.

Final process:

  1. Check new site and I do mean check everything, until you're bored
  2. Since I usually do this stuff at night. I check everything that night and then I check once more in the morning. !Checking data is a lot faster than repairing or re-entering data :-)
  3. Turn Clean URL's back on

Problems you might encounter

with phpMyAdmin

  1. phpMyAdmin has some limitations on the size of file that can be transferred. My Host has it set to 10Mb, others might be lower or higher limits. If file is bigger than limits you have to make some choices.
  2. You can save the file as “compressed” (but you might time out on the upload)
  3. You can “Empty” (NOT DROP) a few of tables. Below are some the tables you might want to think about cleaning up before you make data dump. (Not in any order.)
    1. Aggregator Items (the data from news feeds)
    2. Accesslog
    3. Cache
    4. Watchdog
    5. Search_Index

with FTP (still working on this section)

NOTES:

  1. If you run cron make sure to change this also in /scripts/cron-lynx.sh - so it points to cron at new site.

Comments

jefbak2’s picture

jefbak2 commented

Well the poster is right that you should not attempt this if you are not familiar with the process. However I would guess that most Drupal admins would not ever be familiar with a site transfer. We just don't need to do it often enough to keep the steps fresh. So I think more scenarios need to be detailed on this site as I had a lot of trouble searching for answers as I went through the transfer process.

I just completed my first site to site transfer this weekend. I moved a Drupal 5.1 site form a Netfirms shared host to a Go Daddy virtual dedicated server (VDS) environment.

There were some issues.

The first came when trying to import the sql dump into the Go Daddy location. It turns out that the Netfirms implementation of phpMyAdmin (2.4.0) is limited so you don't know what kind of character set the sql file gets in the export options.

On the Go Daddy side; first there was an issue logging into the database with the proper rights. In this case I had to login as Root or setup another user with proper privileges.

When I went to the Import Tab in Go Daddy's phpMyAdmin, the default character set was utf8 and SQL compatibility mode was set to None.

I could not get the file to import and so the head scratching began. First I compared the SQL versions. I was moving from 5.0.24 to 5.0.27. This did not turn out to be an issue. But I tried some of the compatibility options on the Go Daddy database import, but still had no luck with the import.

Finally I opened the file in Notepad++ and checked the Encode setting under the Format menu. It showed ANSI. I switched it UTF-8 and saved the sql file.

The Import worked! Yay, first step out of the way. I realize I could have done a command line ssh dump on Netfirms and probably specified the utf-8 and all that, but I am much or of an Average Joe GUI guy who does not do these kind things all that often. So I shied away from the command line.

I changed the required the need lines in sites/default/settings.php - Note that netfirms used mysqlhost and Godaddy uses the more familiar localhost.
I also had not swithed the dns nameservers yet so I entered the ip address in the $base_url line (I have no idea if I need to do this).

Then I tried to login to the new site at the ip address/public_html/ (in my case). I got the Site is offline for maintenance message and could not login.
Well darn it, now what? True, I had taken the site offline on the old server before doing the file backup and sql dump. So I figured that had something to do with it (once again I don't know). Well another search on drupal.org revealed that I could login by using the address/?=user option. Oh yeah, right - hey that worked, I was able to login under my admin account (the first account setup on the original site).

So no I was into my drupal site on the new Go Daddy site. But the I was told that there were some problems in the status report. Uh-oh...

It turns out that when I restored my site with ftp, not all the directory and file permissions got restored correctly during the copy. I have found of my last 6 months as a novice Drupal admin, that figuring out the proper permissions for the Drupal directories and files can be a headache until you get it right. Then of course you forget about - or if your smart (unlike me) you write it down (I had not). There is no real good document on Drupal.org that I could find that explained the right permissions, so I ended up changing the /tmp and /files directories to 777. This was the only setting that would make the status report error go away, which is strange, because on the old Netfirms host I used 775 without a problem. (another I don't why this is issue).

My final hurdle concerend the Garland Theme (which this site uses) and the css style sheets. After the site transfer some of the pages where displaying without any css formatting. Yet another search on Drupal.org did not turn up any solutions to this (however my search terms are not always the best). In the end, I deleted all the css files in my /temp directory. I turned off the css aggregate performance option (caching is set to Normal and not changed). Then I changed all the Garland and css related files under the /files directory to, yes, 777.

Then the Garland theme started working again and turned css aggregate back on.

After testing the site for a few hours and switched the nameservers to the Go Daddy site.

The result is a much faster drupal site. Netfirms used a shared sql server farm and Go daddy uses it's own on the VDS setup. So now I have access to php.ini settings that where not available on the Netfirms site and all that.

Sweet! It took me awhile (6 hours) and as you can tell I am no expert, but I did manage to transfer the site. I hope this summary is of help to some other novice like me in the future.

doomed’s picture

doomed commented

I just finished moving a Drupal 5 website from my test machine to a new server.
Domain names and paths are completely different but all I had to do was:

1. Disable Clean URLs (Administer / Site config / Clean URLs)

2. Clean logs and stuff (Administer / Site config / Error Reporting)

3. Make sure the temporary files folder is configured correctly (Administer / Site config / File system)

4. Upload all files to my new webhost via FTP

5. Edit settings.php and insert new Mysql user/pass for the new server

6. Export the data from Test server:
http://doomed.ptarena.net/pics/drupal_transfer_01_phpmyadmin_sql_export.png

7. Import on the Real server:
http://doomed.ptarena.net/pics/drupal_transfer_02_phpmyadmin_sql_import.png

8. A quick comparison of the tables from both databases just to be sure:
http://doomed.ptarena.net/pics/drupal_transfer_03_phpmyadmin_sql_compari...

9. Logon to the new site, enable Clean URLs again and check everything.

That's it. Success! (afaik)

Some details:

My test server:
Windows, XAMPP, PHP 5.2.5, MySQL 5.0.51, PHP MyAdmin 2.11.3 .

My webhost:
PHP 4.4.7, MySQL 4.1.22, PHP MyAdmin 2.11.4 .

ron_mahon’s picture

ron_mahon commented

Thanks
for the nice job of laying out the steps.
I have been more or less following the same learning curve. Recently I modified my procedure to use the backup utility in cpanel. Mysql tables were getting two large.

On the multi sites i have a problem with making changes in user access. They appear to work, but after submitting them there back to the original settings.
have you have any experience with this/

Regards
Ron Mahon
Alias "Link" at
http://The-Villages-Online.com

doomed’s picture

doomed commented

You're welcome.

But unfortunately i can't help you with that question.
I think taking it to the forums will get you more exposure.

doomed’s picture

doomed commented

I would like to add some extra steps to do after the move (on the new server).

10. Disable errors on screen (Administer / Site config / Error Reporting)
11. If you are using Img Assist, empty the filter cache to correct image paths (Administer / Site config / Image Assist)

koyama’s picture

koyama commented

3. Make sure the temporary files folder is configured correctly (Administer / Site config / File system)

I ran into some annoying behavior of Drupal 6 after transferring a site from my local Windows machine (developed using XAMPP) to a shared web hosting provider using Linux (in this case DreamHost).

The temporary directory used by Drupal on my local Windows machine is C:\xampp\tmp. For the new site on Linux the temporary directory needed to be /tmp.

After transferring the site I could change the directory by going to (Administer / Site config / File system) and replace "C:\xampp\tmp" with "/tmp".

But as soon as I landed on that page Drupal would apparently see that "C:\xampp\tmp" directory was missing and decide to create it directly in the Drupal root.

"The directory C:\xampp\tmp has been created."

http://img40.imageshack.us/img40/5332/adminsettingsfilesystem.png

I was therefore stuck with a directory in the root of the Drupal installation called "C:\xampp\tmp" as you can see in this screen shot.
http://img40.imageshack.us/img40/7635/winscp.png

It was very annoying to have such directory "C:\xampp\tmp" in the Drupal root. It couldn't even be deleted using an FTP client because of the backslashes in the directory name (which apparently can't be handled with the FTP protocol?). I could remove it again was via the shell using the command:

>rm -rf C:\\xampp\\tmp

http://img46.imageshack.us/img46/5195/putty.png

Alternatively, if one doesn't have shell access, it can also be deleted using FTP if one first renames it to something suitable via a simple PHP-script:

<?php
rename('C:\xampp\tmp', 'dummy');
?>
doomed’s picture

doomed commented

Thanks for describing these steps!

But what i usually do on my Drupal installations is set the regular files folder as "files" and the temporary files folder as "files_temp"

That way, they reside in the main Drupal folder, side to side, and easier to locate/backup/whatever if needed.

rucativava’s picture

rucativava commented

Just wanted to thank doomed for the working tip.
Thanks :)

ndtrost’s picture

ndtrost commented

2. Clean logs and stuff (Administer / Site config / Error Reporting)

How can I do this outside of the admin? Would emptying the watchdog table in the database do this? Are there other things that would need to be cleared?

jayabee3’s picture

jayabee3 commented

Hi Doomed

3 years later - I hope you are still there and going strong? So I am now at the point you were at 3 years ago - Your instructions look great - It should wor that easily - but those are all the steps I have followed up until now. I always fall down at the 7th Hurdle. Here is my post:

http://drupal.org/node/1135640

I wonder if you have any ideas what I need to do to correct the problem?

My site URL is: http://www.jennybeecroft.com/drupal-7.0/ so you can see what the error message currently reads there

Another point to mention is that if you add 'install.php' to the end of the above URL that loads.

I hope you can help

Many Thanks
jayabee

mrogers’s picture

mrogers commented

I had trouble importing my database. Turns out the problem was the 'Remember Template' checkbox that was checked when I initially dumped my database. Unchecking the 'Remember Template' box fixed everything.

mistersender’s picture

mistersender commented

Thanks for the great tutorial! I just wish I had found it sooner... I successfully got my site transferred, and everything was working just fine until I needed to make a minor change to one of my content types. As soon as I changed the content type, I could no longer access ANY of my content type editing... it just keeps redirecting me back to the content management page. Same problem when I edited a view... the site still works, but I can't edit anything.

I would hazard a guess that this has something to do with me not turning off clean urls when I transferred the site, but I am totally lost as to how to fix this issue now. I still have my original site, but I can't re-upload it as there have been a lot of content additions. Any advice would be super!

Stomper’s picture

Stomper commented

Thanks for the tips and guide. I will be tackling this soon. What is the issue with Clean URLs? Is that the only module we need to disable before transferring?

doomed’s picture

doomed commented

Puting your site in Maintenance mode
Disabling clean-urls

That's more of a standard procedure to prevent problems in general, better safe than sorry.

S.Wan’s picture

S.Wan commented

Hi, Thank you for your induction of transferring test site to the server.
I've done it following your steps, including put files on the server via FTP, change settings of settings.php, export database, import database.
Then when I want to access my site through the server, it shows blank page where nothing displays.

Any idea about this?
Many thanks