The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
|
|
SLX 6.2.4 to 7.2.2
Posted: 23 Apr 08 11:40 AM
|
We are gearing up for this upgrade so the information in the thread is very useful
Slightly different angle - any good experience to pass on in terms of preparing remote and network users for the change? We have a user base of 160.
Thanks  |
|
|
|
Re: SLX 6.2.4 to 7.2.2
Posted: 24 Apr 08 7:20 AM
|
A - FULL (Windows) Administrator rights enabled for all users..
B - Think about a complete uninstall/reinstall for plan "B" if "upgrading" fails.
C - TEST .. test.. test.. test..... did I say test?
D - Think about replacing the remote db engine w/SQLExpress (now the SalesLogix standard).. and If you do.. then a complete uninstall on teh remote is probably necessary...
E - A totally hands off upgrade will probably not work.. plan for spending a lot of time fixing random issues..
... I can think of more... but you get the idea..
We upgraded one of our largest (and world known if I told you who) clients just a little while ago.. over 200 remotes.. NO lan clients..
Oh yes.. We were called in to perform an upgrade almost 100% identical to what you are dooing for another BP.... We were able to do a "in-place" upgrade and NOT recut any remotes... We planned for the worst scenario.. we got lucky...
--
RJLedger - rjlSystems |
|
|
|
Re: SLX 6.2.4 to 7.2.2
Posted: 24 Apr 08 9:46 AM
|
If you have the resources (i.e. a fairly decent server that has some space, processing power, extra memory), I reccomend setting up a Virtual Machine.
I found that my last upgrade went fairly well by using a VM and setting up my existing SLX in VM and then preforming the upgrade there. I was able to prepare myself for a majority of the issues although i had a smaller install base, things like finding out if certain customizations stopped working etc were easy to detect and correct there prior.
You can download the VM software free at www.vmware.com (VM ESX Server 3) I believe is the latest free one, although their might be a newer one coming out.
Definately have a plan B if the upgrade goes south. Hopefully you won't have to recut remotes but if things go south, plan to budget in time to coordinate that. |
|
|
|
Re: SLX 6.2.4 to 7.2.2
Posted: 25 Apr 08 12:09 PM
|
In order to take advantage of tehe(new feature) of not having to cut remotes.. you MUST upgrade the production db in place.
Going to a VM.. upgrading.. putting it back.. then you WILL have to recut every remote.
--
RJLedger - rjlSystems |
|
|
|
Re: SLX 6.2.4 to 7.2.2
Posted: 25 Apr 08 12:14 PM
|
Thanks Bob for the point of clarification, I see how I omitted a very important peice of information. In my work with VM I setup a testbed system but I redid the same work that I did on test in production, call it an insurance policy that i know what customizations would cause me an issue in production. Despite having done that extra step, I still followed standard guidelines and made a backup of the SalesLogix DB and upgraded my SLX system after doing that VM testbed.
I agree that its definately a problem since post-upgrade you need to do several things to the SLX Sync server to prep it to push the upgrade packages for the remotes. Without completing those steps provided in the documentation, the Sync server won't issue the upgrade package.
|
|
|
|
Re: SLX 6.2.4 to 7.2.2
Posted: 25 Apr 08 12:46 PM
|
Mike,
You are correct... One should ALWAYS run a test system.. and do a test upgrade (on our servers) .. validate it.. and then do exactly the same thing against production.
We NEVER do an upgrade unless it's been fully tested (in a test env) and signed off by the client as 100% ok. After that happens, then we schedule the actual production upgrade.
If it's a "pre 62".. we always uppgrad on our servers .. not the client's systems.. and then restore.. If it's 6.2x and up.. production upgrade is on the clients's gear. |
|
|
|
Re: SLX 6.2.4 to 7.2.2
Posted: 25 Apr 08 12:52 PM
|
| at the time, I was working for a SLX Customer, so money was tight and I wanted to keep them up-to-date so I setup the VM to figure out "upgrade costs" since the company didn't want to pay for our BP to do it, since their would be an analysis cost + cost of upgrade ($$$). By setting up the VM, I eliminated the analysis cost and 90% of the upgrade cost from a BP. The BP was fairly priced with an experienced staff however the company I worked for didn't believe in doing an analysis of an analysis to upgrade. They probably wouldn't of done the upgrade unless I gave them a significant savings. Now that I'm working for a BP, I've seen the other side and I don't know what our company would do without those environments. |
|
|
|