The reasons to migrate or test migrate to AWS, and deploy via aMiSTACX are many. Performance, stack control, simplicity, and a possible reduction in hosting and operational 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 there is no direct port of WinSCP to Mac.]
As an alternative, you can also consider deploying a utility stack that leverages Microsoft’s Windows RDP. The utility stack has many advantages. With RDP you can keep a session running and walk away from your computer. Plus, the Windows RDP server will leverage the AWS backbone infrastructure, and increase transfer rates at multiples of Gbps.
For Magento 1 CE to Magento 2 OSE, consider using our stack designed for Magento migrations. This stack includes most PHP versions and can support both MySQL 5.7 and MySQL 8.
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 but recommend] 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 prior to migration. This also means any log files, caching files, duplicate files, dump files, test files, and anything that doesn’t belong with an operational Magento production site. Cleaning up now creates a smaller migration footprint.
Step 3. From your source hosting server zip your Magento 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/magento
sudo zip -r zipfile.zip directory
e.g. sudo zip -r /var/www/magento.zip /var/www/magento
Step 4. From within SFTP, you can just drag-and-drop the finished zip file to your local desktop, or to the RDP server.
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. e.g., /home/ubuntu/
Note2: You may get a dump warning about GTIDs. Append
--set-gtid-purged=OFF to your mysql dump statement.
From WinSCP, just drag-and-drop the MySQL dump file to your local device, or to the RDP server. At this point, you should have both a zip file of Magento, and a MySQL dump file on your local.
aMiSTACX Host B Import:
Important! Make sure you have enough disk space before you begin. The zip file will decompress, and you’ll have both the original and the zip on the drive at the same time.
On the destination server, Host B [an aMiSTACX deployment], we will assume you already prepared your aMiSTACX stack as per the stack directions. You can and should have a placeholder of Magento Open Source 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/magento
Assuming you kept your original test magento directory, [you should] rename it to magento1. This may come in handy later if you need files, do a compare, or restore to a known working version.
Step 2. Unzip your zip Magento file using:
sudo unzip /var/www/zipfile.zip -d /var/www/magento
Step 3. Reset default user/group permissions to the aMiSTACX baseline default.
sudo chown -R www-data:www-data /var/www/magento
sudo chmod -R u+rwX,go+rX,go-w /var/www/magento
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 [aMiSTACX]. For simplicity sake, we are going to use the same exact settings from HOST A MySQL for Host B MySQL. Luckily for us Magento keeps this data in the /magento/app/etc/env.php file.
In other words, whatever credentials you use for the database import, will need to be defined in the env.php 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 magento. More than likely HOST A’s database will have a different name, and there will be no conflict during import.
Step 1. Using phpMyAdmin or MySQL CLI, create an empty database that matches the name of your export from host A.
Step 2. 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. The reset is in the stack guide. Also new deployed Magento Open Source stacks have a script in doc root /magento/ called amistacx.sh
- .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 Magento 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 magento1.
- 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.
If you need some help, ping human support, and we will see what we can do. We usually can point you in the right direction. Oh, and review some post deployment/migration tips. They will be helpful
~Lead_Robot