**

Hi Grant,

Your plan seem ok to me except for the fact that you are importing w/f objects before data. If you import data and then workflow you will not have some filters firing during import process.

My 2 cents worth.

Cheers,

Nagendra
Macquarie Bank

-----Original Message-----
From: Schoep, Grant @ STORM [mailto:GSchoep@STORM.L-3COM.COM]
Sent: Wednesday, 24 April 2002 9:17 AM
To: ARSLIST@LISTSERV.VISTAIT.COM
Subject: Re: ARS Server upgrade 4.0 -> 5.01 plan, comments appreciated


**

Sounds like this may be quicker than doing the method I wanted to, as I have
about 15-20 forms that I need to dump data from, then import back. As well
as the fact the server would be remote from me, I would be doing that over a
WAN, where as this method is much quicker becaused I just be sitting at the
UNIX prompts most the whole time.

Question though, doesn't ARS store the server name in there somewhere? So if
I dumped the ARS database, reloaded it on a new machine(with different
name), doesn't that screw things up? Like, when I need to do a export of the
work flow, and have it be "server-independant".

-grant


-----Original Message-----
From: Patrick Simon [mailto:arslist@simon-p.demon.nl]
Sent: Tuesday, April 23, 2002 3:46 AM
To: 'Schoep, Grant @ STORM'
Cc: 'Action Request System discussion list(ARSList)'
Subject: RE: ARS Server upgrade 4.0 -> 5.01 plan, comments appreciated


Hi Grant,

I recommend you performing the upgrade step-by-step.
Benefit 1: If something goes wrong during upgrade you have only one change
to investigate
Benefit 2: reduction of work (no export and import of workflow and data)

Let me explain by giving you the way I should upgrade:
1. Configure new OS on new platform
2. Install current version DBMS on new platform
3. Install current version ARS on new platform (including licences, mail
etc). If you're running e.g. Remedy Help Desk, install that one to to
ensure the installation of the Remedy Application Service.
4. Create backup of database of old platform. Restore backup on new
platform.
5. Copy eventually all custom scripts to the new server
Now you can test if your old application is working on the new platform.
Put it in production for a few days to see all is fine.

6. Upgrade DBMS
Test the application and put it in production for a few days

7. Upgrade ARS
Test .... than in production

This procedure might look time consuming, but I succesfully upgraded
several environments already following the above procedure. In the case the
application is critical, you must be sure to follow the route with minimal
risk of incidents. If you have the resources test this procedure first in a
test-environment.

I hope this helps.

Sincerely,

Patrick Simon, Turnkiek IT Services
tel: +31 (0)33 454 33 55
fax: +31 (0)33 454 33 45
mail: patrick.simon@turnkiek.nl
web: www.turnkiek.nl

-----Original Message-----
From: Schoep, Grant @ STORM [SMTP:GSchoep@STORM.L-3COM.COM]
Sent: Monday, April 22, 2002 7:37 PM
To: ARSLIST@LISTSERV.VISTAIT.COM
Subject: ARS Server upgrade 4.0 -> 5.01 plan, comments appreciated

**

All,

I'm planning on doing the upgrade from our main server to ARS 5.01 (from
4.03). In the course of this, we are also upgrading the OS, machine, and
Sybase. So I figure it will be easiest to do like I did a few years ago,
and just replace the entire machine, dump all the forms, and upload all the
forms to the new machine.

Here my plan:
1> Install new OS/Sybase/ARS on new machine.
2> Dump workflow from current ARS server.
3> Load workflow to new ARS server.
4> Take current ARS server offline.
5> Dump all the data out via each for as reports( is there any quirks to
this? )
6> Import all data that was dumped out.

Does this sound like an ok plan? This is how I had to do our 3.2 -> 4.0
upgrade a few years ago. The only problem I remeber was a bunch of filters
were firing on the import, can't remeber what I had to do to get around
this, maybe turn off all the filters for that time. Anyone have any
comments?

Thanks
-grant



To UNSUBSCRIBE, email the message "unsubscribe arslist" to:
listserv@listserv.vistait.com
You may also control your subscription options, including UNSUBSCRIBE, at
www.ARSLIST.org

**

Hi, Grant,

You need to run some sql against your db after step 4 of Patrick's plan,
while ARS is down.

Update servercache set server = 'newserver'

and

update fieldtable set tfserver='newserver' where tfserver='oldserver'


At least this is what I ran doing a 4.0.3 copy-over with Sybase.

Jim.

-----Original Message-----
From: Schoep, Grant @ STORM [mailto:GSchoep@STORM.L-3COM.COM]
Sent: Tuesday, April 23, 2002 4:17 PM
To: ARSLIST@LISTSERV.VISTAIT.COM
Subject: Re: ARS Server upgrade 4.0 -> 5.01 plan, comments appreciated


**

Sounds like this may be quicker than doing the method I wanted to, as I have
about 15-20 forms that I need to dump data from, then import back. As well
as the fact the server would be remote from me, I would be doing that over a
WAN, where as this method is much quicker becaused I just be sitting at the
UNIX prompts most the whole time.

Question though, doesn't ARS store the server name in there somewhere? So if
I dumped the ARS database, reloaded it on a new machine(with different
name), doesn't that screw things up? Like, when I need to do a export of the
work flow, and have it be "server-independant".

-grant


-----Original Message-----
From: Patrick Simon [mailto:arslist@simon-p.demon.nl]
Sent: Tuesday, April 23, 2002 3:46 AM
To: 'Schoep, Grant @ STORM'
Cc: 'Action Request System discussion list(ARSList)'
Subject: RE: ARS Server upgrade 4.0 -> 5.01 plan, comments appreciated


Hi Grant,

I recommend you performing the upgrade step-by-step.
Benefit 1: If something goes wrong during upgrade you have only one change
to investigate
Benefit 2: reduction of work (no export and import of workflow and data)

Let me explain by giving you the way I should upgrade:
1. Configure new OS on new platform
2. Install current version DBMS on new platform
3. Install current version ARS on new platform (including licences, mail
etc). If you're running e.g. Remedy Help Desk, install that one to to
ensure the installation of the Remedy Application Service.
4. Create backup of database of old platform. Restore backup on new
platform.
5. Copy eventually all custom scripts to the new server
Now you can test if your old application is working on the new platform.
Put it in production for a few days to see all is fine.

6. Upgrade DBMS
Test the application and put it in production for a few days

7. Upgrade ARS
Test .... than in production

This procedure might look time consuming, but I succesfully upgraded
several environments already following the above procedure. In the case the
application is critical, you must be sure to follow the route with minimal
risk of incidents. If you have the resources test this procedure first in a
test-environment.

I hope this helps.

Sincerely,

Patrick Simon, Turnkiek IT Services
tel: +31 (0)33 454 33 55
fax: +31 (0)33 454 33 45
mail: patrick.simon@turnkiek.nl
web: www.turnkiek.nl

-----Original Message-----
From: Schoep, Grant @ STORM [SMTP:GSchoep@STORM.L-3COM.COM]
Sent: Monday, April 22, 2002 7:37 PM
To: ARSLIST@LISTSERV.VISTAIT.COM
Subject: ARS Server upgrade 4.0 -> 5.01 plan, comments appreciated

**

All,

I'm planning on doing the upgrade from our main server to ARS 5.01 (from
4.03). In the course of this, we are also upgrading the OS, machine, and
Sybase. So I figure it will be easiest to do like I did a few years ago,
and just replace the entire machine, dump all the forms, and upload all the
forms to the new machine.

Here my plan:
1> Install new OS/Sybase/ARS on new machine.
2> Dump workflow from current ARS server.
3> Load workflow to new ARS server.
4> Take current ARS server offline.
5> Dump all the data out via each for as reports( is there any quirks to
this? )
6> Import all data that was dumped out.

Does this sound like an ok plan? This is how I had to do our 3.2 -> 4.0
upgrade a few years ago. The only problem I remeber was a bunch of filters
were firing on the import, can't remeber what I had to do to get around
this, maybe turn off all the filters for that time. Anyone have any
comments?

Thanks
-grant



To UNSUBSCRIBE, email the message "unsubscribe arslist" to:
listserv@listserv.vistait.com
You may also control your subscription options, including UNSUBSCRIBE, at
www.ARSLIST.org



To UNSUBSCRIBE, email the message "unsubscribe arslist" to:
listserv@listserv.vistait.com
You may also control your subscription options, including UNSUBSCRIBE, at
www.ARSLIST.org