After much back and forth with support while testing migrations and upgrades from SLM 7.1 to 7.6.03 and .04 last winter/spring, we were told that the only viable path from SLM 7.1 to 7.6.04 was to upgrade the application. It is the configuration data - service agreements, targets, measurements, etc., that must be upgraded; you cannot move them directly from 7.1 tables to 7.6.04 tables. There is also the problem that many of these objects have system-built z filters associated with the data records, and these correlations do NOT migrate well at all.
We did the upgrade last summer, using the method where you build an offline replica of production and upgraded it; SLM was upgraded from 7.1.00.002 to 7.6.00.001, then 7.6.03, then 7.6.04.01. The rest of the ITSM suite followed similar contorted paths, as recommended by one of the few BMC support folks who knew what they were talking about. Then we restored the upgraded db under a new server installed fresh with all the 7.6.04.01 components, to eliminate all of the legacy 32-bit directory structures; the data remains the same, right down to the T-table numbers. During acceptance testing we kept the following transaction data tables for SLM up to date from production using RRR|Chive every night: SLM:Measurement *which had an overlay SLM:EventSchedule SLM:MilestoneLogging SLM:RuleActionNotifier * SLM:Measurement had to be overlaid - the field Previous Status (301412100) in 7.1 had an enumeration of Pending with ID of '2' that was deprecated in SLM 7.6.04.01, but since the existing 3 years of data contained that enumeration, for whatever reason, it could not be refreshed using RRR|Chive without restoring that enumeration using an overlay. This allowed us to push new Incidents and updates to incidents, along with their associated SLM measurement records, from production to the future production system right up to the point of cutover. It also allowed us to fully test new incidents with attached service targets on the new system without conflict; we set all of the NextIDs for ALL of the necessary tables to a much higher number before beginning testing, and limited RRR|Chive updates to the ranges below them. On my system (where Asset and CMDB are empty), there were 225 tables where I had to set the NextID to a new, higher value on the upgraded system before (a) beginning to refresh production data to it, and (b) before creating any new test or foundation data entries. As near as we could tell when we went live last August, all of the upgraded, migrated, and new SLM transaction data was working properly with Incidents, and escalating properly both before and after the new server was cutover into production. It also appeared correctly in the SLM Dashboards, with some severe initial problems that required db-level data fixes in SQL to data that did not upgrade or migrate properly - where SLM:Measurement stores the server name as an explicit value in the Status Image Tag field - these have to be changed to match the new server or they cause all sorts of problems, up to and including crashing the tomcat server under mid-tier! Be sure to turn off email on the old production server unless you want duplicate escalation notifications; we had some escape the first week on a restart of the old server, which is still "in production" to authenticate for Remedy Knowledge Management 7.2, which is also still in production (RKM 7.6.04.01 displays no search results in Safari, among a myriad of other uncorrected problems). Also, I cannot personally recommend moving from 7.1 to 7.6.04.02 - I gave up on SP2 last November as DOA - almost every installer has fatal problems when run on a system upgraded from 7.1/7.0. MAYBE they will have them fixed in Sp3, but I'm not holding my breath. If you go to Sp1 instead of Sp2, however, there is a slew of hotfixes you will need for Sp1 before using it in production! You may just have to slog through the Sp2 installer problems to get the newer code, then fix all of the known issues CREATED by Sp2 afterwards. Or do all of your testing/setup/planning but execute with Sp3. If you don't drink, upgrading SLM could drive you to it. 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 Melissa Reed Sent: Thursday, February 02, 2012 1:36 PM To: [email protected] Subject: Migrating SLM 7.1 to 7.6.04 Does anyone have any experience migrating data for SLM (integrated with Incident) from a SLM 7.1 environment to SLM 7.6.04? We are migrating open incident data and need to maintain the ongoing service targets that are already attached. In addition we will need to be able to report on the migrated data as well. TIA! Melissa _______________________________________________________________________________ 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"
