If you’ve ever had to move a Magento site from one server/domain to another, you’ll already know how tricky it can be to get things working right afterwards. The following article describes the processes and steps involved to successfully move your Magento site to a new server/domain name, along with some possible solutions for further issues you may encounter.
1. Package up and/or download the site files
I used my Control Panel’s “site backup” feature here for two reasons: a) you have less to download, and b) you can be sure you have all the files intact when you deploy the other end. If you don’t have this feature with your host, you can manually download the files – but be sure to check you have everything and that there were no errors during the downloading process!
Also, if you have shell access to the server, you can zip up the whole lot and download in one go – this will make it easier to deploy on the receiving end, and will ensure none of the files are corrupted and/or go astray during the upload.
Once I had my package downloaded, I deployed to the new server – again, if you can, upload the zip package and extract via the server. If you are unable to do this, extract the package locally and upload the files manually (cue: cup of tea).
2. Take a backup of the original site’s database
Using PHPMyAdmin, take a full backup of the site database that Magento was using. This should be in the form of a .sql file. Make sure you take a full backup of all the database tables. If the database is particularly large, use compression on the export (built-in to PHPMyAdmin) which will help keep within the file upload limits.
3. Import the SQL file into the new database
Working in PHPMyAdmin on the target server, simply import the SQL file into an empty database (you may need to create one first).
4. Update the live site URL data in the database
This needs to be done in two places in the database. Using PHPMyAdmin, select the table named core_config_data and locate the following database rows:
web/unsecure/base_url
web/secure/base_url
Note the text value for each entry – this corresponds to the root URL of the site. This should be confirmed as the data should reflect the current site’s root URL. To change, simply click the edit button for each of the two rows and input your new base URL value into the text box, saving when you’ve finished each one.
5. Update local.xml with the new configuration details
You can find your local.xml file in the app/etc directory.
Look through the file until you see the database connection information. If will look similar to the following:
<default_setup>
<connection>
<host><![CDATA[localhost]]></host>
<username><![CDATA[my_user]]></username>
<password><![CDATA[my_pass]]></password>
<dbname><![CDATA[my_database]]></dbname>
<active>1</active>
</connection>
</default_setup>
Then change the values in the square brackets after the CDATA tags to your new database server settings, for example:
<username><![CDATA[mynewusername]]></username>
Once done, save the file.
6. Delete the cache data
Simply locate your var folder and delete all content within.
You may also need to manually deploy the .htaccess file from the old site to the new site – so if your links do not work on the new server, make sure .htaccess is present and correct.
Problem 1: MagentoConnect No Longer Works
If you are planning to update Magento Core, any modules, or add new extensions to your Magento site, you will need to correct this since the Connect Manager (/downloader on the server) references the old site, and the links are hard-coded into the files, making it practically impossible to update manually. There is also a real risk of accidentally updating files on the old server if running MagentoConnect (if the old site still exists).
The best way to sort this problem is this:
1. Delete or Rename the /downloader directory
Probably safer to rename this for the time being. You will need to do this via FTP or your control panel file manager.
2. Obtain a fresh copy of Magento
The version number will need to be the same as the version you are running on your site. Download the .zip file and extract locally to your computer.
3. Upload the “clean” /downloader directory
Once you have the extracted files from step 2, find the /downloader directory and upload it to your Magento installation.
4. Run MagentoConnect and perform a core update
You can leave this step for now if you prefer not to update your installation. This will check all core modules and update as necessary, and will also add the missing list of core modules back into MagentoConnect. Paste the following extension key into MagentoConnect Manager:
magento-core/Mage_All_Latest
You can also do this for any extensions you have installed, which will also add them back into the list.
Problem 2: “Notice: Undefined index” Error when running the site
This could be caused by an error during the MySQL import and is possibly related to auto-increments on certain rows in the database.
Try this and see if it fixes the problem:
1. Logon to PHPMyAdmin.
2. Locate the following tables: “core_store”, “core_store_group” & “core_website”.
3. Note the “website_id” value for the admin code. It should have a 0 (zero) value; if not, change it to zero and save. Repeat this for all three tables.
Comment by Rich Y — November 20, 2009 @ 4:28 pm [Link]
Thanks for the help on this…. I copied my magento database using PHPMyAdmin for backup. When trying to copy back, I got the above error undefined index.
Just as clarification…
In core_website: code “admin” should have website id = 0
In core_store: code “admin” should have STORE_ID (and website_id) = 0
In core_store_group: name “Default” should have group_id (and website_id) = 0
That should fix it….it seems so far.
Comment by Dan Luton — December 23, 2009 @ 4:41 pm [Link]
Sounds about right.
If in doubt, compare with the original database tables – they should be the same on both. If not, amend the new import with the old values. I’ve had this issue a few times and this always seems to resolve it.
Comment by Fanny Héraud — January 29, 2010 @ 6:08 am [Link]
Thanks for this neat procedure! I’m almost there!
Any idea why I have been able to correct mentioned table, except for core_store?
When changing admin from 1 to 0, I get : #1451 – Cannot delete or update a parent row: a foreign key constraint fails (`dite6021_testmagento/tag_relation`, CONSTRAINT `tag_relation_ibfk_4` FOREIGN KEY (`store_id`) REFERENCES `core_store` (`store_id`) ON DELETE CASCADE)
Comment by Dan Luton — January 29, 2010 @ 10:13 am [Link]
Hi Fanny,
I’m afraid I’ve not seen this particular issue before – it could be something to do with the way the hosting and/or DB is configured. I would attempt to ask your hosting provider if they have any clues – failing that, a scour around Google may provide some help in figuring out what’s wrong.
Comment by Paul Whipp — March 24, 2010 @ 1:37 am [Link]
Thanks for this useful article, I’d got most of the way but the cache caught me out until google brought me to you.
It is very annoying that magento makes this hard.
When I develop websites I routinely work on a local version and then deploy the changes to the live site (often via a staging site that the client can check before changes go live).
Magento is almost forcing users to risk breaking their sites every time they do anything substantial like loading a new extension etc. …or at least forcing them to do the whole thing twice and hope that they don’t do anything different the second time around.
I can script the cache clearing and the change to the core_config_data. The issues with MagentoConnect and the downloader are more alarming.
Currently all my product images have disappeared in the move and I can’t access the product list in admin even though it works in the front end. Ho hum… onwards…
Comment by Dan Luton — March 24, 2010 @ 10:08 am [Link]
Thanks for your comment Paul, and I agree 100% – it is frustrating (and alarming) as you say. And I find each time presents a new set of problems. It certainly adds a lot of time to a project when dealing with these issues.
Comment by Clair Hewson — March 31, 2010 @ 1:05 pm [Link]
A good tip when installing magento is use administrator rather than admin in the administration URL this will avoid problems down the line
Comment by manthilua — June 23, 2010 @ 3:24 am [Link]
I see that Magento now is quite useful for enterprises which want to build for themselves a professional website. However, installation process is very difficult to do.