Hi,
We're running Solaris 9, Oracle 9.2, ARS 5.1.2, Helpdesk 5.5
on server A, and wish to upgrade to Solaris 9, Oracle 9.2, ARS 6.3, Helpdesk 6.0 on server B.
If we install Helpdesk 6.0 out-of-the-box on server B, is it possible to migrate our existing data from Helpdesk 5.5?
Has someone already done this?
I can't find a white paper on data migration. Remedy seem to recommend an in-place upgrade from 5.5 to 5.6 and then to 6.0
Many thanks,
Dafydd

Hi,

You should migrate to 5.6 first. It's an easy job...

Then you can migrate to the 6 and use the migration tool to migrate your datas. It's an easy job whith stadard application...

Here is a document that I received from Remedy Support. Depending on how many HD tickets you have, it can be a long process. I had a lot of problems with the HD upgrade. The ARS 6.3 upgrade was easy. You really need to upgrade to 5.6 first then to 6.0.

You might want to start with a fresh install on Server B

drop the Remedy User when you drop the table space.

1. Fresh install of Remedy creates a user and a new tablespace and installs everything in the correct directories.

2. Drop the table space and import the table space

3. Run the install again but this time as an upgrade. An upgrade will only modify those parameters that you enter and will not establish the default parameters.

Also go to KM-000000020632 for "new upgrade program for ITSM 5.6 applications "


Problem: (Long Description)
Remedy 4.5.x is installed with applications on a UNIX Server 'remedyprod' with a local database. There is a need to setup a test or development server, ‘remedytest’, that will be a duplicate of the Remedy server 'remedyprod'.
OS Type:
UNIX
Reference:
Remedy Server Administrator’s Guide
Migration Problems:
• embedded servername in workflow will need to be changed
• applications may require related OS files
• applications may require modifications to existing OS files (DB Clients, HP Openview clients, SMS, ...)
• workflow may reference specific paths to filenames that may need to be changed
• new server may require licensing
• large data sets are too time consuming using Remedy tools
Migration Procedures:
There are a few different options that can be used to migrate the system.
Solution 1: migration essay solution from the Server Admin Guide
1. Use Remedy Admin Tool to exports all definitions Server Independent
2. Use Remedy User Tool to export all data in all forms
a. this requires running a report on each and every form that has data (how many forms?)
b. create ARX files to be used later with Import Tool
c. see Workflow admin guide for help on running reports to create the .ARX files
3. Install Remedy server on new system
4. Login with Remedy Admin and delete all forms on new system
5. Use Remedy License to license new system
6. Use Remedy Admin Tool to import all definitions on new system
7. Use Remedy Import Tool to import all data in the .ARX files for each and every form that has data
Problems with Solution 1:
• no reference is made to using arclean
. the assumption is the admin tool can export server independent (in some cases the admin tool does not fully strip out the servername)
• no reference is made to related OS files (like a run process executable; hpdcfg, pager, arsnmfeed, ...)
• join forms may not import because they were attempted before the base forms were imported
• guides may not import because the active link has not been imported
• table fields may not import because the source form has not been imported
• there may be too much data to practically migrate in this manner
. how long will it take to export hundreds of thousands of records and import them into a new system?
. will the export or import timeout?
• the import changes the last modified by and last modified date fields
• insufficient licenses may impede import of User records

Solution 2: includes steps for add-on applications
1. Use Remedy Admin Tool to exports all definitions Server Independent
2. Use Remedy User Tool to export all data in all forms
a. this requires running a report on each and every form that has data (how many forms?)
b. create ARX files to be used later with Import Tool
c. see Workflow admin guide for help on running reports to create the .ARX files
3. Install Remedy server on new system
4. Install any application that uses related OS files/registries (Telemon Pager, Remedy Link, HelpDesk, ...)
a. Installs should use the exact same directory structures as on original system
5. Login with Remedy Admin and delete all forms on new system
6. Use Remedy License to license new system
7. Run arclean against a copy of the definition file as many times as is necessary to remove any versions of the old servername
a. The utility arclean can be obtained from the Remedy Application Gallery on the Remedy website at this URL <http://www.remedy.com/appgall/util/util128/arclean45.htm>
b. There is a readme with instructions on how to use arclean.
c. Use it for each instance of the servername (i.e. remedy1 or remedy1.remedy.com)
8. Use Remedy Admin Tool to import all definitions on new system
9. Use Remedy Import Tool to import all data in the .ARX files for each and every form that has data
10. After importing User form data arreload should be run to resync the user_cache
a. See the Server Administrator’s Guide page C-10 for instructions on arreload
11. After importing Group from data arreload should be run to resync the group_cache
12. Check forms which reference OS paths and other information which may affect workflow
a. Remedy Applications use SHR:ApplicationSettings which has fields specifying paths to executables, rappsvc configuration files, and admin login information.
problems with 2:
• join forms may not import because they were attempted before the base forms were imported
• guides may not import because the active link has not been imported
• table fields may not import because the source form has not been imported
• there may be too much data to pratically migrate in this manner
. how long will it take to export hundreds of thousands of records and import them into a new system?
. will the export or import timeout?
• the import changes the last modified by and last modified date fields
• insufficient licenses may impede import of User records
• application installs can be time consuming adding to the overall down time

Solution 3: migrator migration
1. Install Remedy server on new system
2. Use Remedy License to license new system
3. Use Remedy License to license both systems for Remedy migrator
4. Install any application that uses related OS files/registries (Telemon Pager, Remedy Link, HelpDesk, ...)
a. Installs should use the exact same directory structures as on original system
5. Use Remedy Migrator to migrate changed definitions and data from old to new system
6. Check forms which reference OS paths and other information which may affect workflow
a. Remedy Applications use SHR:ApplicationSettings which has fields specifying paths to executables, rappsvc configuration files, and admin login information.
problems with 3:
• there may be too much data to practically migrate in this manner
. how long will it take to export hundreds of thousands of records and import them into a new system?
. will the export or import timeout?
• the import changes the last modified by and last modified date fields
• insufficient licenses may impede import of User records
• application installs can be time consuming adding to the overall down time

Solution 4: database migration
1. Use Admin Tool to export all definitions Server Independent
a. this gives us a good backup (just in case)
2. Shutdown the Remedy server
3. Export the entire ARSystem database using database native export tools (see your DBA on this)
a. Performing the data transfer is left to the customer. This document assumes that the data transfer completes successfully. Make sure the backup/export includes all objects and data.
4. Install Remedy server on new system
5. Install any application that uses related OS files/registries (Telemon Pager, Remedy Link, HelpDesk, ...)
a. Installs should use the same directory structures as on original system
6. Use Remedy License to license new system
7. Shutdown both Remedy servers
8. Import the entrire ARSystem database using database native import tools (see your DBA on this)
a. Performing the data transfer is left to the customer. This document assumes that the data transfer completes successfully. Make sure the backup/export includes all objects and data.
b. note for SQL and Sybase databases ARAdmin must be the dbo, not confused with db owner
c. note for Oracle databases ARADMIN must be the db owner
d. note for Informix databases the user running arserverd must have all dba rights
e. note for DB2 databases the user running arserver.exe must be the DB owner
9. If there are table fields on any forms update the field_table table to change the old servername to new servername
a. update field_table set tfserver='newserver' where tfserver='oldserver'
10. Startup Remedy server
11. Run arclean against a copy of the definition file as many times as is necessary to remove any versions of the old servername
a. The utility arclean can be obtained from the Remedy Application Gallery on the Remedy website at this URL <http://www.remedy.com/appgall/util/util128/arclean45.htm>
b. There is a readme with instructions on how to use arclean.
c. Use it for each instance of the servername (i.e. remedy1 or remedy1.remedy.com)
12. Workflow may still be referencing the old servername
a. we already have a good definition export from step 1
b. delete all workflow (not forms)
13. Use Remedy Admin Tool with the cleaned definition file to import all of the workflow (not Forms)
14. It is not necessary but may be beneficial to run arreload to resync the user_cache
a. See the Server Administrator’s Guide page C-10 for instructions on arreload
15. It may also be beneficial to run arreload to resync the group_cache
16. If arreload is unable to work properly there is a work around documented in KB 4387. Here is a summary of that KB.
a. Login to database using native db tools (sqlplus, dbaccess, isql, …)
b. delete from user_cache
c. delete from group_cache
d. delete from server_cache;
e. Note the -e designates an entry id. The id should be unique for the User form. This will create a temporary admin user where <host name> is the name of your server.
./arcache -Ua –e999998888877777 -n TempUser -p "" -g"1;" -lw 1 -s <host name>
f. This will create a temporary admin group where <host name> is the name of your server.
./arcache –Ga –e000000000000001 –i 1 –t 2 –n Administrator –s <host name>
g. The run the following arreload commands to resync the user_cache and group_cache.
./arreload -g Group -a TempUser -p "" -f -s <host name>
./arreload -u User -a TempUser -p "" -f -s <host name>
17. Check forms which reference OS paths and other information which may affect workflow
a. Remedy Applications use SHR:ApplicationSettings which has fields specifying paths to executables, rappsvc configuration files, and admin login information.
problems with 4:
• database export and import utilities are not support by Remedy (however they are by the DB vendors)
• application installs can be time consuming adding to the overall down time

Solution 5: migrate using DB transfer and OS transfer of files
1. Use Admin tool to export all definitions Server Independent
a. This gives us a good backup (just in case)
2. Shutdown the Remedy server
3. Export the entire ARSystem database using database native export tools (see your DBA on this)
a. Performing the data transfer is left to the customer. This document assumes that the data transfer completes successfully. Make sure the backup/export includes all objects and data.
4. Backup all files related to Remedy server on the system including but not limited to:
a. See Installation and Getting Started Guide for list of files related to the server
b. Any menu files
c. Any run process executables
d. All files in the Remedy installation directory
e. Remedy configuration files
i. $ARCONFIGIR/ar or /etc/ar
ii. $ARCONFIGDIR/ar.conf or /etc/ar.conf
iii. $NTSPOOLDIR or /usr/spool/remedy
iv. $ARCONFIGDIR/nfy.conf
v. $ARCONFIGDIR/ardb.conf
f. Remedy X-default files
i. /usr/lib/X11/app-defaults/…
g. Remedy message files located in language locale directories
i. /usr/lib/local/…
ii. /usr/lib/nls/…
h. Remedy Install Directory and all sub files
i. Remedy Application Install directory and all sub files
j. Any add-on application files
k. Any add-on application config files
5. Copy all software to the new system
a. This may use tar, cpio, dump/restore
b. See your OS vendor for suggested backup/restore programs
6. Use Remedy License to license new system
7. Shutdown both Remedy servers
8. Import the entrire ARSystem database using database native import tools (see your DBA on this)
a. Performing the data transfer is left to the customer. This document assumes that the data transfer completes successfully. Make sure the backup/export includes all objects and data.
b. note for SQL and Sybase databases ARAdmin must be the dbo
i. not confused with db owner
c. note for Oracle databases ARADMIN must be the db owner
d. note for Informix databases the user running arserverd must have all dba rights
e. note for DB2 databases the user running arserver.exe must be the DB owner
9. If there are table fields on any forms update the field_table table to change the old servername to new servername
a. update field_table set tfserver='newserver' where tfserver='oldserver'
10. Startup Remedy server
11. Run arclean against a copy of the definition file as many times as is necessary to remove any versions of the old servername
a. The utility arclean can be obtained from the Remedy Application Gallery on the Remedy website at this URL <http://www.remedy.com/appgall/util/util128/arclean45.htm>
b. There is a readme with instructions on how to use arclean.
c. Use it for each instance of the servername (i.e. remedy1 or remedy1.remedy.com)
12. Workflow may still be referencing the old servername
a. we already have a good definition export from step 1
b. delete all workflow (not forms)
13. Use Remedy Admin Tool with cleaned definition file to import all workflow (not Forms)
14. It is not necessary but may be beneficial to run arreload to resync the user_cache
a. See the Server Administrator’s Guide page C-10 for instructions on arreload
15. It may also be beneficial to run arreload to resync the group_cache
16. If arreload is unable to work properly there is a work around documented in KB 4387. Here is a summary of that KB.
a. Login to database using native db tools (sqlplus, dbaccess, isql, …)
b. delete from user_cache
c. delete from group_cache
d. delete from server_cache;
e. Note the -e designates an entry id. The id should be unique for the User form. This will create a temporary admin user where <host name> is the name of your server.
f. ./arcache -Ua –e999998888877777 -n TempUser -p "" -g"1;" -lw 1 -s <host name>
g. This will create a temporary admin group where <host name> is the name of your server.
h. ./arcache –Ga –e000000000000001 –i 1 –t 2 –n Administrator –s <host name>
i. The run the following arreload commands to resync the user_cache and group_cache.
j. ./arreload -g Group -a TempUser -p "" -f -s <host name>
k. ./arreload -u User -a TempUser -p "" -f -s <host name>
17. Check forms which reference OS paths and other information which may affect workflow
a. Remedy Applications use SHR:ApplicationSettings which has fields specifying paths to executables, rappsvc configuration files, and admin login information.
problems with 5:
• database export and import utilities are not support by Remedy (however they are by the DB vendors)
• application installs can be time consuming adding to the overall down time
One of the last steps on all of these migrations is to find any data fields that store data that need to be changed as a result of the migration. A common example of this is fields that store paths for running executables. The exact forms and fields will vary depending on what application is installed. Contact your application vendors for help identifying fields with data like this that may need to be changed. Note that if the applications are installed in the same paths this is not necessary. Finally, the applications should all be tested in the new environment.
Conclusion:
You can use a database transfer to significantly decrease the amount of time to sync up a production server with a test or development server.

Thanks for the replies folks.
We don't have the Remedy Migrator Tool. How difficult/possible will it be to import HD5.5 tickets into HD6 post-installation without the tool?
Also, the Remedy doc mentions the "arclean" utility to ensure that def files are truly server-independent. Is it still necessary to run arclean on def files created in 5.1.2 for import into 6.3?
Thanks,
Dafydd

I am in process of upgrading HD 4.03 to HD 6.0

I was told i could go from 4.0 to 6.0 but no on can provide docs and i heard it is a mess to do.

There is a migration tool you can use to go from 5.5. to 5.6 an then another from 5.6 to 6.0

I don't think you can install 6.0 and then migrate from 5.5 without doing what bmc recommends.