Migrate a website from shared hosting to Lightsail step by step

Shared hosting is a good place to start: cheap, with a panel, with email included and with someone maintaining the server. It stops being so when the website grows and gets slow, when you need to install something the panel does not allow, or when the "higher plan" they offer you costs more than a machine of your own. A Lightsail machine gives you a whole server to yourself for a fixed monthly price.

In return, nobody looks after it for you: updates, backups and security become your job. And there is a trap many people fall into: shared hosting usually carries the email. If you change the DNS without thinking about that, the website works and the email disappears. The migration goes in the safe order: new machine, copy of everything, test without touching the domain, DNS change with an easy way back, HTTPS, email and, only at the very end, cancel the old hosting.

Step by step

1. Decide whether it is worth it and which blueprint to use

   It is worth it if the website is slow and the hosting talks about "excessive resource usage"; if you need a version of PHP or a tool the panel does not have; if you have several websites and they charge you for each one; or if the higher plan costs more than a Lightsail machine. It is not worth it if the website is a brochure page with a hundred visits a month: there, shared hosting does the job.

   If the website is WordPress, use the Lightsail WordPress blueprint: the migration comes down to a plugin. If it is something else (a custom PHP website, Joomla, PrestaShop, several sites), use the LAMP blueprint, which comes with Apache, PHP and an empty MySQL/MariaDB. Plan: for a website that was running tight on shared hosting, 2 GB is the reasonable minimum; with a shop or several sites, 4 GB. You can always upgrade later with a snapshot.

   Before touching anything, write down: where the domain's DNS is (usually the same hosting), where the email is (almost certainly the same hosting), the version of PHP the website uses now and the space taken up by files and database.

2. Create the machine and prepare it

   In the Lightsail console, Create instance, nearby region (Paris or Ireland for Spain), WordPress or LAMP blueprint, plan, name (web-empresa). When it is running, Networking tab, Create static IP and attach it. Add the HTTPS (443) rule to the firewall if it is not there. Write down the static IP.

   Check the PHP version: click Connect using SSH and type php -v. If your website needs an older version, be prepared to fix warnings; it is better to know beforehand. And download the machine's key to upload files: Account menu, SSH keys, Download the default key for your region (a .pem file). Keep it somewhere safe.

3. Export files and database from the old hosting

   In the hosting panel (cPanel or Plesk), open the File Manager, go into the website folder (public_html or httpdocs), select everything, Compress into a zip and Download. If it is several GB, better with an FTP client like FileZilla, which resumes if it is cut off.

   The database: in the panel, phpMyAdmin, select the website's database (the name is in wp-config.php or whichever configuration file it is), Export tab, quick method, SQL format, Go. Download the .sql. If it is hundreds of MB, phpMyAdmin may cut off halfway: use the panel's backup tool.

   If it is WordPress, there is a shortcut: install a migration plugin (Duplicator, All-in-One WP Migration) on the old WordPress, export a package and save it. It does files and database at the same time and fixes the internal addresses. On large websites, the free version has size limits.

4. Import on the new machine

   With a plugin (WordPress): open http://IP-estática/wp-admin, log in with the user user and the password shown by cat bitnami_application_password in the terminal, install the same migration plugin and import the package. When it finishes, the new WordPress is a copy of the old one, users included. Jump to the next step.

   By hand (LAMP or WordPress without a plugin): in FileZilla, File, Site Manager, new site, protocol SFTP, host the static IP, user bitnami, logon type "Key file" with the .pem. Upload the website contents to /opt/bitnami/apache/htdocs (LAMP) or to /opt/bitnami/wordpress (WordPress blueprint, replacing what is there), and the .sql to the home folder. In the terminal, create the database and import:

   mysql -u root -p -e "CREATE DATABASE miweb;
     CREATE USER 'miweb'@'localhost' IDENTIFIED BY 'una-contraseña-larga';
     GRANT ALL ON miweb.* TO 'miweb'@'localhost';"
   mysql -u root -p miweb < copia.sql

   The root password is the one in the bitnami_application_password file. Then edit the website's configuration file (wp-config.php or whichever it is) with the new database name, user and password, and localhost as the server. If the website stores its address in the database (WordPress does), leave it with the real domain: you are going to test it with the hosts file.

5. Lower the TTL and test with the hosts file, without touching DNS

   Go to the domain's DNS (at the old hosting or at your registrar) and find the A record for the domain and the one for www. Do not change the IP yet; change only the TTL to 300 seconds. If it was at 3600 or 86400, you have to wait that long before the IP change is noticed quickly: do it today and change the IP tomorrow.

   Meanwhile, test the new website as if it were already on the domain. Edit your computer's hosts file as administrator: on Windows, C:\Windows\System32\drivers\etc\hosts (with Notepad run as administrator); on Mac, sudo nano /etc/hosts in Terminal. Add a line at the end with the static IP and the domain:

   203.0.113.10 midominio.com www.midominio.com

   From that moment, only your computer sees midominio.com on the new machine; the rest of the world is still on the old hosting. Open a private window and go through the website: home page, inner pages, forms, the admin panel, uploading an image. The browser will warn that there is no padlock: that is expected, it is fixed in step 7. If something fails, you fix it calmly while visitors are still on the old one. When everything is fine, delete the line from the hosts file.

6. Change the DNS and freeze the old website

   Change the A records for the domain and for www to the Lightsail static IP. Do not touch the MX records or the TXT ones (SPF, DKIM): they are the email, step 8. With the TTL at 300, within ten or fifteen minutes most visitors are already arriving at the new one.

   If the website stores user data (orders, comments), there is a period when some write to the old one and others to the new one. To avoid it, just before changing the DNS put the old one in maintenance mode and take one last export of the database to import into the new one. For a brochure website this is not needed.

   Check from your phone on mobile data (no wifi) that you reach the new one. In the machine's terminal, sudo tail -f /opt/bitnami/apache/logs/access_log shows the visits arriving in real time; if nobody arrives in an hour, the DNS has not changed where you thought.

7. Set up HTTPS on the new machine

   With the DNS now pointing to Lightsail (Let's Encrypt checks that the domain reaches the machine), in the terminal:

   sudo /opt/bitnami/bncert-tool

   Type the domain with and without www, accept the redirects to HTTPS and to a single version (the one you used before), enter your email and confirm. In a couple of minutes the website has a padlock and renews on its own. If it is WordPress, check in Settings, General that both addresses start with https://.

8. Sort out the email and close the old hosting

   If the domain's email (info@midominio.com) was on the shared hosting, you have two options, and you must decide before cancelling anything:

   • Leave the email where it is: keep the old hosting on its cheapest plan (many have an "email only" one) and do not touch the MX records. The website lives on Lightsail and the email on the hosting. It is the simplest if the email works well.
   • Move it to an email service (Google Workspace, Microsoft 365, your registrar's email): create the accounts, migrate the mailboxes with the tool they offer and change the MX and SPF records to the ones they give you. Tell the people in the company about the change.

   Do not put the email on the Lightsail machine: maintaining a mail server that does not end up in the spam folder is a job in itself. The machine does need to be able to send notifications (forms, orders): set up SMTP sending in the website with the email service you use.

   Afterwards, wait two or three weeks with the old hosting on, in case something forgotten turns up (a subdomain, a linked file, a scheduled task). Download a final complete backup from the panel and keep it. Then cancel the hosting, or leave it on the minimum plan if it keeps the email. And if the domain was registered with that hosting, transfer it to a registrar or to Route 53 before cancelling, so it does not go with it.

What can go wrong