Re: Upgrade from 7.1 to 7.6.04
For whatever my 2 cents is worth, I used DSO to transfer the data (as an independent copy). Seemed to work pretty well - of course as with any solution, you'll need to go through the pain of identifying any mapping issues, validation, etc. Just something that worked for me. - Original Message - From: "Brian Pancia" To: arslist@ARSLIST.ORG Sent: Wednesday, September 12, 2012 2:40:53 PM Subject: Re: Upgrade from 7.1 to 7.6.04 ** Tauf, RKM is the one piece that scares me a little. I've been trying to search various threads on the upgrade, because I know there are several out there. I'm hoping more and more people have started going down this path. Our tried and true method has always been to move customizations over and then data, which depending on the versions becomes a mapping nightmare. We actually used AIE in the past for an upgrade, which was interesting. For this upgrade we've migrated a lot of the foundational data over, which has caused many headaches. I'm hoping to start incorporating some of the other technologies in the upgrade process. Hopefully the other technologies can help streamline the process. What I need to start doing is saving a vm of each version, so in the future I can test various upgrade scenarios out. I've done a ton of upgrades, but unfortunately it is never the same combination of versions. Thanks again for the info on RKM. Brian On Wed, Sep 12, 2012 at 2:13 PM, Tauf Chowdhury < taufc...@gmail.com > wrote: ** For your question: Since there are drastic differences for RKM between 7.1 and 7.604 will DDM and RRRChive work or will it be a headache regardless? Within RKM 7.6.4 is an import tool which will convert articles from older versions to the new system. If I remember correctly, you can only move "Published" articles. Everything in Draft will have to be left behind. You should set a drop dead date for getting articles published in your old system. I also remember breaking out the import into different types such as Referece, Known Errors, Solutions, How-To, etc... This allows you to process chunks of data as opposed to the whole thing. This is also because you may notice some articles failing and you will have to comb the error logs to find out why. I remember there were also some bugs which may/may not be addressed by Sp3 and Sp4. One such bug was if the old article's title had an extension in it.. like "Article1.doc" was the name of the article, this would bomb out the article conversion tool. The .file extension would throw off whatever mechanism it uses to parse the .xml files from the old RKM system. Another bug, which again, not sure if it is fixed or not, was that you would lose audit and article history from the old records. On Wed, Sep 12, 2012 at 2:01 PM, Brian Pancia < panc...@finityit.com > wrote: ** These are the steps we typically take, but for major version upgrades 5x to 6x or 6x to 7x. In that case it is usually best just to bring in the old data as archive data and start fresh. For this upgrade the customer wants everything brought over. What are the limitations with DDM besides deletes? Are there workarounds to these limitations? It looks like people have had a lot of success with RRRChive. Is RRRChive difficult to setup and configure for this type of upgrade or is it better suited for bring subsets of data between systems? Since there are drastic differences for RKM between 7.1 and 7.604 will DDM and RRRChive work or will it be a headache regardless? Thanks, Brian On Wed, Sep 12, 2012 at 12:15 PM, Goodall, Andrew C < ago...@jcp.com > wrote: ** We are on 7.5 migrating to 7.6.04 next weekend – God willing J I would recommended - Move customization, import clean foundation data, leave old record data – start with new record data. If old record data is a must have, then there are limitations with DDM - I don’t recommended it, primarily it does not recognize deletes, and ITSM uses delete operations for many functions that will not be picked up. Global search / FTS is a complete waste of time and a big headache – it is over sold as a feature, in my view it is only beneficial for searching RKM data where it actually uses a boost relevancy. Regards, Andrew C. Goodall Software Engineer Development Services ago...@jcpenney.com jcpenney 6501 Legacy Drive Plano, TX 75024 jcp.com From: Action Request System discussion list(ARSList) [mailto: arslist@arslist.org ] On Behalf Of Brian Pancia Sent: Wednesday, September 12, 2012 10:23 AM To: arslist@arslist.org Subject: Upgrade from 7.1 to 7.6.04 ** We are in the process of upgrade 7.1 to 7.604 with all the ITSM apps and some minor customizations. There are a few paths we are trying: - move customizations over and migrate data over to new syst
Re: Upgrade from 7.1 to 7.6.04
Tauf, RKM is the one piece that scares me a little. I've been trying to search various threads on the upgrade, because I know there are several out there. I'm hoping more and more people have started going down this path. Our tried and true method has always been to move customizations over and then data, which depending on the versions becomes a mapping nightmare. We actually used AIE in the past for an upgrade, which was interesting. For this upgrade we've migrated a lot of the foundational data over, which has caused many headaches. I'm hoping to start incorporating some of the other technologies in the upgrade process. Hopefully the other technologies can help streamline the process. What I need to start doing is saving a vm of each version, so in the future I can test various upgrade scenarios out. I've done a ton of upgrades, but unfortunately it is never the same combination of versions. Thanks again for the info on RKM. Brian On Wed, Sep 12, 2012 at 2:13 PM, Tauf Chowdhury wrote: > ** For your question: Since there are drastic differences for RKM between > 7.1 and 7.604 will DDM and RRRChive work or will it be a headache > regardless? > > Within RKM 7.6.4 is an import tool which will convert articles from older > versions to the new system. If I remember correctly, you can only move > "Published" articles. Everything in Draft will have to be left behind. You > should set a drop dead date for getting articles published in your old > system. I also remember breaking out the import into different types such > as Referece, Known Errors, Solutions, How-To, etc... This allows you to > process chunks of data as opposed to the whole thing. This is also because > you may notice some articles failing and you will have to comb the error > logs to find out why. I remember there were also some bugs which may/may > not be addressed by Sp3 and Sp4. One such bug was if the old article's > title had an extension in it.. like "Article1.doc" was the name of the > article, this would bomb out the article conversion tool. The .file > extension would throw off whatever mechanism it uses to parse the .xml > files from the old RKM system. Another bug, which again, not sure if it is > fixed or not, was that you would lose audit and article history from the > old records. > > > On Wed, Sep 12, 2012 at 2:01 PM, Brian Pancia wrote: > >> ** These are the steps we typically take, but for major version upgrades >> 5x to 6x or 6x to 7x. In that case it is usually best just to bring in the >> old data as archive data and start fresh. For this upgrade the customer >> wants everything brought over. What are the limitations with DDM besides >> deletes? Are there workarounds to these limitations? It looks like people >> have had a lot of success with RRRChive. Is RRRChive difficult to setup >> and configure for this type of upgrade or is it better suited for bring >> subsets of data between systems? Since there are drastic differences for >> RKM between 7.1 and 7.604 will DDM and RRRChive work or will it be a >> headache regardless? >> >> >> Thanks, >> >> Brian >> >> >> >> On Wed, Sep 12, 2012 at 12:15 PM, Goodall, Andrew C wrote: >> >>> ** >>> >>> We are on 7.5 migrating to 7.6.04 next weekend – God willing J >>> >>> ** ** >>> >>> I would recommended - Move customization, import clean foundation data, >>> leave old record data – start with new record data. >>> >>> ** ** >>> >>> If old record data is a must have, then there are limitations with DDM >>> - I don’t recommended it, primarily it does not recognize deletes, and ITSM >>> uses delete operations for many functions that will not be picked up.*** >>> * >>> >>> ** ** >>> >>> Global search / FTS is a complete waste of time and a big headache – it >>> is over sold as a feature, in my view it is only beneficial for searching >>> RKM data where it actually uses a boost relevancy. >>> >>> ** ** >>> >>> Regards, >>> >>> **** >>> >>> *Andrew C. Goodall* >>> >>> Software Engineer >>> >>> Development Services >>> >>> ago...@jcpenney.com >>> >>> *jcpenney* >>> >>> 6501 Legacy Drive >>> >>> Plano, TX 75024 >>> >>> jcp.com >>> >>> ** ** >>> >>> *From:* Action Request System discussion list(ARSList) [mailto: >>> arslist@arslist.org] *On Beh
Re: Upgrade from 7.1 to 7.6.04
For your question: Since there are drastic differences for RKM between 7.1 and 7.604 will DDM and RRRChive work or will it be a headache regardless? Within RKM 7.6.4 is an import tool which will convert articles from older versions to the new system. If I remember correctly, you can only move "Published" articles. Everything in Draft will have to be left behind. You should set a drop dead date for getting articles published in your old system. I also remember breaking out the import into different types such as Referece, Known Errors, Solutions, How-To, etc... This allows you to process chunks of data as opposed to the whole thing. This is also because you may notice some articles failing and you will have to comb the error logs to find out why. I remember there were also some bugs which may/may not be addressed by Sp3 and Sp4. One such bug was if the old article's title had an extension in it.. like "Article1.doc" was the name of the article, this would bomb out the article conversion tool. The .file extension would throw off whatever mechanism it uses to parse the .xml files from the old RKM system. Another bug, which again, not sure if it is fixed or not, was that you would lose audit and article history from the old records. On Wed, Sep 12, 2012 at 2:01 PM, Brian Pancia wrote: > ** These are the steps we typically take, but for major version upgrades > 5x to 6x or 6x to 7x. In that case it is usually best just to bring in the > old data as archive data and start fresh. For this upgrade the customer > wants everything brought over. What are the limitations with DDM besides > deletes? Are there workarounds to these limitations? It looks like people > have had a lot of success with RRRChive. Is RRRChive difficult to setup > and configure for this type of upgrade or is it better suited for bring > subsets of data between systems? Since there are drastic differences for > RKM between 7.1 and 7.604 will DDM and RRRChive work or will it be a > headache regardless? > > Thanks, > > Brian > > > > On Wed, Sep 12, 2012 at 12:15 PM, Goodall, Andrew C wrote: > >> ** >> >> We are on 7.5 migrating to 7.6.04 next weekend – God willing J >> >> ** ** >> >> I would recommended - Move customization, import clean foundation data, >> leave old record data – start with new record data. >> >> ** ** >> >> If old record data is a must have, then there are limitations with DDM - >> I don’t recommended it, primarily it does not recognize deletes, and ITSM >> uses delete operations for many functions that will not be picked up. >> >> ** ** >> >> Global search / FTS is a complete waste of time and a big headache – it >> is over sold as a feature, in my view it is only beneficial for searching >> RKM data where it actually uses a boost relevancy. >> >> ** ** >> >> Regards, >> >> >> >> *Andrew C. Goodall* >> >> Software Engineer >> >> Development Services >> >> ago...@jcpenney.com >> >> *jcpenney* >> >> 6501 Legacy Drive >> >> Plano, TX 75024 >> >> jcp.com >> >> ** ** >> >> *From:* Action Request System discussion list(ARSList) [mailto: >> arslist@arslist.org] *On Behalf Of *Brian Pancia >> *Sent:* Wednesday, September 12, 2012 10:23 AM >> *To:* arslist@arslist.org >> *Subject:* Upgrade from 7.1 to 7.6.04 >> >> ** ** >> >> ** >> >> We are in the process of upgrade 7.1 to 7.604 with all the ITSM apps and >> some minor customizations. >> >> ** ** >> >> There are a few paths we are trying: >> >> ** ** >> >> **- **move customizations over and migrate data over to new >> system >> >> **- **use the Delta Data Migration Tool and a staging server as >> outlined in the BMC whitepaper >> >> **- **move customizations over and use RRRChive to migrate data >> over >> >> ** ** >> >> Has anyone else attempted this upgrade? What path did you chose? Are >> there any lessons learned or recommendations? >> >> ** ** >> >> Thanks, >> >> ** ** >> >> Brian >> >> ** ** >> >> _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ >> >> The information transmitted is intended only for the person or entity to >> which it is addressed and >> may contain confidential and/or privileged material. If the reader of >> this message is not the intended >> recipient, you
Re: Upgrade from 7.1 to 7.6.04
These are the steps we typically take, but for major version upgrades 5x to 6x or 6x to 7x. In that case it is usually best just to bring in the old data as archive data and start fresh. For this upgrade the customer wants everything brought over. What are the limitations with DDM besides deletes? Are there workarounds to these limitations? It looks like people have had a lot of success with RRRChive. Is RRRChive difficult to setup and configure for this type of upgrade or is it better suited for bring subsets of data between systems? Since there are drastic differences for RKM between 7.1 and 7.604 will DDM and RRRChive work or will it be a headache regardless? Thanks, Brian On Wed, Sep 12, 2012 at 12:15 PM, Goodall, Andrew C wrote: > ** > > We are on 7.5 migrating to 7.6.04 next weekend – God willing J > > ** ** > > I would recommended - Move customization, import clean foundation data, > leave old record data – start with new record data. > > ** ** > > If old record data is a must have, then there are limitations with DDM - > I don’t recommended it, primarily it does not recognize deletes, and ITSM > uses delete operations for many functions that will not be picked up. > > ** ** > > Global search / FTS is a complete waste of time and a big headache – it is > over sold as a feature, in my view it is only beneficial for searching RKM > data where it actually uses a boost relevancy. > > ** ** > > Regards, > > > > *Andrew C. Goodall* > > Software Engineer > > Development Services > > ago...@jcpenney.com > > *jcpenney* > > 6501 Legacy Drive > > Plano, TX 75024 > > jcp.com > > ** ** > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@arslist.org] *On Behalf Of *Brian Pancia > *Sent:* Wednesday, September 12, 2012 10:23 AM > *To:* arslist@arslist.org > *Subject:* Upgrade from 7.1 to 7.6.04 > > ** ** > > ** > > We are in the process of upgrade 7.1 to 7.604 with all the ITSM apps and > some minor customizations. > > ** ** > > There are a few paths we are trying: > > ** ** > > **- **move customizations over and migrate data over to new > system > > **- **use the Delta Data Migration Tool and a staging server as > outlined in the BMC whitepaper > > **- **move customizations over and use RRRChive to migrate data > over > > ** ** > > Has anyone else attempted this upgrade? What path did you chose? Are > there any lessons learned or recommendations? > > ** ** > > Thanks, > > ** ** > > Brian > > ** ** > > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ > > The information transmitted is intended only for the person or entity to > which it is addressed and > may contain confidential and/or privileged material. If the reader of this > message is not the intended > recipient, you are hereby notified that your access is unauthorized, and > any review, dissemination, > distribution or copying of this message including any attachments is > strictly prohibited. If you are not > the intended recipient, please contact the sender and delete the material > from any computer. > _attend WWRUG12 www.wwrug.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"
Re: Upgrade from 7.1 to 7.6.04
We did the same 7.1 to 7604 SP3 - move customizations over and use RRRChive to migrate data over thanks Ravi Date: Wed, 12 Sep 2012 11:22:38 -0400 From: panc...@finityit.com Subject: Upgrade from 7.1 to 7.6.04 To: arslist@ARSLIST.ORG ** We are in the process of upgrade 7.1 to 7.604 with all the ITSM apps and some minor customizations. There are a few paths we are trying: - move customizations over and migrate data over to new system - use the Delta Data Migration Tool and a staging server as outlined in the BMC whitepaper - move customizations over and use RRRChive to migrate data over Has anyone else attempted this upgrade? What path did you chose? Are there any lessons learned or recommendations? Thanks, Brian _attend WWRUG12 www.wwrug.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"
Re: Upgrade from 7.1 to 7.6.04
We are on 7.5 migrating to 7.6.04 next weekend - God willing J I would recommended - Move customization, import clean foundation data, leave old record data - start with new record data. If old record data is a must have, then there are limitations with DDM - I don't recommended it, primarily it does not recognize deletes, and ITSM uses delete operations for many functions that will not be picked up. Global search / FTS is a complete waste of time and a big headache - it is over sold as a feature, in my view it is only beneficial for searching RKM data where it actually uses a boost relevancy. Regards, Andrew C. Goodall Software Engineer Development Services ago...@jcpenney.com jcpenney 6501 Legacy Drive Plano, TX 75024 jcp.com From: Action Request System discussion list(ARSList) [mailto:arslist@arslist.org] On Behalf Of Brian Pancia Sent: Wednesday, September 12, 2012 10:23 AM To: arslist@arslist.org Subject: Upgrade from 7.1 to 7.6.04 ** We are in the process of upgrade 7.1 to 7.604 with all the ITSM apps and some minor customizations. There are a few paths we are trying: - move customizations over and migrate data over to new system - use the Delta Data Migration Tool and a staging server as outlined in the BMC whitepaper - move customizations over and use RRRChive to migrate data over Has anyone else attempted this upgrade? What path did you chose? Are there any lessons learned or recommendations? Thanks, Brian _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If the reader of this message is not the intendedrecipient, you are hereby notified that your access is unauthorized, and any review, dissemination,distribution or copying of this message including any attachments is strictly prohibited. If you are notthe intended recipient, please contact the sender and delete the material from any computer. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
Upgrade from 7.1 to 7.6.04
We are in the process of upgrade 7.1 to 7.604 with all the ITSM apps and some minor customizations. There are a few paths we are trying: - move customizations over and migrate data over to new system - use the Delta Data Migration Tool and a staging server as outlined in the BMC whitepaper - move customizations over and use RRRChive to migrate data over Has anyone else attempted this upgrade? What path did you chose? Are there any lessons learned or recommendations? Thanks, Brian ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
