The reasons to migrate or test migrate to aMiSTACX are many. Performance, stack control, simplicity, and a possible reduction in hosting costs.
Although there are many ways you can migrate and many different variations, I’ll cover a LAMP migration process that has worked well and is proven. Although this article uses WordPress, the same exact process can be used for Magento.
Important! My blog article assumes you have an intermediate skill level with Linux and basic understanding and experience with the AWS console. If this is all new to you, please hire a professional.
Before you even start, you need to make sure you have all the items my list covered; otherwise, you’ll run into snags.
We will define Host A as your migration source, and Host B as the destination to aMiSTACX on AWS. We will also assume you are using Windows, Putty and WinSCP as your SSH and SFTP clients. If you are using a Mac or other OS, you may have to hack at a solution. As an alternative, uou can also use our Windows Utility Server >> that comes with a bunch of migration tools such as WinSCP and Putty.
Migration Prep List:
* Admin access SSH/SFTP to Host A
* Ability to run Zip on the Host A server
* Ability to dump MySQL on the Host A server
* [Optional] CloudFlare DNS
* Host B SSH/SFTP access as per our aMiSTACX connection docs.
Step 1. Make a Full backup of your Host A before you begin, this also means to include the MySQL database.
Step 2. Clean-up – If you have a bunch of inactive plugins, you can delete them from within the WordPress admin console in order to create a smaller footprint. This also means any log files, caching files, duplicate files, dump files, test files, and anything that doesn’t belong with an operational WordPress site.
Step 3. From your source hosting server zip your WordPress document root. [location will vary – ask your provider if you can’t find it.] It is easier if you set your current directory to one below your target. e.g /var/www/ with your target being /var/www/wordpress
sudo zip -r zipfile.zip directory
e.g. sudo zip -r /var/www/wordpress.zip /var/www/wordpress
Step 4. From within SFTP you can just drap and drop the finished zip file to your local desktop.
Step 5. Dump the MySQL database from Host A.
As there are many ways to accomplish this task, we will present the one that works 9/10 without issue.
From CLI on Host A: mysqldump -u USERNAME -p DATABASE > backup.sql
e.g. mysqldump -u root -p MyHostADatabaseSource > hostAdb.sql
Note: The dump file should go into your connected user’s home directory.
From WinSCP just drag and drop the MySQL dump file to your local device. At this point, you should have both a zip file of WordPress and a MySQL dump file on your local.
Host B Import:
Important! Make sure you have enough disk space before you begin!
On the destination server, Host B, we will assume you already prepared your aMiSTACX stack as per the stack directions. You can and should have a placeholder running for testing purposes. Meaning, DNS or EIP in place, and a functioning site according to your end goal. Even if you have to use a hosts file to resolve DNS, you should have all of this prepared beforehand.
Step 1. Copy your migration Zipfile from HOST A to HOST B. Use the default destination path /var/www/wordpress
Assuming you kept your original test wordpress directory [you should] rename it to wordpress1.
Step 2. Unzip you zip WordPress file using:
sudo unzip /var/www/zipfile.zip -d /var/www/wordpress
Step 3. Reset default user/group permissions to the aMiSTACX default.
sudo chown -R www-data:www-data /var/www/wordpress
sudo chmod -R u+rwX,go+rX,go-w /var/www/wordpress
Importing the database:
Assuming your skill-set is on par with this article, then you can easily change your MySQL credentials if you want for the new host. For simplicity sake we are going to use the same exact settings from HOST A MySQL for Host B MySQL. Luckily for us WordPress keeps this data in the wp-config.php file.
All this means is after you import the MySQL database from Host A to Host B you need to have the user defined in wp-config.php access to the database defined in the same file.
Important! Make sure the database that you are importing is unique; otherwise, you will get an error. For example, the default database on aMiSTACX is named wordpress. More than likely HOST A’s database will have a different name and there will be no conflict during import.
Step 1. Import MySQL Dump File. First copy the dump file from your local device to HOST B’s /home/ubuntu/ directory. Then proceed with the import:
mysql -u USERNAME -p DATABASE < backup.sql
e.g. mysql -u root -p MyHostADatabaseSource < hostAdb.sql
Testing & Troubleshooting:
Assuming all was set up prior, DNS, vhost, and you are using the correct MySQL credentials. All should be working now!
However, should something be not OK, here are some troubleshooting tips gathered from experience.
- .htaccess – Hosting companies [not aMiSTACX] love to put stuff in your document root .htaccess file in a vain attempt to speed things up, and also for other reasons like cpanel redirects. Best to just use a fresh clean one that was provided by the CMS. As previously noted, it is useful to leave the default CMS folder in tact, and just rename it to something like magento.bkup or wordpress1.
- Google PageSpeed Module for Apache – For Magento this may not play nice. Make sure it is disabled. Then after your migration and testing you can re-enable it and then re-test; however, it is NOT recommended that you use Redis and PageSpeed at the same time with Magento. Redis works great and we have Magento stacks running in milliseconds.
- Hard-coded URLs – A nightmare! If your dev is using hard-coded URLs you probably should fire them. It is such a no no, and only in rare cases required. One of the most common issues we come across with migrations, is hard-coded URLs set to the source domain. Fixing them is tedious and very time consuming.
- Hosts File – One of your best friends while testing is to make use of a local hosts file that points to the source domain. This can help you identify hard-coded URLs! You can easily switch between A/B domains too, and a hosts file will bypass a CDN like CloudFlare.