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