Orbis2 Schedule Change
Migration Management Group:
Tomorrow morning (Monday July 8th) we have to make a decision about whether to restore the Voyager database back to Friday night in order to re-run the order load. If we opt to re-run the order load we will have to delay our go live date by a week. We will have to delay by a week in order to give the circ imp. team enough time to complete the sysadmin work (some of which will be lost by the database restore) that must be in place before the circ conversions start.
The problem with the order load is that orders with foreign currencies migrated with $0 prices. Roughly 15% of our 112000 orders have prices in foreign currencies. Today Endeavor identified the cause of this problem. They can fix it by re-running the order load. We asked them to consider writing a special program to update just the problem orders instead of reloading all orders. They are considering this option, but without more analysis cannot say if and when they'll run it.
Our options are:
1) Restore database, reload orders, delay go-live by a week. (Also delay start of Acq by an additional day until Wed, 7/10).
2) Require Endeavor to write a program to update just the problem orders.
3) Accept the order load as is and update each order as invoices come in.
I am leaning heavily toward option #1 for the following reasons:
- It is the no-risk way to fix the orders. A special program introduces an opportunity for additional problems. If we insist on a special program we will be sitting on our hands -- work will have to stop on prodorbis Voyager -- until Endeavor determines if it's doable (probably 1/2 day) which will add more pressure to the Circ Imp team. If we opt of manual correction we will be adding yet another step to the already complicated Acq workflow.
- For the past 3 days during which Voyager prodorbis was up, we experienced system downtime. All clients froze and could not connect to the database. Each outage lasted 1.5-2 hours. From their diagnostic work this weekend, ITS believes the problem is with a network card that is used by the internal, private network that connects our 2 production servers together.
If we delay a week we will have more time to ensure the problem is fixed. Going live and then going down would be worse PR than delaying a week.
- Circ Imp members have a massive amount of sysadmin work to complete before the circ conversions. If we delay a week they will have more time to complete this work. They are feeling extra pressured because the downtime from the network card has cut into their available time by about 5 hours.
The downside to restoring and reloading the orders is:
- We've announced July 16th to the public and already printed publicity with that date. Missing the date is a let-down especially for Implementation staff.
- We have to continue interim workflow for an additional week which will mean holding more material and extra double keying.
- Some units can't do any of their normal work until circ goes live (LSF, Course Reserve operations, recon cleanup in Cat Management).
Thank you for responding with your recommendations.