Pour a fresh cup of coffee (or whiskey) and settle in comfortably before reading ;-)
The following long and arduous process worked last year (May to August 2011) for our upgrade from 7.1 to 7.6.04.01: The production system was upgraded as follows, using a staging server for the upgrades and overlay process, then restoring the db to a new production server which was a new 64-bit install of the program files (upgrades on same box remain in the (x86) structure): ARS from 7.1.00.002 to 7.1.00.011 to 7.5.00.007 to 7.6.03 to 7.6.04 SP1 CMDB from 2.1.00.002 to 2.1.00.006 to 7.6.00.002 to 7.6.03.001 to 7.6.04 SP1 AIE from 7.1.00.003 to 7.1.00.008 to 7.6.00.002 to 7.6.03.001 to 7.6.04 SP1 ITSM from 7.0.03.009 to 7.6.00.001 to 7.6.03 to 7.6.04 SP1 SLM from 7.1.00.002 to 7.6.00.001 to 7.6.03 to 7.6.04 SP1 The upgrade was chosen because all attempts to migrate live SLM data failed; SLM must be upgraded in place. After upgrading to 7.6.04.01, we ran BPCU Successfully in Prefixed Overlay Mode to change our customized workflow to Custom, which we then disabled. Using BPCU on forms proved to be a disaster in earlier testing (hundreds of forms were overlaid incorrectly) so we avoided that on the final upgrade and created all of the form/view/field overlays by hand from 7.6.04.01 objects. Otherwise you get overlays of the much older (7.0) version of the form, which don't work properly in 7.6.04. The same was done with workflow, since much of that was changed significantly from 7.0.x to 7.6.04.01 and it is easier to start with an overlay of the newest version of the object (active link, filter, guide) and add only your changes; if you use the BPCU-created overlay it will be missing every change from 7.0 to 7.6.04.01, and you will have to add those as in as well! After all of the upgrade and overlay processes were complete, we ran the new production server in parallel to the old production system for a month of acceptance testing, during which time updates to data in dozens of tables on production were synced to the new server nightly using batches of RRR|Chive scripts (including SLM transactions!!). This was done safely by setting the NextID on all of those tables to the next 10,000, 100,000, or whatever level so that all new records in Incident, SLM, Email, etc., on the new server never conflicted with data coming in from production each night. That also meant that any work on the new production server by our early-adopting departments was real, live data, and would remain live after the cutover. Cutover involved setting the old production server to Administrator-Only Mode, and changing the web page links to the new mid-tiers and iframes to point at the newer Kinetic Request console, which we also upgraded from 4.0.3 to 5.0.2. The patch level to patch level jumps were recommended by BMC based upon what they were seeing actually work - other patch levels and larger jumps were failing miserably for us and for other customers. I cannot tell you what to use for the jump from 7.0.01.006 to 7.1.00.002, and only ONE BMC support tech was savvy enough to be able to recommend the sequence we finally used. They have a good reason to want you to jump from ITSM 7.0.01.006 to 009 first; we started there, and there were a LOT of changes in 008 and 009. On operating systems, we remained on Windows 2003 servers (from 2003 to 2003 R2) due to lane java requirements for AlarmPoint - a complete waste since that product turned out to be a disastrous failure against ITSM 7.6.04. The db went from SQL Server 2005 to 2008 with that hosted on Windows 2008 R2. You must go through all of the db cleanup steps every time you move the db and restore it under a different server; that has been discussed on the list recently, as well as in the archives. In our case that was once on the staging server before all of the upgrades (restored from old production), and again on the new production server when restored from the staging server. One last warning; when you upgrade a server that many levels, some tables and views are never upgraded the way that the BMC developers think they should be, and when we tested the 7.6.04.02 installers for Atrium and ITSM they choked on a number of tables/views left over in the system upgraded to 7.6.04.01, which were not as they would be in a NEW 7.6.04.01 install. After fighting with BMC support (they never seemed to fully understand this), we abandoned 7.6.04.02 for the apps (ARS went to Sp3 correctly, but not Sp2) and are still on SP1. We will have to fight this again to get to 8.0.x, unless we switch to a different vendor's product. I cannot speak for SRM - we did not use it and still don't, but installed it on the new 7.6.04.01 server and left it alone. Also RKM 7.6.04.01 - installed it and left it alone. We are still live on RKM 7.2 due to the MYRIAD problems we found in RKM 7.6.04.01, some of which still have not been fixed in 8.0.00! Since it appears that you do not have either one in production now, that is two less headaches for the upgrade. As to upgrading to 8.0.00, I have not tried that yet and won't until SP1 comes out. I put a Preconfigured Stack Install on a couple of Windows 2008 R2 VMs easily enough, but had trouble with all of the Patch installers (now on ARS Patch 002, apps Patch 001). It turns out that they must be run as administrator in order to work in our setup, which was not true of the stack installer. I would not rate 8.0.00 as ready for production yet, and if you have customizations you will want to get them moved to overlays at the point where you have upgraded to 7.6.04.01. If all this scares the heck out of you, and you are not required to upgrade (I don't see SLM on your list of implemented apps), the new install - customize - migrate data option may be a lot less trouble. Many of our customizations were eliminated in the jump from 7.0 apps to 7.6.04, and another major one (adding Login Name back in as the key field for people searches) has FINALLY been restored in 8.0 and I will be able to drop it in that upgrade if we decide to move up. As William pointed out, you have to read and re-read a lot of upgrade documentation, most of which was incomplete or incorrect for 7.6.03 and 7.6.04.00. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Mary C. Sent: Tuesday, November 20, 2012 8:05 PM To: [email protected] Subject: AR System & ITSM Upgrades (we are WAY behind) Hi, We are on AR System 7.0.01 Patch 006, CMDB 2.0.1, ITSM 7.0.3 Patch 006 and SLM 7.0.1 Patch 4. We were unable to consider upgrading until now, and of course this is going to be a major effort from what I can see. We have some customizations, but I think I could rebuild them from scratch if I had to. We are in a Windows/SQL server setup and are running a server group. We want to upgrade everything to 8.0 Here is a high-level upgrade path that Support recommended. A) Upgrade ITSM 7.0.3 patch 6 to ITSM 7.0.3 patch 9. B) Run ARserver 7.6.04 patch 4 in upgrade mode. C) Run the difference report to find the customization. D) Create Overlay to retain customization. E) Then upgrade CMDB 7.6.04 patch 4 F) Then upgrade ITSM 7.6.04 patch 4. G) Once everything is working fine upgrade ARS, CMDB and ITSM to 8.0 Do you all agree with this upgrade path? Would you recommend another approach? Any advice you can give me would be appreciated. Many of you have listed lots of gotchas, so I am semi-planning for those pitfalls. Thank! _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
