On Aug 11, 2005, at 3:03 PM, Jeff Kell wrote:

> Seeking last minute advice before blindfolding myself and stepping
> off the edge...
>
> Current server:  Listserv 1.8d / LSMTP 1.1b / Windows NT4
>
>     New server:  Listserv 14.4 / LSMTP 1.1b / Win2K3 Server
>
> (A) Can this be done with some careful file migration, then just
> crank it back up?  Or does there need to be a step-wise update (can
> you go straight 1.8d -> 14.4, or should there be an intermediate
> stop?).
>
> (B) One stumbling block is existing lists are setup with Notebooks
> on D:\PUBLIC\listname, and the new server will have them on F:
> \PUBLIC\listname (it has a DVDROM in as D:).
>
> Any suggestions or war stories would be greatly appreciated.  We've
> been thinking about doing this for ages, but it is really (really)
> going to happen now...

The suggestion to reconfigure your new server's hardware layout makes
sense. You'll save yourself a lot of effort by avoiding the need to
make any changes in the path on each list's Notebook keyword. I had
to do a more complicated migration last January. I went from Listserv
1.8d under a cranky old Tru64 Unix system to Listserv 14.3 under Red
Hat Linux with a completely different file system and different mail
distribution agent. I also migrated a small Listserv 1.8e server from
Windows 2000 to our Listserv 14.3 server after I finished with our
primary Listserv 1.8d server's migration. I migrated the list's from
the Windows server individually over a period of about one month and
I notified each list owner as I worked through that migration. The
migration of our Listserv 1.8d server was urgently needed because our
old Listserv crashed every night like clockwork.

To migrate the 1600+ Listserv 1.8d lists, I wrote some perl scripts.
One perl script transferred all but the most recent archives files
for each list from our old Listserv 1.8d server to our new one. The
script worked by creating a tar file for each list's old log files. I
knew I could run that script safely while the Listserv was in
production because the old archive files could not change. I ran that
script a few days prior to the cutoff date for our migration and I
transferred the tar files to our new server and I untarred them. I
also wrote a script to transfer the lists and I did that before the
cut-off date just to make sure everything worked. I also needed a
script to generate the multiple sendmail aliases that each list uses
because we moved from qmail to sendmail at the same time, which was
against my recommendation. Everything worked fine. I was able to
start up the new Listserv and have it index the archive files and I
could do all the usual Listserv type stuff via the wa CGI.  I also
set up some test lists on our old server to try out during this
process, so I could be sure my migration method was sound.

On the actual migration day, all I had to do was run another perl
script to migrate the most recent log files over. I also wrote
another perl script that created a tar file for each list that
consisted of the .list file, plus any .mailtpl and other support
files. That script also adjusted each list's Notebook keyword to
reflect the different path each list's log files needed. As a result,
on the actual migration day, all I had to do was shut down our old
Listserv 1.8d server, move the most recently changed files over, plus
the list's support files. Half an hour later,we were good to go, but
I did have one glitch which was out of my control that delayed the
time I was able to begin the final migration phase.

If you can, I suggest you move the IP address and host name over from
your Listserv 1.8d server to your 14.4 server. This will make your
life a lot easier if your relationship with the people who maintain
your organization's DNS is not as good as it should be. The only
glitch I had that gave me any grief involved a DNS change. We were in
a situation here where we had to move the listserv.temple.edu host
name from one IP address to another for reasons that don't matter
here. At least two weeks prior to our migration date, I requested
that our Network Services group make this change on the migration
date at a specific time.. Unfortunately, that time came and went
despite my reminding our DNS gate keepers repeatedly that this change
was crucial to the project, but they had other ideas. After my pleas
went unheeded, I finally had to enlist the help of senior management
to coax our network people into making the DNS change. As a result of
this delayed DNS change, the new IP address did not propagate to the
computers at our help desk on a timely basis. It took a few hours for
some reason for the change to propagate to our help desk area. This
delay caused a great deal of confusion for Temple's help desk staff.
Oddly enough, the change propagated everywhere else much faster,
including to the two workstations in my office so I didn't realize
this was an issue until I started getting complaints from help desk
consultants. The moral of my story is, you would be wise to keep the
same IP address and host name on your new Listserv. Of course, you'll
need to shut down the old Listserv server to ensure you do not have
an IP address conflict. Eight months has passed since I did that
migration and we still have all the old lists sitting around on our
old server (which also received a new host name). Had my migration
plan failed, I would have simply brought the old server back online
with its old host name and returned to the drawing board to develop a
better migration plan, but fortunately, it worked well.

Now, I am getting ready to migrate from Listserv 14.3 to 14.4 this
Tuesday, and I am looking forward to completing that process. By the
way, you do realize you need a new 14.4 LAK, right? This is explained
in the documentation. If you haven't requested a new LAK, I suggest
you do so now.