I hope you are doing well. It's been a while!
I'll give you my advice, that would be to set up a completely new server and migrate a location at a time. That allows for a smoother upgrade while not causing a long downtime, or frantic night work to touch each client. This is not as much a concern for the print clients as it will be for the SignUp clients. Print client is backward compatible, but these versions of SU clients are not backward compatible. So, if you were to upgrade your existing server, all SU clients will be offline until you can update them. Migrating each lab to a new server will allow a methodical approach and downtime will be limited to the site you are working on at any given time Now there are some other considerations too, like migrating users and your guest card system (if you still do that) so that may move the suggestion in favor of an in-place upgrade. If you do that, then you'll need to have a quick plan for updating SU clients. Also, I'd suggest updating the Print Client (Popup Client) as well, since you are there anyway.
So you'll need to decide what's most important to your users and what time-frame you have to do the work. Based on this, do you have any more questions?
-Jeff Herald - Pharos Systems
I guess another consideration for this is the financial side of things - as in, how to deal with people who visit different branches and have funds on their account for printing/copying? We have 13 branches with around 400 public access PCs, as well as a mobile library which also has a few machines in it, and our patrons often go between the various branches. This is one of the main reasons behind me leaning towards a large single upgrade... which would be a rather mammoth task, even with remote installation for the clients.
Am half-considering doing the migration by splitting branches into groups geographically, in order to reduce the scale and urgency of the work, whilst minimising the impact... will work with Library Admin on that one to see how we can best fit this to suit our needs.
I guess the main reason for my post is to ask this - is it possible (and preferably easy) to have some kind of trigger on the databases to replicate financial info from one database to the other if a patron logs in and starts doing transactions, when the database is split between the two environments?
Am currently still waiting on our Test servers to finish being built so that I can start replicating our Prod environment on them for testing the upgrade, so I have a bit more time to work on the planning aspect of things...
2 of 2 people found this helpful
Pharos doesn't support synchronizing transactions between databases. That's a lot of work, fraught with risk, for little gain. What I have done with libraries in the past is to set a cut-over date for the migration to begin. On that date, branches on the old server are set to print/copy for free (gasp) and add-value stations are disabled so the user balances in the old database will not change. Then, take a copy of the users and their balances and migrate them to the new DB server, before opening time. Starting with the busiest branch first, begin the migration of stations from old system to new system. Enable print/copy charging and add-funds stations as you finish. Go branch to branch, busiest first, to reduce loss of print/copy revenue. Also, I don't recommend announcing that part to the public or they'll flock to the free sites and take all they can get. Just treat it like an outage or something low-key.
One other hint from my experience, when you start, it will take you longer to do an early site than it will later in the process. You say you have 13 branches, but (depending on size) you can expect the first one to take more time, maybe even a day or two. By the end, you might be able to do 2 or 3 branches a day. That's because you will refine your procedures as you go and will have the pattern down as you get better. Other factors, like working when the site is closed, or avoiding peak times (after school lets out for example) will also speed up the process. So factor that into your plan. The usual thought process is to divide the work evenly, but you may find yourself behind schedule right away, but finishing early by the end. That's just what I've found, so I'm passing along the hints.
Of course, you can also just upgrade in place. It depends on your needs. I hope this helps.
-Jeff Herald - Pharos Systems
Thanks for the insight, Jeff, very much appreciated! Certainly food for thought
It sounds like we are lucky in that we phased out pharos-based copy cards, and now use cards living in the Odyssey server reached via the CBORD gateway. This is nice for Circulation staff, too, since they don't have to stock a machine with cards or collect money - our campus card folk do that.
I do have a question for Jeff on the DatabaseMigrationTool. What exactly does it copy over? We are now running SignUp, and visitor accounts (guest accounts?) live in Pharos. I would expect they would be transferred over in the process, along with most of the settings, such as set in the Pharos Administrator.
I was wondering if there was a way to do a database migration with the tool, then is it possible a few weeks later (when we do the actual migration of clients) to sync the two databases again, somehow? Alternately, if that's not possible,since we're virtualized, do the process twice. Build new servers, run the migration tools (db & printer), documenting & testing everything, then a week before the migration, do the entire process all over again following the documentation we built, building new servers, & repeating the entire process all over again.
The database migration tool will copy the old DB to the new server ad update it (see the instructions in the folder where you find that tool). There will not be a synchronization, it will copy and overwrite whats in the new database. It will copy all of the DB, not just users.
So, after consultation with Bryan (I had opened a ticket with Pharos), and this reply, it has been stated that I probably shouldn't run the DatabaseMigrationTool for standing up a new server & slowly migrating one branch at a time to it. The concern is that BOTH servers would think the SignUp clients 'belong' to them, and havoc would ensue.
Does anyone have any idea if it would work to migrate the database, then immediately DELETE all the SignUp clients from the new server? I mean, since we have to install a new client anyway...
Semi-related - can anyone guide me in exporting our users from the old server & then importing them into the the new one? That was one of the proposed paths to take - just migrate the users, and manually migrate all other settings, scripts, etc. I don't see a way to export them from the Administrator, so I assume it's SQL Studio time?
The duplicate names in different databases is not actually a big deal, if.... you take care with them. The simplest option is to just stop the SignUp service after the migration. That said, I have a SQL query I normally run that allows me to easily rename all of the clients by adding a suffix or prefix. This results in the new system not being able to communicate with the production workstations until we are ready to make a cutover. The script then simply removes the suffix/prefix after, a change control is issued and then I run it on the old server unless the services will be disabled (which I recommend doing even if the server gets shut down).
Depending on how many machines you have, you could modify the name in the database slightly, or you could just make sure that the new system doesn't have network access to the production systems. In short, as long as you take precautions to avoid the havoc that Brian warned you about, it really is a pretty routine practice (at least for me). As a side note, keep in mind that deleting computers from the database will not be allowed unless all of their transactions have been removed as well (archive + remove/purge from database). The archival of such records will affect your reports and usage statistics.
As for importing users from the old to the new, see the article below, but proceed with caution. Keep in mind that the Pharos database holds a remarkable number of configurations that can be a pain to try to remember all in one shot. Pulling the database over keeps all of that configuration intact, you just need to plan it as described in the first two paragraphs.