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.

There are 18 awesome comments...

1. 

   Rich Y - November 20, 2009 at 4:28 pm

   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.
2. 

   Dan Luton - December 23, 2009 at 4:41 pm

   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.
3. 

   Fanny Héraud - January 29, 2010 at 6:08 am

   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)
4. 

   Dan Luton - January 29, 2010 at 10:13 am

   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.
5. 

   Paul Whipp - March 24, 2010 at 1:37 am

   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…
6. 

   Dan Luton - March 24, 2010 at 10:08 am

   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.
7. 

   Clair Hewson - March 31, 2010 at 1:05 pm

   A good tip when installing magento is use administrator rather than admin in the administration URL this will avoid problems down the line
8. 

   manthilua - June 23, 2010 at 3:24 am

   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.
9. 

   shashank - August 24, 2010 at 7:37 pm

   i have clone a magento store , frontend is working fine , in backend when i enter login and password then it shows this link is broken , please help on this.
10. 

    Magento Development India - December 29, 2011 at 9:59 am

    I have successfully configured Magento. Thanks for such great help.
11. 

    atwix - January 23, 2012 at 3:22 pm

    Thanks for the useful information. You’re welcome to check out our article on the similar topic posted here http://www.atwix.com/magento/moving-magento-to-another-server/ and leave your feedback.
12. 

    Cameron - May 7, 2012 at 3:15 pm

    You are a boss. This got me out of a pinch. This is just the cat’s pajamas.
13. 

    breast feeding of - February 25, 2013 at 12:09 pm

    Pretty! This was a really wonderful post.

    Thank you for providing this info.
14. 

    The 54 Most Useful Magento Articles of All Time | @nexcess - June 26, 2013 at 5:14 pm

    […] Moving a Magento Installation […]
15. 

    François - September 15, 2013 at 2:15 pm

    Thanks alot for this tutorial, you saved my life!
16. 

    boduk - July 20, 2014 at 3:23 pm

    in magento 9 no database configuration when you transfer the site
    like it?
17. 

    boduk - July 20, 2014 at 3:24 pm

    i mean magento 1.9
18. 

    Nexcess.net, LLC | Business Insider - October 3, 2014 at 5:55 pm

    […] Moving a Magento Installation […]

Leave a comment: