Successful Weblog Server Change!

We’re live on the new server! In a nutshell, I’m thrilled. Moving this website to the new server has been frustrating at times and certainly time-consuming for both my ISP and for myself, but it’s definitely been a worthwhile adventure. Preliminary good planning and organization helped us tremendously and made all the difference. Today’s post relays some of the details about making the move. I’ve definitely learned a lot through this process, too.

As I wrote in my earlier post, Moving MT Installation to New Server, moved from an older and slower Windows IIS server with Apache to a new UNIX server with FreeBSD, Apache, MySQL, PHP, and more.

Although much of this is true for moving any website or weblog, note that what I’m writing here is based on the existing installations of Movable Type 2.6x and the default Berkeley DB.

Planning Ahead

Prior to moving, I researched a bit on what to look out for, in addition to backing up everything and exporting my data. Here are a few things to keep in mind:

Entry URLs

Since I use customized entry URLs not based on the entry IDs, I knew I wouldn’t have the problem that others have mentioned about all their URLs breaking after a server move. Apparently the entry IDs can change with a server move, and if your entry URLs are based on those entry IDs, your URLs will change. 1  That can be a big mess of dead URLs for search engines and anyone linking to your posts. Not good!

I’ve written several posts on friendly URLs, so check those out for more info:

Plugins, Hacks, and Customizations

Prior to the move, I started looking at the latest information for the plugins I’ve used at my weblogs, along with a few hacks I’ve added over time. New versions have come out for some of them, but I needed to find out if the new versions would continue to work for my 2.6x version. I downloaded newer versions available, some of which were updated for version 3.x. For the most part, I ended up having to experiment to see if the new versions would still work with my version. If not, I used the older version. I’ve written more on that below.

Backing Up, Exporting Data

Just like anything else for your computer, having backups is so important. Here are a few helpful tips.

  • Weblog configurations, settings:
    Make sure you have a copy of all of your weblog configurations, as you’ll need these for your new server.
  • Templates:
    If you’ve linked to each of your templates, it’s easy to back them up regularly along with all your other server files. See MT’s documentation, Editing a Template: Link this template to a file, and the, Back up Templates with 'Link This Template'. In addition, I edit my templates when needed on my local computer in TopStyle Pro and upload them via FTP, which I find much easier and more convenient, too.
  • Back up:
    Make sure you’ve backed up a complete copy of the latest versions of everything on your current server.
  • Export:
    Make sure you’ve exported your latest MT data. To do that, log in to your MT interface online, click on “Manage Your Data” for one of your weblogs, then click “Import/Export” in the left-side navigation menu. On the Import/Export page, scroll down to the bottom of the page and click the link, “Export Entries From (weblog name).”
Planning the Server Move Strategy
  • Keeping it simple:
    For the initial move, we decided to try to keep the move simple by using the same version of Movable Type and the Berkeley DB database, waiting to upgrade both until after the move. That made good sense logically, but that idea ended up not being totally true!
  • Researching:
    In addition, do some research to learn as much as you can about making sure your move goes smoothly. Check out problems others have run into and how they resolved them. Often they’ll also write about how to avoid those problems, too. You’ll find lots online from others who’ve made similar moves and have some helpful tips. My previous post, Moving MT Installation to New Server, has some helpful resources that came in quite handy. There are plenty more out there, too.
  • Allowing Overlap Time:
    By keeping my existing domain name live on the old server until the new installation was completed allowed all of our work to be done privately on the new server prior to going live. This also meant no website downtime whatsoever. When I completed my part for the new server, I emailed my ISP and let him know I was ready to go live. He did his magic to update the DNS (Domain Name System/Server), and the change to the new server went live without so much as a hiccup. The key is to allow plenty of overlap time to move everything, especially if you need to deal with a CMS or weblog publishing system. I usually tell clients to allow a week or two overlap for basic websites, but I think it’s wise to allow more time than that for bigger moves. It really helps to allow plenty of time (more than you think you’ll need!) for handling any changes and testing needs. Better to be safe than sorry.

Moving Day

My ISP handled the actual move to the new server, and from our emails back and forth, it’s clear that it was challenging to get the data to transfer. It turned out that upgrading to MySQL was far easier to transfer than trying to transfer keeping the original default Berkeley DB. After trying a variety of approaches, the one that finally worked was converting the data on the old server first using the db2sql script across an Internet connection.

Then Came My Turn

Once my ISP had completed the transfer, it was my turn. Much to my surprise, all my Movable Type configuration settings were intact on the new server for each weblog, and all my data was there. I did need to set the new file paths since they reflected the old server, though. Things were definitely off to a good start, at least until I got to the plugins, which I explain below.

Changing from .pl to .cgi

Many of the scripts on the IIS server needed to be changed to a .pl extension from the original .cgi extension, such as the scripts for the login interface, comments, trackbacks, search, and others. Switching to the new server’s UNIX environment running FreeBSD meant changing those back to the original .cgi extension. My ISP took care of that on the server side, but if I had any hard-coded references within my templates, I’d need to change the appropriate endings. Using MT tags for scripts means you don’t need to deal with that, though, such as the form fields:

<form method="post" action="<$MTCGIPath$><$MTCommentScript$>"...

In many instances, hard-coding those may not matter much, but if/when you need to make any changes, it’s one less thing to include on your To Do list. It also means you eliminate possible typos or missing anything, which would mean your script wouldn’t work.

Plugins and Customizations

I’ve customized my installation quite a bit with the use of plugins and a few hacks. (See my Colophon for details.) So, once I reviewed everything and changed the file paths to the new server within the Weblog Configuration area, I was ready to begin installing the plugins.

I added and tested the plugins one at a time to be able to easily identify which plugin was causing problems. This part was a bit tedious and time-consuming. I tried installing the most recent versions of each plugin, but they didn’t always work properly with my version 2.66 installation. Whenever I encountered an error (most likely due to incompatibility with my v.2.66 installation), I tried the older plugin version that I knew would work. This approach worked beautifully, allowing me to use updated versions whenever possible.

I also used Stepan Riha’s CGI application, MT-Medic, to help point out any warnings or error messages as I installed and tested each plugin. That CGI application is especially invaluable for something like this, but that’s only one of its helpful features.

After I installed and tested each plugin, I used my private test weblog to run a test build. Everything worked beautifully. Whew! I was ready to rebuild my website on the new server.

I then went ahead and rebuilt each of the weblogs on the new server, checking each one carefully before rebuilding the next one.

Next on the list was to add the hacks I’d used on the old server for avoiding duplicate comments and trackback pings, adding an 'Unsubscribe' choice for Email Notification subscribers, and adding the capability of receiving me an email for new Email Notification subscribers. See my Colophon’s Movable Type Hacks section for details.

Once again, I added each hack one at a time, testing each one before adding the next one. I also made a backup copy of each original before I made any modifications.

Other Server Differences

SSI Differences

I encountered a difference in how SSI (Server-Side Includes) files are handled. For example, on the old IIS server, I’d used SSI directives within SSI files, such as adding a latest modified date SSI directive:

<!--#config timefmt="%m/%d/%Y"-->
Last updated <!--#echo var="LAST_MODIFIED"-->

or adding an include directive, such as:

<!--#include virtual="/directory/" -->

The new server doesn’t follow either of these directives when they are embedded within an SSI file. They work fine on the new server within my HTML and PHP files, though.

  • Regarding the LAST_MODIFIED directive, after running some Google searches and coming up empty, I tried the above SSI LAST_MODIFIED directive within a PHP include, which works fine. That was an easy fix.
  • Regarding the <!--#include virtual... directive, after testing possible SSI alternatives, I tried PHP includes for the include file and for the embedded included file, which works fine. Once again, that was an easy fix.

I’m sure there are plenty of possible approaches that can work, but the above was quick and easy to implement. I’d love to hear other possibilities, so feel free to leave a comment below or send me an email (especially if I’ve turned off comments below).

Support for PHP, .htacess, MySQL

This support is a huge relief to have on the new server! I’ve used .htaccess and PHP includes for client websites when available. It’s great to finally have this support for my own websites.

  • I’m not a programmer (obviously!), but I’ve picked up enough to create PHP includes for customizing per-page elements, such as navigation (changing the navigation link for the current page, for example).
  • I’m also excited about being able to use PHP and MT’s MySQL database to close off comments and trackback pings all at once on older posts. Although spammers still try to hit my new posts, they mostly go after older posts. MT-Blacklist stops nearly all of them, fortunately.
  • The MySQL approach allows far more flexibility with MT. I’m also finding that rebuilds are tremendously faster, but I’m not sure how much of that is MySQL and how much is the new, more powerful and faster server. I’m clueless, but I’m sure those who understand server stuff and databases know all the details. See also’s MySQL or Berkeley DB? and MTWiki’s Berkeley DB and MySQL.

Feedback Request: Bugs, Problems, Glitches?

If anyone finds anything amiss, please don’t hesitate to let me know right away. In addition to addressing plugin problems above, I’ve found one post two posts so far that were duplicated by mistake as a result of the move. These might not be the only ones, although hopefully that’s it.

[image: going crazy!]

In addition, the “Recent Comments” in the sidebar isn’t updating, either, even though it’s working properly on the Recent Comments Archive page. That’s another plugin version issue to fix that I haven’t figured out yet.

I’ve been writing this weblog since 2000, so there’s a lot of material here within the archives. If you find anything amiss at all, please let me know!

The Verdict

All in all, I’m thrilled to have my websites, including this one, on a new server that’s far more powerful and has more options that I’d wanted for quite some time.

I adore my local ISP, who I’ve been with for at least eleven or twelve years now. Previous server moves were simple, in part because the moves were always IIS-based and in part because my websites were simpler and didn’t involve a CMS or databases. Now they’re simpler to manage, though, and it’s worth the initial effort of getting things set up.

Kind of like moving to a new home, moving a website like this can be quite a job, but the new surroundings make it all worthwhile. Over the coming months I’ll be exploring new possibilities and experimenting.

1Entry IDs are the default for Movable Type v. 1.x and 2.x; however, I think that’s changed with v. 3.x.


Comments, Trackbacks: 3 so far. Add yours!

  1. Glad all went well. IT sounds like you probably ended up with a more complex situation than was necessary. Of course, whenever you use MT, you’re asking for added layers of complexity.


    04:04 am, pdt 8 August, 2005Comment by Aaron Brazell

    comment #1 permalink ·'; else echo '·'; ?>

  2. I’m very glad to see that your move went without a hitch.

    05:49 am, pdt 8 August, 2005Comment by Sian

    comment #2 permalink ·'; else echo '·'; ?>

  3. While checking on something else today, I noticed that Shirley has completed what I would imagine was a pretty tough server move from Windows IIS (yuck!) to a new FreeBSD, Apache, MySQL and PHP box. Welcome to AMP Shirley! I run the exact same setup. If

    12 Aug, 2005Trackback from blogZero

    trackback #3 permalink ·'; else echo '·'; ?>

This discussion has been closed. Thanks to all who participated.

*/ ?>