Scripts to a New Server
Moving a web site to a different server can be a breeze, or it can
be a real headache.
If a web site consists only of web pages, no server programs or
forms, for example, it generally requires only dragging the site
mirror backed up on the hard drive into the upload window of the
FTP program. Links need to be checked, of course, and all pages
viewed to verify the upload.
When scripts or other server programs need to be moved to the new
location, a bit more care needs to be taken.
More often than a person might think to be the case, CGI scripts
can be moved to the new server without changes.
But don't bet on it. Keep this article where you can refer to it,
or bookmark the WillMaster Possibilities archives at http://willmaster.com/possibilities/archives/
Note: This article does not address everything you may need
to know when moving CGI scripts to a new server. There
are too many different scripts and too many possible
variations of server configurations for that. It does
provide enough information, I believe, to allow most
such moves to be accomplished with success.
First, mirror of your web site.
A mirror means downloading the files from your server and storing
them in the same directory structure as exists on the server. For
example, on my hard drive I have a directory named "willmaster.com"
where the mirror for that web site is located. The "willmaster.com"
directory has a sub-directory named "possibilities"
where a copy of the files of this ezine's section of the web site,
in their own respective subdirectories, are located.
Always keep a mirror of your web site in a safe place. Don't let
the mirror become outdated. If you suddenly need to move to a new
server, you won't have to worry about whether or not you can
access the account at the old server.
Directory Structure and Paths
Next, using your word processor or a sheet of paper, record the
directory structure at the old server. Also note the path to perl
and the path to sendmail.
After that, record the directory structure you will need to use at
the new server, along with the paths to perl and sendmail. Support
at the new hosting company can provide information you don't have
If the directory structure and paths to perl and sendmail are the
same on both old and new server, the Universe is smiling on you.
When Directory Structures Are Different
When the directory structures are different, use a plain text word
processor, BBEdit or NotePad or other software that reads,
displays, and saves files only as plain text, and replace all old
directory structures with the new directory structures.
For example, let's suppose the new server's document directory
and the old server's document directory path is
then you would need to replace all instances of "/usr/local/etc/httpd/htdocs"
with "/www/example.com/htdocs" -- all CGI scripts need
to be searched.
Do the same with the server's cgi-bin directory path if the new is
different than the old.
If the name of the cgi-bin directory itself changes (some common
names are "cgi", "cgi-bin", and "cgi-local"),
then the URL of the scripts in the directory will change also.
This means any links, including links from FORM tags, must be
Some scripts have a configuration file where the directory path
information is specified. Others have a control panel that needs
to be used in the newly installed location to specify the
Always use a plain text word processor when editing perl CGI
When Paths To perl Are Different
The two most common perl locations are:
When the paths to perl on the new server are different than on the
old server, the first line of all CGI scripts must be checked and
changed if necessary. (Perl modules and include files don't
necessarily have the perl location on the first line like main
perl programs do.) Some CGI scripts also contain the perl location
in other places, scripts that generate other scripts for example.
You may wish to do a search and replace through all CGI scripts
except than those you know with certainty don't generate other
When Paths To sendmail Are Different
The path to sendmail can be just about anything, but usually
The path might begin with
When the paths to sendmail on the new server are different than on
the old server, do a search and replace through all CGI scripts.
Some scripts have a configuration file or control panel where the
sendmail location is specified.
CGI Scripts Running In Document Directories
If your old server allows CGI scripts to run in document
directories (in directories other than the usual cgi-bin
directories), then your new server must also allow this. If it
doesn't, you'll have to move the scripts into the cgi-bin, which
means they would have a different URL.
Any links you might have to scripts that are moved to a different
URL will no longer be valid. That can be fixed if the links are
all on your web site. But if the links are on another web site,
those other links will generate a "404" error.
Verifying the New Server Has Required Modules
When a CGI script uses standard Perl modules, it will have at
least one of these lines within it:
The underline will contain the name of the module the script needs
in order to run correctly.
Search your scripts for those types of lines, making a list of
each module. Once you have your list, do two things:
1. Check the file names of the files in your cgi-bin
that are in the same directory as the script or in
one of the script's subdirectories, crossing from
your list every file name that matches.
2. Of the file names left on the list, all should be
modules already installed on the server. The support
personnel of the new server should be able to tell
you whether or not each of those modules is indeed
installed on the server. If they can't, or if you
don't want to ask, you can download and use the
Master Pre-Installation Tester program from
http://willmaster.com/master/pit/ to look for them.
The new server must
have the modules your CGI scripts need or the scripts won't run
correctly, or maybe not run at all.
Scripts That Use Certain Database Modules
This can be a confusing section if you are unfamiliar with Perl
CGI scripts or how they work.
If you go through this section and you find that any of your
scripts use the modules referred to, you may wish to contact the
author(s) of the program and ask them to move the program for you.
Again, warning, this section could make your head spin if you're
not familiar with Perl.
A DBM module is used to store information in a special type of
database. This database is not a plain text database, so it can't
be treated as such.
If you download or upload DBM database files with FTP, you'll need
to transfer the files as binary files. Otherwise, you'll corrupt
the files. (The file name extensions of DBM database files are
usually one or two of the following: ".pag" and
".dir" (a set), ".db", or no extension at
If any of your CGI programs use DBM modules, the same modules
should be available for use on the new server.
If a script uses a specific DBM module, it will have one of these
lines somewhere in it:
Or, it will have the word
somewhere within it, which causes the default DBM module (any of
the above) to be used if no other DBM module was specified.
If any of your scripts use DBM modules, see if the CGI program can
export the database. If it can, export it, then import it at the
new location. That's almost always the best way to go, so much so
that it may be time well spent to ask the program's author how to
export and import if the program doesn't already have that
Keep backups of the original files.
When you install CGI scripts on the new server, follow the
installation instructions. The FAQ at http://mastercgi.com/faq/
may be of assistance if you run into problems not addressed in the
Some scripts can be tested on the new server by substituting the
IP address for the domain name in the URL. Others can be tested
only after the site is live on the new server.
Be aware that data files moved from the old server to the new
might have incorrect permissions. Data files the script creates on
the server have correct permissions. But those moved over from the
old might not.
If a script doesn't work and you suspect the reason is data file
permissions, try removing the data files in question and running
the script. When the script runs, it should create new files. The
new files would have the correct permissions. You can now
re-upload the data files from the old server and the uploaded
files should retain the same permissions as the files they
When All Else Fails (Or, The Easiest Way)
If you can't get a newly installed script to work, or if you just
want to do things the easy way, hire the author of the script to
do the move. If the author is not available, s/he may be able to
recommend someone who can do the job.
About the Author: