Migration Issues
Koha: Because the migration will occur between semesters, there will be a clean break for the Academics. We will set fixed and final due dates, as we do every year.
New Port Richey: We don’t know yet how we will handle this, as we do not yet know which vendor New Port Richey will migrate to.
Subscription Database Access
Subscription databases identify valid users in two main ways. They look at the IP address of the computer that is trying to connect, or they can check a validation server. As each library moves to its new system, its IP address will change. We—TBLC staff and library staff—will need to compile a list of the subscription database vendors and provide each of them with the new IP addresses and the date they will become active. Presumably, then, they will accept searches from computers with the new and different IP address. RPA is an intermediary. When a patron at home wants to search a subscription database, he comes to the RPA server first and is asked for his barcode. RPA looks that barcode up in the main library database and, if it is good, passes it on to the subscription data base with an “OK” stamp. RPA will need to be told the new IP addresses, so that at the appropriate time it can go to the correct server to validate remote borrowers. In most cases your new vendor will provide you with or help you find a substitute for TBLC-managed RPA.
Like RPA, SIP is a process that uses an intermediate server (housed here at TBLC) to validate a patron for a specific purpose. It may be for self checkout or to reserve a public access PC or for some other purpose. The patron’s barcode is keyed in or scanned at the library and is sent to the SIP server. The SIP server does a barcode lookup in the patron database and sends a response back to the device at the library. Like RPA, SIP has to know where the patron database is, so we will have to give it the IP address of the new server at the time of the transition. Again, SIP services will probably be a part of your new vendor’s package.
Four Sunline libraries currently use Debtcollect and Unique Management. Three of them are migrating to Polaris. Unique tells us that they can work with Polaris as easily as they can with Horizon, and that nothing special needs to be done for the transition. The fourth user is New Port Richey, and we do not yet know how their migration will affect their use of Unique Management.
There are a large number of iBorrow issues that come out of the migration.
1. Duplicate barcodes. The problem of duplicate item barcodes has come up with PALS in the past, but it should not come up in relation to iBorrow. This problem would occur if a library that migrated into the PALS database brought with it an item that had been borrowed (e.g through OCLC) from an existing PALS library. The copy attached to the brief record for the borrowed item would have the same barcode as the original item in the PALS database. Since iBorrow has not so far been able to communicate with Polaris, the PALS Polaris libraries are not part of the iBorrow network. So, no PALS items will have come into our Sunline system through iBorrow. Items borrowed through traditional ILL mechanisms and entered into the Sunline database with their original barcodes could cause this problem. But not iBorrow.
2. Use by patrons prior to the closed period. Patron searches in iBorrow and ILL staff work in the URSA client are both done on a server in Utah that is unaffected by the migration. When a Sunline library fills a request for another library system through iBorrow, that item is checked out to a dummy patron in the Sunline database, while it is on loan to the ‘foreign’ borrower. To Sunline, this is a normal checkout, and it will carry over intact into Polaris. Fixed and final due dates for the libraries going to Koha will prevent any issues there. Generally speaking, there is no technological reason to restrict patrons’ use of iBorrow prior to the closed period.
3. Use by patrons during the closed period. Sunline patrons who use iBorrow are, by definition, getting materials from other libraries, and these libraries are not affected by the Sunline migration. I see no reason to restrict the Polaris libraries ability to initiate requests in iBorrow during the closed period. The Koha libraries will probably cease to use iBorrow after they migrate, because Koha does not have an NCIP responder iBorrow can talk to. We can’t yet address how this will be handled with New Port Richey.
4. Use by patrons after re-opening. Like SIP and RPA, iBorrow stores an IP address for a library and communicates with it at that address. We will have to change the IP addresses for the Polaris libraries in iBorrow. This will take about 2 minutes per library. The bigger post-migration issue is that–as of mid-May–Polaris can handle only one of the eight NCIP messages that iBorrow uses. Fortunately, it is the most critical of those messages: the one that enables patrons to validate and request. We are making progress with Polaris and may have many or all of the working by the time of final migration. At present, Koha and iBorrow to communicate at all, so we’re not optimistic about the academics being able to continue to participate.
There are two migration-related issues with Overdrive: titles available and patron validation.
We need to make sure that any titles to which Polaris patrons have legal access are copied into the new database, if they are not there already.
Overdrive also uses RPA to validate borrowers. Our RPA server will not move nor change its address, so the change of home server should not matter to Overdrive, so long as they can find our RPA server and our RPA server can find the new Polaris server. Again, new RPA or RPA-like services provided by your new vendors may eliminate any need for RPA in relation to Overdrive.
http://ipac.tblc.org will see everyone’s material, because this is the ‘all libraries’ interface.This is the first ‘draft’ of this message. I expect that there will be additions and corrections. If you have any, contact me at TBLC by phone or email.