I finally launched the new and improved gench site! It’s my first Drupal site.

In order to replace the current (non-drupal) site with the new one, I had to juggle some big directories around on the live server. The good news is it’s relatively easy to do this. The bad news is it’s still rather nerve-racking! UNIX commands are indispensable for a task like this.

My scenario…

development environment = my local MAMP stack

staging environment = sub-directory under the live site (the old gench site)

live site = root of shared hosting web server

In other words…

/public –> http://www.gench.com (live instance of old non-drupal site)

/public/new/drupal –> http://www.gench.com/new/drupal (staging instance of new Drupal site)

The goals…

1) I need to ultimately blow away the contents of /public and replace it with the contents of /public/new/drupal.

2) I need to backup the old site and make it available under a sub-directory (http://www.gench.com/old-site/) as the client has requested.

3) I need to make sure I do nothing to damage the continuation of logging and analytics on the gench domain.

4) I need to create redirects for any old URLs that will no longer exist once the new site is promoted.

5) Oh yeah, and I have to do all this as fast as possible in order to minimize downtime on the live site. However, I do have one luxury you may not have: my client is OK if there are a few minutes during this launch when visitors get an error message. I set expectations as follows: there will be 3-5 minutes when visitors may see an error message and there will be 5-15 minutes when visitors will see the themed drupal maintenance message.

Have a safety net!

Before I share how I did this, I want to emphasize that I had a safety net in place before I got started with this. In my case, it was my local development environment. I knew that if disaster befell me on the live server, I could always restore the new site using my development copies of the code, files and database. I had a local copy of the old site for insurance as well. Of course, in order for my local copies to be viable backups, I first ensured they were completely in synch with the live sites.

WARNING: Your local copy of a site may be missing the following essential information or may have versions that will not work on the live server. You should take extra manual measures to back these items up locally…

• symbolic links
• .htaccess
• settings.php
• robots.txt

Write a script. No, not that kind of script…

Braver souls than I might actually write a shell script that performs all the maneuvers in a matter of seconds. But that’s not what I did or recommend. By “script” I mean a checklist for you to follow. By thinking it through and jotting it down, you’ll probably uncover some complexities that would have caused delays and additional stress, had you not done this exercise. Writing a script allows you to figure out all your syntax ahead of time and identify the steps that must be done quickly. You should also write a roll-back script: the commands and steps you’ll follow if you have to put the old site back into production.

Prepare redirects…

This step can be done any time prior to the launch provided the final architecture of the new site is established. It took me the better part of a day to do this step. I used a free site mapping tool (www.snapsitemap.com) which generated a list of all URLs of the old gench site. I then just slogged through the list row by row, creating redirects for almost everything. I just created these redirects in a text file on my local computer. One of the final steps of the launch will involve me simply pasting these redirects into .htaccess on the live site. Here is an excerpt showing just a few of my redirects…

# 301 Redirects from old gench site to new

    #Redirect /olddirectory/oldfile.html http://example.com/newdirectory/newfile.html

    Redirect /genchmusic.html http://www.gench.com/genchmusic
    Redirect /concert-series.html http://www.gench.com/concert-archives
    Redirect /mono-poly.html http://www.gench.com/mono-poly
    Redirect /home.html http://www.gench.com
    Redirect /slew.html http://www.gench.com/slew-0    
    Redirect /gench.html http://www.gench.com/article/about-gench-studio

My script…

1) Ensure my local copies of old and new site are current with latest changes (including .htaccess & settings.php)

2) Remove large junk files from live server (particularly old compressed css & js files)

3) Backup drupal database and store as tar.gz locally

4) Check live server for symbolic links. Turns out I have this sym link which is essential for phpMyAdmin to function. I don’t know of any way to preserve it, so I just copy and paste the link into my script so I can reconstruct it after the new site is promoted…

lrwxrwxrwx    1 gench.com users          62 Mar  6  2013 phpMyAdmin -> /services/websiteos/phpmyadmin/phpMyAdmin-2.11.1-all-languages

5) Backup old site. Because the new drupal site is below the doc root of the old site (/public), I want to create an archive of all files and directories on the server except everything under /new/drupal. I use the –exclude flag with the tar command to accomplish this. I’ll issue this command from above the public directory (the ftp root of my shared hosting account)…

tar -cvf old-site.tar.gz public --exclude=public/new

6) Backup log files. They’re already included in the tar.gz archive we just created, but for convenience later, I want an archive of just the logs sub-directoy and it’s recursive contents. I issue this command from inside /public…

tar -cvf logs.tar.gz logs

7) Then I store the logs.tar.gz up one level in the ftp root (above /public)…

cd ../
mv public/logs.tar.gz logs.tar.gz

8) Navigate to inside new site’s drupal root…

cd public/new/drupal

9) Backup just the new drupal site from inside drupal root…

tar -cvf /public/drupal.tar.gz .

10) Navigate back to ftp root and mv drupal archive there…

cd ../../../
mv public/new/drupal/drupal.tar.gz drupal.tar.gz

11) I now have the following in my ftp root…

drupal.tar.gz
logs.tar.gz
old-site.tar.gz
public

12) Put drupal site in maintenance mode (though I realize there are still going to be a few minutes where visitors will get a page not found). The previous steps don’t affect site visitors, so it’s only now that we have to be very quick.

13) Only proceed if you have local backups as I advised earlier. From within /public, issue this command to recursively delete everything…

rm -F .

14) Quick!!!! Navigate back to ftp root and copy the archive for the new drupal site into the sites doc root (/public)…

cd ../
cp drupal.tar.gz public/drupal.tar.gz

15) Issue this command to unpack the archive…

tar -xvf public/drupal.tar.gz

16) Check site. Clear caches. If you have problems, the most likely culprits are settings in .htaccess and  settings.php (especial base_url, base_rewrite and clean URL settings). Depending on the expectations of your client, it might be time to start executing your roll-back script if you can’t get the site up now.

17) Site looks good. While I’m still in maintenance mode, I’d like to complete a couple more steps.

18) Time to add the redirects I prepared in advance. I navigate into the public directory. I make a backup copy of .htaccess as I’m going to edit it…

cp .htaccess bak-htaccess

19) I then open .htaccess in the vi editor. I go to the last line of the file and hit ‘a’ on my keyboard to append to the file. I copy the redirects in the local text file I created in advance and paste them into .htaccess. I save my changes. Now I test some of the redirects to make sure they’re working generally. I’ll be keeping a close eye on my log files for the coming days/weeks to catch any redirects that I may have missed.

20) If you’ve been pointing your staging site to a PayPal sandbox account, it’s time to point it to your actual PayPal (or other payment) account.

21) If you want to protect your forms from spam bots, register your site with mollom and install & enable the drupal mollom module.

22) Now I take the new drupal site out of maintenance mode and we are back in business. However, I still need to restore the old site in a new place (as a reference for the client) and restore the site’s log files.

23) Copy the old-site archive into the /public directory by issuing this command from the ftp root (above /public)…

cp old-site.tar.gz public/old-site.tar.gz

24) Navigate into the public directory and unpack the old-site archive…

cd public
tar -xvf old-site.tar.gz

25) The archive we just unpacked has created a directory called “public” at the root of the /public doc root for the site. This is confusing, so let’s rename it…

mv public old-site

26) Check old site (http://www.gench.com/old-site)

27) Repeat steps 23 & 24 for the logs.tar.gz archive.

28) Time to recreate the symlink I noticed earlier…

ln -s /services/websiteos/phpmyadmin/phpMyAdmin-2.11.1-all-languages phpMyAdmin

29) This might be the time to merge custom settings in your old robots.txt file into your new drupal robots.txt.

30) I go ahead and delete all the .tar.gz files I used for this migration. I’d keep them longer (just in case!), but I don’t have much space allotted on this server (and I’ve got my local copies).

31) I notify the client that the launch is complete and provide them with their new login URL.