Hi Karthick, I agree with Rick in advocating standing up a new environment and moving your data to it. There are many advantages to doing thing this way and I probably don't have to list them all here. Stand up a new environment, on a new database, install ARS, ITSM to each server in the group, get it patched to the right versions, apply the customization you need to preserve via overlays (some may be covered in the new version), then use rrr|Chive or similar to move the data to the new environment.Perhaps use this as an opportunity to archive old unnecessary data at the same time (eg old notification logs). Using this approach you will be able to test your new system in full prior to the big cutover weekend. On a big system it can take time to synchronize the data but rrr|Chive's synctotarget feature can be used to minimize any duplication of effort and this can all be done up front.
There are (at least) a couple of gotchas to be aware of if you do stand up a new server and move your data to it. 1. Some forms have had unique indexes added to the "Instance ID" field. They probably should have been there all along but if you have somehow allowed duplicate instance IDs to creep in (via "copy to new") then you will need to clear this field and generate new IDs for the dupes when moving data to the new system. 2. Doing an in-place upgrade to a system populated with data can take a very long time and can timeout before completion. I presume the upgrades can sometime do data conversions and this is the reason. I think in one instance it tries to push fields to every row in a table in one transaction and that kept repeating, timing out or reaching the filter limit before rolling back. Best advice is to try and avoid doing an in-place upgrade to systems with lots of data. Clear the data out of impacted tables, do the upgrade and then replace the data. That's why it is best to do the patch upgrades prior to moving data to new system. 3. Some of the same out of the box foundation data has different request IDs between versions of ITSM. If you try and merge the foundation data between 2 different releases of ITSM you can end up with duplicate permission groups or similar. identify the real key and delete the dupes on migration. I'm sure there are some other gotchas and as Rick says when you start combining changes to the data as you migrate things can get a little messy but I think you may be surprised how easy it actually is to move the data from one version of remedy to a new one. Rod Harris PS BMC advocates using DDM Delta Data Migrator which does a similar job to rrr|Chive On Saturday, 21 February 2015, Rick Westbrock <rwestbr...@24hourfit.com> wrote: > ** > > Good point, it should be easier to get AR working properly then ITSM > before worrying about getting your old data into the mix. I have the fun of > building a new product catalog as part of the upgrade as well as changing > from multi-tenant to single-tenant so it’s going to be a fun ride over here. > > > > -Rick > > > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Rick Cook > *Sent:* Friday, February 20, 2015 8:36 AM > *To:* arslist@ARSLIST.ORG > *Subject:* Re: Remedy Upgrade - Suggestions required. > > > > ** > > Yup. We are doing the same upgrade, and are doing it via the build and > migrate plan, not an upgrade in place. > > > > There are some bugs in the 8.1.02 installers, too, as I am finding. All > the more reason to do it in a simpler environment. > > > Rick Cook > > > > On Fri, Feb 20, 2015 at 8:29 AM, Rick Westbrock <rwestbr...@24hourfit.com> > wrote: > > ** > > Karthick- > > > > I know that others share my opinion that when you are jumping ahead > multiple big versions like this it is probably better to stand up a fresh > 8.1.02 environment and migrate relevant data from the old system to the > new. That is my plan when I get a chance to work on upgrading our 7.1 > environment to 8.1.02 myself (although I am working with Linux servers). I > believe there were quite a few posts to the list in the last six months or > so regarding exactly this topic so you might want to visit arslist.org > and search for the old posts there. > > > > In fact I did a quick search of my mailbox and found a thread named > “Upgrade to 8.1 AR/ITSM” from just last month regarding this. Contact me > off-list if you would like me to send over the messages. That thread had a > mention of the AMIGO program which you should also investigate. > https://kb.bmc.com/infocenter/index?page=content&id=KA404408 > > > > -Rick > > > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Karthick S > *Sent:* Thursday, February 19, 2015 9:51 PM > *To:* arslist@ARSLIST.ORG > *Subject:* Remedy Upgrade - Suggestions required. > > > > ** > > We are planning to do an upgrade in Remedy, please provide your > suggestions on this. > > > > Our current remedy environment is 7.1 Version and it’s database version is > SQL 2005. > > We are planning for an upgrade it to latest version 8.1.02 version. > > We have planned in 2 sections, first upgrading Remedy 7.1 to 7.6.04 and > then to 7.6.04 to 8.1.02. > > > > We have a new test server which is Windows Server 2012 R2 64 Bit and SQL > Server 2014 64 Bit Enterprise Edition. > > > > We have planned to take a backup copy of AR System DB from production > server which has DB version 2005 and copied into 2014 SQL DB version, from > their we can perform the upgrade. > > Is it possible, please let me know.? > > > > Or creating a test DB at 2005 SQL version, start the upgrade in Windows > Server 2012 R2 64 Bit and point it to test DB (2005 SQL version) and later > on moving the DB instance from 2005 SQL DB to 2014 SQL DB. > > > > > > > > > > > > > > *Regards,* > > *Karthick Sundararajan* > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
