Site to site transfer with phpMyAdmin and a FTP Client
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.
- Download all the Drupal program files from OLD site, to local Hard Drive, using FTP program. (Don't worry about mySQL files yet)
- 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.
- Edit settings.php and cron scripts to reflect new site.
- 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:
- Find database in phpMyAdmin
- Click the Export Tab (we're going to do a dump of data to local hard drive)
- In the “Export” box – check “select all” and be sure the radio button is checked for SQL
- 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!) - 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.)
- Check “complete inserts” ( to make sure it does not miss anything when rebuilding the site )
- Check “Send” box (this makes the data go to a file instead of the screen)
- 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)
- You can check “compression” if you so desire.
- Click the “GO” button and you will soon see a pop-up asking you where to save file.
Importing: (with phpMyAdmin)
- Find NEW database with phpMyAdmin
- Click the tab SQL (just like when you are adding a module)
- Go to the “Or Location of the text file:” (just like you would for adding a module)
- “Browse” to local hard drive and find file.
- Click “GO”
- It's going to take a few minutes for everything to come over.
Final process:
- Check new site and I do mean check everything, until you're bored
- 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 :-)
- Turn Clean URL's back on
Problems you might encounter
with phpMyAdmin
- 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.
- You can save the file as “compressed” (but you might time out on the upload)
- 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.)
- Aggregator Items (the data from news feeds)
- Accesslog
- Cache
- Watchdog
- Search_Index
with FTP (still working on this section)
NOTES:
- If you run cron make sure to change this also in /scripts/cron-lynx.sh - so it points to cron at new site.
Real Life Site to Site Summary
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.
Drupal moving
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....
7. Import on the Real server:
http://doomed.ptarena.net/pics/drupal_transfer_02_phpmyadmin_sql_import....
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 .
Site Transfer
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