Note: If you need to migrate Magento, please review this post.
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.
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 contact us as we offer migration consultancy services.
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, you 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.
Migration:
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 magento > 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. This may come in handy later if you need files, do a compare, or restore to a known working version.
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 magento < hostAdb.sql
Note: If you are importing to AWS RDS, you need the following format:
mysql -u {username} -h {RDS Endpoint Address} -p {DATABASE} < hostAdb.sql
Tip: If you encounter “Access denied; you need (at least one of) the SUPER privilege(s) for this operation” during your RDS import, then please review the fix here.
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.
-
-
-
- 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.
- Permissions – Reset permissions to baseline.
- Google PageSpeed Module for Apache – We now consider this module as obsolete. aMiSTACX favors Redis and S3R-Alpha and the WP Fastest Cache plugin.
- .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.
- 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.
-
-
Post Migration
If you are using an S3 Titanium stack you’ll want to copy the plugin over and a few files. This assumes you followed the above instructions, and kept our original structure, and renamed the directory to wordpress1 and you have a new wordpress folder. As follows:
1) In your new wp-config.php, copy and paste this line at the bottom:
define('WP_TEMP_DIR', dirname(__FILE__) . '/wp-content/temp/');
2) Create a folder called temp in /wp-content/ [or copy the one using duplicate WinSCP function]
3) Create a new file in /wordpress/ called db-config.json
Have contents from the very top as:
{
}
4) Copy the plugin amistacx-wp-s3-titanium to /var/www/wordpress/wp-content/plugins [or copy the one using duplicate WinSCP function]
5) [Optional] Copy any of the other 3rd-party recommended plugins to new site.
6) Set permissions to baseline:
sudo chown -R www-data:www-data /var/www/wordpress
sudo chmod -R u+rwX,go+rX,go-w /var/www/wordpress