Customizations to the app are best moved with Migrator. You can build a fresh test server, migrate the customizations to it from development or production, then apply a patch or run an upgrade to see how it affects those customizations. Then later you can apply the same patch (or upgrade, but good luck with that) to development or production and then migrate the customizations back over from test.
Typically I refresh development from production by restoring the db from a backup of production. Then there is a LONG list of places you have to update the clone on development to remove server and mid-tier references to the production environment (and remove notifications that are waiting to go out). Next you can apply a patch, then re-migrate customizations from production. Once you document everything that you have to do to restore customizations after patching, you can patch production and migrate the customizations back from development. That is essentially how we got from ITSM 7.0.03.007 to 009. Christopher Strauss, Ph.D. Call Tracking Administration Manager University of North Texas Computing & IT Center http://itsm.unt.edu/ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Shyam Attavar Sent: Friday, March 05, 2010 2:00 PM To: [email protected] Subject: Re: Refreshing the DB for ITSM 7.1.0 ** Thanks for the suggestion Saby, But I am looking for a way to move customizations only and not the data. Thanks to Joe D'Souza for his suggestion and I will most likely be using that for our needs. Regards, -- Shyam ________________________________ From: Sabyson Fernandes <[email protected]> To: [email protected] Sent: Fri, March 5, 2010 6:08:39 AM Subject: Re: Refreshing the DB for ITSM 7.1.0 ** Hi Shyam, Have you looked into rrrChive? Its a great utility for copying over data from one server to another. I use it currently for copying data from a production server to a archive server and will shortly be using it to copy production data to our UAT environment so that users can test enhancements/fixes with production data. Regards, Saby ________________________________ From: Shyam Attavar <[email protected]> To: [email protected] Sent: Thu, March 4, 2010 4:59:45 PM Subject: Refreshing the DB for ITSM 7.1.0 ** Dear Listers, I have a need to refresh the production database back onto a test environment we are building. Since there have been quite a few customizations, we would like to get to a point where we can start leveraging the Test environment without having to individually migrate the customizations over. If refreshing the DB from production environment is considered risky due to the various notifications, escalations and approvals that might be pending, we can even refresh from our development server. Here's the environment: ITSM 7.1.0 (except SRM) ARS 7.1.0 Patch 6 running in a server group with four nodes on RHEL Oracle 10gR3 RAC running on RHEL Has anyone attempted something like this and has been comfortable with the refresh process. I have done this in the past on ITSM 6.x running on Oracle. I do realize exporting the ARADMIN schema from one instance and importing into another instance would get me started. However, I am more concerned with the data driven nature of ITSM 7.1.0 and there is more to the refresh process than meets the eye. I have never attempted this on ITSM 7.1.0 - hence my concern and posting to the list. Any words of advice, things "to do", things "not to do", things to "watch out for", or not do this at all. Any feedback is welcome. Thanks in advance, -- Shyam _Platinum Sponsor: [email protected] ARSlist: "Where the Answers Are"_ _Platinum Sponsor: [email protected] ARSlist: "Where the Answers Are"_ _Platinum Sponsor: [email protected] ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"
