Some months ago I posted a query to the list and following is a
compilation of the answers received, forwarded with permission from the
authors.  I have also added some details of the strategy QUT Library is
adopting.  Apologies for my neglect to those who asked me to copy to the
list:

I said:

I would be interested to hear from anyone with experience in migrating
automated serials (orders, check-in function) from one library system to
another, particularly people who have set up prediction data from scratch
on their new library system.  I am particularly interested to hear from
anybody who was not able to continue check-in and invoicing operations on
their existing system as they created records on the new system.

Paul Reynolds, Serials Librarian, University of Tasmania replied:

Here at the Univ of Tas we migrated from our old Urica system to Horizon,
earlier this year....below are some thoughts on the process:

1. How many "subscriptions" (including donations, standing orders, etc.) do
you have?
we have approx 4,000 live serial titles
2. What type of data did you need to create manually (eg. order,
control/check-in records)
in our migration from the old system, we generated order records, and
control records for all serial titles.  So we were required to manually
generate checkin records (including publications patterns etc.).  So no
accessioning data was transferred in the process, but the brief holdings
statement for each title was included in the download.  I decided that we
would retrospectivelly enter the 1996 issues as well as the 97 issues in
hand.  Further, we decided to set each title up as a new issue arrived in
the library, so this whole process will be ongoing for at least 12 months.

3. How did you manage the process of setting up the new order and
control/check-in records while maintaining check-in and invoicing throughput

our order record were downloaded in the migration process so we could begin
paying invoices almost immediately.  But the process of setting up checkin
records slowed us down considerably.

4. Did you create control records from the item in hand or from the
frequency and receipt patterns from your previous system

definitely from the item in hand....I did not want to duplicate errors from
the old system, and the setups are so different that it would have been
almost impossible anyway.

5. Did you employ additional staff, for what period, at what cost, and what
work was performed by them?

this became somewhat of a problem for me.  Although at one stage we had a
considerable backlog, I was reluctant to hire new casuals because of the
training involved....ie. the amount of time it would take to train a casual
was not worth the effort in my opinion, particularly since we had no
longstanding casuals left, so the training was not guaranteed to be a good
investment.  Instead I pleaded with my colleagues to give me help from other
areas....we ended up getting some help from acquisitions and cataloguing,
and even some branch people helped with non system tasks like sorting gov
pubs etc.

For those people who helped with the on line stuff, we set up the checkin
record and passed the title on to the helpers to actually perform the
checkin operation.  Once they had enough experience, and we thought they
were capable, we taught them how to create the checkin record, so that they
could perform the whole process themselves.  Not sure that this was
ideal....I would rather have had only people with real serials experience
creating the checkin record, but there was not enough of these people around.

6. How long did the transition to the new system take?

the serials module came up in March this year and we expect in to take us
the rest of the year to have every title set up properly on the system.

7. What library system do you have?

Horizon

8. Any other lessons you learnt from the process.

The most important lesson is to get the migration of data correct in the
first place...if this means delaying the process somewhat, so be it, but it
is the most important step in the whole process.  Starting a new system with
suspect or incomplete data could be disastrous.  But, I would advise against
generating new data from suspect data.  In our case the frequency patterns
in the old system were very simplistic and not compatable with the new system.

I gave most of my attention to order data rather than the accessions data in
the migration process.  Ensuring the continuation of titles and paying
invoices is essential.

I would advise against trying to run two systems in tandem, rather make sure
that you can hit the ground running with the new system.  But if you
absolutely have to continue with the old system for a while, consider
accessioning on the old system, and concentrate on getting the order and
financial records in place on the new system first.

Don't let the techies talk you out of migrating the notes fields from the
old system...there is always important information in these fields,
especially for serials!

In the contact negotiations, make sure that your new vendors have some
responsibility for the implementation process...there are sure to be
problems and you will need quick acccess to the experts at this crucial
stage of the process.

As always, the above is my opinion only and does not necessarily reflect the
opinions of the institution for which I work.

***************************************************************************
Marifran Bustion, Acquisitions Department, George Washington University
replied:

I'm replying a little earlier than our conversion completion, but I can
tell you what we're planning to do.  We're now a NOTIS site and are
converting, as one of seven libraries in a consortium, this summer to
Endeavor's Voyager.  Three of the libraries, including ours, used two
different check-in systems in NOTIS, one is basically a free-text receipt
statement, with limited number of characters, the other was supposedly
based on the MARC Format for Holdings.  The free-text statement will
convert to the MHLD record, field 866; the other will not.  We are
converting all of the latter to the free-text receipts before we convert
to Voyager by closing records and transferring date as we bind volumes and
from a report identifying all titles in the MARC based check-in records
(about 1200 titles).  We have over 10,000 titles altogether.

Order records will not convert, although some data from the records will,
primarily vendor records, some notes, the check-in statements, will.

We will create check-in records with issue in hand.  To do this, we also
have to create purchase order and fund records and publication patterns
before creating check-in records.  Since we can't do this for all titles
received each day, we will also receive issues on the 866 in the MHLD
records until we can create the check-in records.

We are not hiring additional staff, although there was a little bit of
money to support this.  Our Periodicals staff, which assumed daily
check-in of periodicals just a year ago and had no computers!, has
undertaken the project and is doing quite well.  If we had hired
additional staff, they would have done other duties, such as public
service desk work, and not transferred check-in data.

Since we haven't actually done this, I can't speak to the length or
smoothness of the transition, but I will say that most of our staff,
especially the Periodicals staff, are very excited about learning more
technical service type work to make their public service work more
understandable and effective.

***************************************************************************
A colleague from another University replied:

1. How many "subscriptions" (including donations, standing orders, etc.) do
you have?

We had approximately 2000 "live" records on the GEAC checkin module
which we tried to move with mixed success to DRA (classic).  We are
part of a consortium so we move system when they do.  We now have
around 4500 active titles.

2. What type of data did you need to create manually (eg. order,
control/check-in records)

In effect we recreated everything manually based on data preserved
in various forms from our old system. The vendor records created on
the old system were able to used with only minor editing.

We preserved old orders (thus vendors), and invoices (ie audit trail)
but they were often linked to a duplicate record and had to be
transferred to the correct record. We had to recreate orders for
all titles as order numbering system / renewal logic was not
compatible between systems.

We tried to preserve issue level receipts as a system generated
summary.  In practice this was only a guide as many statements were
so complex as to be unintelligible. (eg these generated statements did
not ignore a fulfilled claim and recorded it as a claim; where 2 copies
were held their data became mixed).

We preserved summary statements of holdings from both the cataloguing
module (ie the statements we put in for the public) and the more
detailed summaries we had created for our own use (ie including every
missing issue in an old run). We chose to reenter most of this data
to make more use of new system funtions, however, at leat the data
was there on which to make choices.

We lost all patterns/prediction info as the 2 systems were so different
in architecture as to be incompatible here. This meant every pattern
was redevised.

3. How did you manage the process of setting up the new order and
control/check-in records while maintaining check-in and invoicing throughput

We had a 5 month hiatus between decommissioning of old system and
commissioning of new serial module.  (Because our consortium and
the vendor were trying really hard to preserve and extract usable data
for us). In the interim we relied very heavily on an
inhouse (dBase) list which had been created for shelflisting.  The
public could get call numbers and locations from PAC (via preserved
cataloguing summaries) or via a printout from the dBase list, but details
were sketchy and increasingly obsolete.

As we were only expecting a 2 week delay between systems we set up
a nasty system of identifying call number and campus from the dBase list
then photocopying cover (and annotating if necessary) so issues could be
back entered when system was available. These photocopies were filed by
title (in this way we could answer questions such as "did we get..." and
had no build up of issues in processing).  This part worked reasonably well
at least our users didn't notice the chaos out the back and the
throughput was much the same as under the old system. We had an old Kal
register system which had been closed in 1990 so no use was made of that.

When system became available we started with weeklies (so we could reduce
photocopying burden), then titles where there were duplicate subs (
so if issues came separately it was easy to tell which issue went where),
titles we remembered with bad claim histories (very subjective),
then monthlies etc.  We did loosleaf services last.

New order records were created by serials librarian as titles
required renewing.

The 2 LT's (one a Senior LT) identified correct record, added
new pattern, new copy record (ie data on vendor, call number,
processing) and checked new predictions.  They also deleted
the converted data and reentered (or tidied) free text information
about longstanding subs such as their summary holdings and missing
issues.  They added any claims which were obvious.

We only claimed titles where an issue was obviously missing in
this period. They checked the shelves a lot!

4. Did you create control records from the item in hand or from the
frequency and receipt patterns from your previous system

Item in hand (and its photocopies), lost all frequency and pattern data.
We were able to use converted bib data and vendor info.

5. Did you employ additional staff, for what period, at what cost, and what
work was performed by them?

We seconded an LT to assist the SLT who both worked full time (and
incredibly hard!) to set up and convert all titles.  In the end they
created/upgraded 4000 records over 12 months.

Cost:  500 hours of Sen Librarian (HEW 7)
      1000 hours of Library Technician (HEW 4)
       500 hours of Sen Lib Technician (HEW 5) overtime

Reams and reams of photocopy paper!

6. How long did the transition to the new system take?

12 months

7. What library system do you have?

DRA classic (migrated from GEAC)

8. Any other lessons you learnt from the process.

Believe noone when they say your data can be preserved.
(There is no accepted standard for serials formats so
even the most basic things don't match between systems.)
Get the most accurate hard copy of your information as
you posssibly can BEFORE you attempt to convert anything.
Try not to be the first library to add complex things to the
new system.  There are so many ways of approaching most things
in serials (eg what is the advantage of Quarterly over 4 x pa,
 what about using seasons (does your system assume they are
Northern hemisphere only), how important is preserving an order
no for a vendor, if I don't follow the standard format the manual
suggests (because I'm using converted data) what reports can't I
get later that I really want...  If you're not the first, you can
ask someone who made the mistakes and avoid a few...

The new system is much faster than the old one and does
claim more accurately.  There are lots of things we are
stuck with because we used converted data but we will
live with them!

**************************************************************************

The above advice was invaluable in Queensland University of Technology's
planned move from URICA2000 to our new system (under contract negotiation
at present).  Some things can't be decided yet because we don't know which
system we will have.

We have about 11,000 live serials which we will need to translate.  At
this stage we are planning to migrate as many order fields as we can.
Control/check-in records will be created from scratch.  Holdings records
are currently open free text statements and will be migrated as such.  One
of the potential systems is offering a way for our new system holdings to
be merged with our existing textual statements, but this will be performed
title by title, at the binding stage, and not as part of the migration
process.

We devised two possible strategies to manage the process of setting up the
new order and control/check-in records while maintaining check-in and
invoicing throughput.  The preferred strategy depended on a decision to
implement vendor supplied shelf-ready processing of approximately 60% of
our serials for 1998 which would release staff time from end-processing,
claiming and problem-solving and so allow the data entry project to be
managed with the minimum additional staffing resources.  This has now been
decided and we are in the thick of organising shelf-ready supply from our
partner Blackwell's.

We plan to create the control record/check-in card prior to accessioning
on the new library system.  We won't be migrating any receipt pattern data
from the existing library system due to the reasons already identified.
We are intending to consult the pattern information on our existing system
at the time of creating the new records.  We are creating a
quick-reference table of frequencies and grace periods for consolidated
and publisher direct material for staff reference.  As a fall-back
position we also intend to produce a printout of a year of receipt data
from the library system as we may not be able to keep the existing system
live for the entire project.  Material arriving direct from the publisher
will be set up as priority as the library is responsible for claiming
routines for this material.  To avoid delay in delivery of consolidated
material to the shelves we are planning to accession from the Blackwell's
packing slips in conjunction with existing library system data.  Our
partner Blackwell's is examining automated solutions they can employ to
help us with this translation process.

To create the check-in records which can be done independently of the
order records we have identified tasks which could be absorbed by other
areas during the project and have applied for funding to replace 3
additional serials experienced staff to be seconded from other areas to
achieve 9.5 f/t equivalent staff working 5 hours a day to complete the
project in 3.5 months.  This is based on 15 minutes per record and
allowing 20% project "slippage factor".

To create the order records, and in expectation that some order fields
will be migrated, and that a maximum of 5 minutes per order record is
anticipated we have allowed two existing Serials staff 3 hours each per
day, completing the project in 6 - 7 months.

Colleen Cleary
Serials Manager
Queensland University of Technology Library
Kelvin Grove Campus
Victoria Park Road
Kelvin Grove
Qld 4059 Australia

ph. 61 7 38645577
fax. 61 7 38645539
email: c.cleary@qut.edu.au