PHP / MySQL Web Application Migration Steps

I was recently asked how easy it is to move a web application based on the PHP/MySQL realm of web application development. When moving a static website, one can “drag and drop” the website from one location to another, and things usually work just fine, so surely moving a web app is this easy?

Unfortunately, there is a lot more work involved than that. The thing is, not all information is stored in navigable files and folders, there is information stored elsewhere in the system, such as a database, and meta information tied into the existing file structures. This article will explain the steps required to move a web application, and will be split into two categories, the old server and the new server.

Requirements

You will need to know the following technologies to move a web application:

• Basic PHP (required to change database configuration and host configuration variables)
• Linux file permissions (required to troubleshoot file permission errors)
• Basic MySQL administration (user account creation, permission granting, import/export)
• Access to old server control panel
• Access to old server FTP
• Access to new server control panel
• Access to new server FTP
• Registrar login information (e.g. GoDaddy, if keeping same domain)
• New server Nameserver records

Registrar

This part is optional. This is if you are moving a web application from one server to another server and are KEEPING the same domain name and same registrar. If you need to move registrar's as well, that's a whole ‘nother store.

The first thing to know is that the registrar answers the request to a visitors browser when they attempt to visit your domain. A new session goes like this. The visitors browser wants to visit www.yourdomain.com, and has no idea anything about it, has never been there before. The browser asks .com where to find yourdomain.com. The big .com server responds with a way to get to that server (an IP address). This information is stored by the computer / routers / internets for relatively long time, 12 hours is common. So, when changing server information like this, do NOT vist the website for a while before and after the transition, otherwise your browser will still see the old host and not the new host. We call this old DNS cache issues. Once the broswser gets access to the yourdomain.com, the host server sends the files requested to the browser.

You will need to log into your registrar, go to your list of domains, and update the entry for the particular website hosting the web application. Once there, you will need to update the setting called a nameserver. There are usually two records for this, along the lines of NS1.HOST.COM and NS2.HOST.COM, but they don't need to follow that convention. Update those, and set them to the values required by your new host, such as NS1.NEWHOST.NET and NS2.NEWHOST.NET. Once this is done and you've waited enough time, you can attempt to visit the website. If you get an Error 404 file not found, everything is good. If you still see the website, your DNS cache is old and will require several hours to resolve to the new information. If you see something along the lines of this domain is not configured, you still need to create an account on the new host for this domain.

Old Server

The application is already functioning on the old server, so we will need to copy the data to the local computer.

We will want to connect to the old server via FTP (server-name, user-name, password, application directory). From here, you will want to copy the files from the server to your desktop. While doing this, you will need to look around at the folders and look for any with non standard file permissions (Linux file permissions look like 0777, 0566, etc.). These numbers correspond to accessibility between the current LInux user (the FTP account), the users main group, and the permissions for the rest of the server. Keep in mind that the web server itself runs under a different user account than the FTP account, which is why these permissions matter. With a static website, nothing needs to be updated, and the process is a lot simpler. For the most part files can be moved without remembering exact permissions (the server usually “gets it right”), but writable directories (usually stuff with names like cache or temp or uploads) will need to be set to writable on the new server. When you find these, write them down, otherwise we'll have issues later.

Now that you have the files copied to your local machine, you will need to also download the relevant database information. Web applications store data in a database instead of local files for many reasons, such as efficiency, security, stability, etc. Most web servers (every server I've used) comes with a convenient to use web application for use as the database front end called phpMyAdmin. This is usually buried within a control panel script (such as cPanel or Plesk). There is no standard between different servers for knowing the URL to access the control panel, you will need to contact your host for this information if you do not already have it. Once you access your control panel, navigate to and open phpMyAdmin.

Once inside of phpMyAdmin, you will see a listing of databases, storing information for the different applications running on the server, and some information for the server itself. Open the database for your application. On the top of phpMyAdmin, you will see an export tab, click it. In here, you can select which tables to export (all of them in this case), and whether to export data or structure or both (choose both), along with about two dozen other export options. Usually you can leave these at their default values. Click the export button and a file will begin to download. This file contains instructions to rebuild the database on another server, in the form of possibly thousands of SQL commands. You can open this file in notepad to see what it looks like. If your database is too large, the export will fail, and you will need to export the data using another method, usually via an SSH connection to the server, where you will need to execute commands via the Linux command line.

Now that you have the listing of files, which files/directories require special permissions, and the database “dump”, you are able to move on to the new content server to upload the web application.

New Server

On this new server, you will need to hunt down the control panel like you did for the last one. If the server is hosted by a different company, the control panel will be in a different location. Also, the control panel may not be the same version of the software as the last one (e.g. cPanel, WHM, or Plesk), and if it is the same software it may not have the same branding or interface (e.g. Mediatemple has a highly configured Plesk which does not resemble or function like any other hosting companies Plesk interface).

Once you're in the interface, look for their MySQL configuration settings. Note that this is different from phpMyAdmin. Most hosting companies don't allow their phpMyAdmin install to have full administrative permissions (required for MySQL user account creation) but will require this to be done in a specialized screen. This screen is named differently by every hosting company, so I can't just tell you what it would be. Look for something like “MySQL permissions, database configuration, database settings, SQL admin, etc).

Once in here, you will need to do a few things. First, you will need to create a new MySQL database. Name it whatever you like, as long as it's simple. Stick with letters and numbers to be safe. Once this is done, note that the database you created does NOT have the name you gave it. Shared hosts will add a prefix, usually a code representing your account. So, if you created a database named flowers it might actually be named sa5024_flowers. Write this down, it is your database name.

Next, you will want to create a MySQL user, which will have a username and password. This information will be used by your web application to “log in” to the database. Yes, even applications require user permissions. Note that when you create a user account, the username will ALSO be given a prefix, most likely the same as the database name. So, if you create a user named floweruser, it will end up being something like sa5024_floweruser. The password will not be prefixed. Write both of these down, this is your database username and database password.

Now that this is done, you will need to grant the MySQL user permission to access the MySQL database. Usually in this same area of the control panel there is a list of users available which you can edit. You will need to tell the control panel that the user has access to the database (or that the database can be accessed by the user; it could be backwards). Once you do this, it will ask which permissions to grant, for example INSERT, SELECT, UPDATE, DELETE, DROP, etc. You only want to grand the insert, select, update, delete permissions (which also might be named create, edit, read, remove, etc). Save the settings and you now have a MySQL user which can connect to the MySQL database.

There is a fourth piece of information required by the web application to communicate with the server, and that is the server name. About 95% of the time this will be localhost as the database server is usually shared with the web server, but this isn't always so “as is the case with Mediatemple). Find this tidbit of information, it is usually in the same screens. If you can't find it, guess localhost, and if that does not work, contact the hosting company and ask this information.

Now, go into the phpMyAdmin area of the new application, and access the newly created database. Click the import tab at the top of the screen, browse to the file you saved earlier, select it, and run the import. Some systems have a maximum file size limit and the import may need to be broken up into smaller files, or you may need to access the server via SSH and run Linux command line options (although most shared hosts do not allow SSH access for security reasons).

If all goes well, you will not have a properly configured MySQL database with all of the tables of data imported from the last application.

In the files you have downloaded from the preview server, there should be a configuration file somewhere. Depending on the web application, the file could be located anywhere and be named anything. A lot of times this file will be located in the root and be called something convenient like config.php, other times it will be buried. Codeigniter based apps store this info in ./system/application/config/config.php & ./system/application/config/database.php (this information can be split among many files), whereas WordPress keeps it at ./wp-config.php. Open this file using a TEXT editor, e.g. notepad, textmate, etc. Do NOT open the file with a word processor or it will become corrupt. This file will store the settings as variables and values. I'm not going to get into the syntax of PHP too deep, but you will see something like $username = 'My Username' or define('MYSQL_USERNAME', 'My Username'). You can replace the value from the old server with the value from the new server. The value is stored within the quotes. Don't delete them, they're important! Update the MySQL username, password, database, hostname items.

Now that you've updated the configuration settings, upload the files via FTP to the new server (the login information will of course be different from the previous server). When the files are done uploading, go through and find the files/folders which require special permissions to be set and update them. These can be set differently depending on the FTP program of your choice.

Now that everything is uploaded, attempt to browse to the new website with your browser. If everything was done correctly, you should see the new website. Browse through a few files and make sure everything works properly.

Thomas has contributed to dozens of enterprise Node.js services and has worked for a company dedicated to securing Node.js. He has spoken at several conferences on Node.js and JavaScript and is an O'Reilly published author.