Goal: upgrade applicaion ,minimize downtime and reduce any client impact.
If it's a desktop app - load it on an old - rarely used server - and test it's perfomance. This is generally quick and easy.
Deployment can be desk to desk - or set up an object package to deploy the update to machines (use a GPO or SUS to deploy).
On a server application/web application - it's a bit more complex. The process to use is called "proof of concept" - then "server swapout".
Watch server during a normal worload using perfmon or top - and get some baseline performance metrics (CPU/ memory/disk IO / network traffic .....)
It goes more or less like this:
STEP a - make and verify a good set of backups.
STEP b - mirror your server's system state - backup registry
STEP c - buy a new server- load OS and an old copy of the app
STEP d - load application upgrade on new "test" server
STEP e - verify data integrity after app upgrade
STEP f - test application functionality
STEP g - test 3d party apps/DTS/data import scripts for any needed tweaks.
STEP h - identify and needed user training issues, develop training docs,
STEP i - plan swap time (i.e. downtime)
During scheduled downtime
STEP j - back up data from live server - replicate current copy of data to the new server, then verify it's working.
STEP k - make needed network settings/DNS/AD settings to server - and swap old server for the new server with the upgraded app.
STEP l - test application functionality, and all 3d party tools for functionality.
STEP m - meet with team - share the training docs - and migration is complete.
So, if all fails, then there is little business impact .........
THE BACKOUT PLAN: put old server back in place, identify the point of failure, reimage the new server, and rerun process correctly.
there are some qualitative issue there - like application performance, so keep an ear out for user response on these issues. Also perfmon/top the server and watch server load to determine if disk io/memory/or CPU performance changes significantly.
(remember - the old server wont be archiving new data, so keep good backups)
1. insure backwards compatability.
- will the data migrate gracefully
- will the application / interface/gui need any modifications
- will any existing DTS/data import tools need tweaking
2. proof of concept
- will the app perform to the expected speed/response
- will normal functions/queries/searches get the desired response time
- will normal maintenance plans/backup time change
2007-12-02 12:09:34
·
answer #1
·
answered by drewfountain 3
·
0⤊
0⤋
INSTALLING
1) Keeping track of which employee/department purchased the software so that the software doesn't accidentally get installed on more then one PC.
2) Also, Remembering which programs were installed on a particular computer when you need to replace the computer.
It's easy to miss an application or two causing the user to complain later on when they go to use it.. they then complain "I use to have _____ installed on my computer" which brings you back to #1 where you then have to track down the software and the serial # to make sure they are telling the truth and you are not violating Copyright.
But there are many 3rd party applications which do just this or even query/audit computers to take an inventory of what's installed on them.
UPGRADING
upgrading existing applications when the user is not an administrator on their computer.
Personally, I just started looking into using Active Directory Group Policy to push out MSI files of the Update to each PC using the System or Domain Administrator account which
1) eliminates having to manually go to each PC, 2) eliminates the need for the user to be an administrator on their PC
2007-12-02 11:48:43
·
answer #2
·
answered by John S 7
·
0⤊
1⤋
Depending on the scale the major ones are downtime and retraining i guess
2007-12-02 11:41:35
·
answer #3
·
answered by the_lad_irl 2
·
0⤊
1⤋