Going forward, on any of your virgin ITSM apps or out of the box Remedy products, its good to NOT modify the existing code directly, but disable what you want to modify, rename the code with a postfix and SAVE AS, so that the modified code remains next to the original, so that after any upgrade or patch, the original is found or detected by the install script, and then you can decide whether you let the original be as it is and disable the modified code or disable the original once again and continue using the modified.
Its the best practice on any virgin OTB apps that I have come across.. Easy to maintain and document, and less painful to migrate, patch or upgrade... While performing modifications on the form itself by way of adding fields, STAY CLEAR of the range of field ID's Remedy are likely to use on future patches or upgrades. I usually use field ID's in the 7, 8 or 9 million range. DO NOT delete fields (of any kind) you do not want to use. Hide them. USE the Change History on the form, fields or workflow wherever possible to document reasons for change and the content of change itself.. Joe D'Souza -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Barber, Dave Sent: Tuesday, November 06, 2007 9:43 AM To: [email protected] Subject: Re: What has been customized. A third on that as well. I managed a migration from v4 to v6 apps, and decided eventually to drop virtually every bespoke change that had been made - just a couple of essential pieces of data were added to the main helpdesk form, and keeping the look similar to the standard v6 apps, but putting some of the fields users were used to seeing in easily accessible locations. It was also made a little more "interesting" by the documentation for the changes prior to my working on the system were somewhat basic, sometimes verging on non-existent. Also, when you do finally go through the process of migrating from 6 to 7, document the changes, and follow the various guidelines that are around for handling the changes as well. Good luck with the migration. Regards Dave Ps. We're going to be going through an ITSM5 to 7 change at some point in the not-too-distant future, should be most "interesting". -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of William Rentfrow Sent: 06 November 2007 13:19 To: [email protected] Subject: Re: What has been customized. I'll second that - I might go so far as to say skip detailing what the differences are between the base product in 6 and what you've customized. That's really not the problem you are trying to solve. Instead sit down and really document the business requirements. Then match those to the functionality in 7 (which can take a while since ITSM 7 is much more robust than 6 was). Identify all the areas where functionality is lacking and customize accordingly. We are in the process of doing this for a major Federal customer who previously had customized extensively. We still have to do some minor customization to fulfill their needs but by using base product features we've avoided literally hundreds of minor and several major customizations. The only ones we've had to customize for so far are things like: -Telephony Integration -Custom data loads and integrations -Data Display (ie, need employee ID# in the "Search People" window) -Several custom data fields - we keep these on a separate tab in the HPD:HelpDesk form in Incident to make future migration easier. William Rentfrow Principal Consultant, StrataCom [EMAIL PROTECTED] O 952-432-0227 C 701-306-6157 ________________________________ From: Action Request System discussion list(ARSList) on behalf of Murtuza B Sent: Tue 11/6/2007 6:55 AM To: [email protected] Subject: Re: What has been customized. ** Hi Frex, Rather than looking @ specific workflow and fields that were customized, I would suggest you look only @ broad functionality. If you know how an OOTB 6.0 installation works, you can know broadly what basic functions have been added / customized in your install. Interact with daily users of the apps. After that you can chk what is already available on 7.0 & cross them off the list. The rest can be implemented in the new version if still required. It is my opinion that it is generally useless to carry unwanted baggage from previous releases. Also, since the ITSM workflow in 7.0 is very different from 6.0, you cannot hope to actually move any workflow directly to the new version, unless it is an independant application. HTH. Murtuza. ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Frex Popo Sent: Tuesday, November 06, 2007 1:29 PM To: [email protected] Subject: What has been customized. ** Hello everyone, I am planning to upgrade to ITSM 7.0. I have ITSM 6.0 at the moment and do not know what has been added, changed or removed (customised) in the current installation. One way of finding out, I am thinking, is to install ITSM6.0 from afreash on a seperate machine and use Migrator to run a diff reports between similar sets of object on both installations. Is this the best way in going about it or is there another easy way? Anything that you think I should bear in mind etc. Kind Regards Frex. No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.15.23/1113 - Release Date: 11/6/2007 10:04 AM _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
