Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Only thing left is our config file. This file contains the encryption key, the user name and password to connect to the database. If the connection parameters are different between your old and new servers, then you need to edit this file to reflect the changes. The editing is straight forward as the password for the database connection is not encrypted. Now, let’s copy that over as well:

  1. cp app/etc/local.xml backup/

Important note about caching! If you are using apc caching (<cache><backend>apc</backend> in local.xml) and are creating a copy of the installation on the same server, you MUST change the <cache><prefix> setting to a new value. The reason for this is that if apc cache is used, magento will save all cache entries in the apc itself instead of /var/cache directory. And the apc cache storage is the same for the whole server, it knows nothing about installations, and <prefix> setting is the only thing that can tell it which website each cache entry belongs to. If you have two sites running with the same prefix, some very strange and hard-to-find errors may occur like data from one shop appearing in another shop’s menus, spontaneous redirects to the other shops’ url in back-end, changing of settings in backend affecting the other installation etc, etc.

Alright, so we have all of the data we need!

If you omit this file in the new server, you will have to go through the setting up process the first time you browse your site in the new server. Here, Magento will make a new encryption key which will cause problems with the credit card information and passwords in the database.

NOTE: If you want to copy your .htaccess or php.ini (assuming you have one) in to the backup directory, now is the time to do it. You don’t need the .htaccess or php.ini file unless you’ve made changes to them. However, if you do want to move them over, run the following command:

  1. cp .htaccess php.ini backup/

Our backup directory will now have the following files in it:

  • local.xml
  • app.tar
  • data.sql
  • media.tar
  • skin.tar

NOTE: Before continuing to move your site make sure that your server has all the necessary software components installed. See the Magento System Requirements.

A couple of tips:

1) PDO for mysql needs to be installed (ubuntu: apt-get install php5-mysql)

2) The curl extension for PHP5 needs to be installed. (ubuntu: apt-get install php5-curl). Without this when attempting to access the admin login you will see a blank page on the server you have transferred the Magento install to.

IMPORTANT NOTE FOR MAMP USERS: You must select PHP 5.2 in the PHP preferences!

We’re ready to set Magento up on the other server now, so SSH in to your account and go to your public_html directory:

  1. cd public_html

We now want to grab all of the files from the other server, but let’s create a backup directory here so we have somewhere to move the files:

  1. mkdir backup

And let’s go in to that directory:

  1. cd backup/

Time to grab the files from the remote server:

You’ll want to replace the above URLs with the IP address or domain name from the old server. Usually whatever domain you had setup on the old server will be the same one you have on the one.

NOTE: If you’ve already updated the DNS nameservers for your domain and it’s pointing to the server we’re moving the files over to, you cannot use the domain name. Use the IP address instead. If you haven’t updated the nameservers for your domain yet, then you can use that.

IMPORTANT SECURITY NOTE: Using the method above you are putting all of your data (including credit card data if you are storing it), your website files and the config file containing your database password on the public internet for anyone to download. If you must use this method, you may want to use something other than /backup as your path, and you will certainly want to delete the files immediately when you have copied them. Consider putting the files in a private folder and copying via SFTP instead.

Alternatively you can do a secure copy (SCP) as below:

  1. scp -r .

Sure this copy will be really secure only if /backup folder is out of /public_html as below:

  1. scp -r .

Now we have all of our files over here. So let’s do a clean install of Magento. We need to go back to the public_htmldirectory, because right now we’re still in the backup directory:

  1. cd ..

Ok, time to install Magento:

  1. wget
  2. tar -zxvf magento-
  3. mv magento/* magento/.htaccess .
  4. mv php.ini.sample php.ini
  5. chmod o+w var var/.htaccess app/etc
  6. chmod -R o+w media

If you haven’t setup a blank database on this server yet, do so now. We’re going to import the data from the dump file in to this database:

  1. mysql -h DBHOST -u DBUSER -pDBPASS DBNAME < backup/data.sql

Replace the values like you did when we created a dump file.

Now we want to initialize the PEAR registry and let Magento update anything in our database that needs to be updated:

  1. chmod 550 ./mage
  2. ./mage mage-setup .
  3. ./mage install community Mage_All_Latest

Lastly, a little bit of cleanup:

  1. rm -rf downloader/pearlib/cache/* downloader/pearlib/download/*
  2. rm -rf magento/ magento-
  3. rm -rf index.php.sample .htaccess.sample STATUS.txt

Almost finished! We just have to move the media directory back in place and the themes:

  1. cp backup/app.tar app/design/frontend/default/
  2. cp backup/skin.tar skin/frontend/default/
  3. cp backup/media.tar .

And we need to extract the data:

  1. cd app/design/frontend/default/
  2. tar -xvf app.tar
  3. rm -rf app.tar
  4. cd ../../../../skin/frontend/default/
  5. tar -xvf skin.tar
  6. rm -rf skin.tar
  7. cd ../../../
  8. tar -xvf media.tar
  9. rm -rf media.tar
  10. cd ..

If your database details have changed from what you had on the old server, you’ll need to edit the local.xml file and update the appropriate information. It should be pretty clear what you need to update in there, all the fields are plain and not encrypted.

So the last thing left to do is to move the local.xml file where it belongs:

  1. mv backup/local.xml app/etc/

To migrate your extensions you need to copy these folders:

  • app/code/community
  • app/code/local
  • app/etc/modules
  • js

You need to edit a few things in the database if your changing domain names or if you’re using a test server that’s just an IP address. Using PHPMyAdmin, Navicat or something similar, connect to the database. Table core_config_data has rows that need to be changed and updated with the new url. For a single store installation you need to just update:

path:                       value:
web/unsecure/base_url       http://[you_domain_here]/
web/secure/base_url         https://[your_secure_domain_here]/

with multiple stores you need also change:

path:                          value:
web/unsecure/base_url          http://[you_domain_here]/
web/secure/base_url            https://[your_secure_domain_here]/
web/unsecure/base_link_url     http://[your_domain_here]/
web/unsecure/base_skin_url     http://[your_domain_here]/skin/
web/unsecure/base_media_url    http://[your_domain_here]/media/
web/unsecure/base_js_url       http://[your_domain_here]/js/
web/secure/base_link_url       https://[your_secure_domain_here]/
web/secure/base_skin_url       https://[your_secure_domain_here]/skin/
web/secure/base_media_url      https://[your_secure_domain_here]/media/
web/secure/base_js_url         https://[your_secure_domain_here]/js/


evisboy on forums provide example of code for MySQL:

  1. UPDATE core_config_data SET value="" WHERE path=’web/unsecure/host’;

Propose: I think ‘web/unsecure/host’ should be changed to ‘web/unsecure/base_url’ in the last line above here.

~ bdugan

That’s it! Open up your browser and your site should be working. If it is, you can delete the backup directory on the new server:

  1. rm -rf backup/

The data on the older server is safe to delete as well.

The above method starts you out with a fresh, clean installation of the latest version of Magento. If you experience problems using this method, there’s another way to copy the data.

Follow the instructions above for creating a MySQL dump file, and leave that in the directory where Magento is installed. Make sure you Refresh or Disable the cache before exporting the database. You can also do an “Export” via phpMyAdmin.

You’re then going to archive the entire public_html directory, so you’ll want to be one directory above the directory where Magento is installed:

  1. tar -cvf backup.tar public_html/

You will then need to use wget like we did before to transfer this file from the old server to the new one. Extract the data from the backup archive we created:

  1. tar -xvf backup.tar

And move it out of it’s directory:

  1. mv public_html/* public_html/.htaccess .

You can remove the extracted public_html directory now. Do not confuse this with the public_html directory for your site, this is only the name of the directory that was in our backup file!

  1. rm -rf public_html/

Now you need to create a blank database and import the MySQL dump file to it. The instructions are listed in the previous method.

Open the new database with phpMyAdmin (or however you prefer), go to the [mage]core_config_data table, and edit theweb/unsecure/base_url and web/secure/base_url (config_id’s 2 and 3) rows to reflect the new URL of the new server.

(Note: some seem to avoid this step by changing the paths to { {base_url} } in the Admin section [System→Configuration→General→Web→Secure and Unsecure] before attempting to move the site, and then changing it in the Admin after the move.)

(Another quick way to deal with the URL changes is to load the SQL dump into Editplus or something similar and search and replace the URLs before importing)

Edit the local.xml (app/etc/local.xml) file and update the database variables if they’ve changed (but keep the same security/encryption key).

Lastly, in order to make magento connect to work correctly edit the pear.ini (downloader/pearlib/pear.ini) and update al the paths that you see in this file. Otherwise magentoconnect will try to upgrade your old site when you use it.

(the files downloader/pearlib/pear downloader/pearlib/peardev downloader/pearlib/pecl may also need the paths updating if you have changed the path)

(Note: Updating this file -pear.ini- is a tedious job, because when you change the paths, you also need the update the field before it which starts with “s:”. You need to type in the length of characters of the path field that you have updated.)

A simple helper script to generate a new the pear.ini file: drop your old pear.ini in the same directory as the PHP script, adjust the paths in the script, open it in a browser and paste the contents into your new pear.ini.

Code Block
header('Content-type: text/plain');
$contents = explode("n", file_get_contents('pear.ini'));
$data = unserialize($contents[1]);
foreach($data as $key => $value) {
    if(is_string($value)) {
        $data[$key] = str_replace('/old/path', '/new/path', $value);
echo $contents[0] . "n";
echo serialize($data);

Note: The code above splits the ini file into lines by detecting the “n” character - depending on the operating system you are running on the correct new line character to split your file may vary.

Make sure there is nothing in the cache directory (var/cache and var/session):

  1. rm -rf var/*

Finally make sure the permissions are still correct on the new server:

  1. chmod o+w var var/.htaccess app/etc
  2. chmod -R o+w media

If you find any errors, make sure folder permissions are set to 755 and file permissions to 644. If your administration submenu pulldowns don’t work, make sure /js/index.php is 644.

That’s it, you’re all done!