I agree with everyone else, go with option 2. Might be a good time to research the possibility of updating all of your client ODBC connections to reference the DB by cname rather than server name.
- Sean On Mon, Aug 12, 2013 at 12:10 PM, Christopher Bodnar < [email protected]> wrote: > Agree with others that #2 is the best option. Not sure how many or how > complicated your maintenance plans are, but if it's worth your effort, this > might help in the migration: > > > http://www.symantec.com/connect/articles/progress-creating-and-managing-sql-server-database-maintenance-plan > > > *Christopher Bodnar* > Enterprise Architect I, Corporate Office of Technology:Enterprise > Architecture and Engineering Services Tel 610-807-6459 > 3900 Burgess Place, Bethlehem, PA 18017 > [email protected] > > > * > The Guardian Life Insurance Company of America* > * > **www.guardianlife.com* <http://www.guardianlife.com/> > > > > > > > From: Jesse Rink <[email protected]> > To: "[email protected]" <[email protected]> > Date: 08/12/2013 03:37 PM > Subject: [NTSysADM] sql server upgrade > Sent by: [email protected] > ------------------------------ > > > > > We have an older Windows 2003 R2 x64 VM server which contains SQL2005 x64 > on it. I'm planning on getting this box more current... > > My first option is to: > > 1. Take a image backup of the VM with our PHD Virtual software > 2. Increase the c: drive hard disk in vSphere and then use a partition > tool to expand the c: partition (its too small to perform the 2008 R2 > upgrade on it) > 3. Upgrade 2003 R2 x64 to Windows 2008 R2. > 4. Upgrade SQL 2005 to SQL 2008 R2. > > Anyone had bad experiences going this route? > > The second option is to: > > 1. Create a brand new 2008 R2 server with SQL 2008 R2. > 2. Detach the 10 DBs from SQL-OLD, copy them over to the SQL-NEW server > and re-attach. > 3. Decomission the old SQL-OLD server > 4. Rename SQL-NEW to SQL-OLD and assign it the same IP address that the > original SQL-OLD had. > 5. Setup my Maintenance Plans from scratch. > > I think I'll be good for all my client applications that have specific > ODBC settings configured pointing to either the IP address of the SQL box > or the computer name/FQDN. > > Anyone had bad experiences going this route? > > Leaning more towards option TWO at this time... I tend to like clean > installs as opposed to upgrades (generally). > > JR > > > > ----------------------------------------- This message, and any > attachments to it, may contain information that is privileged, > confidential, and exempt from disclosure under applicable law. If the > reader of this message is not the intended recipient, you are notified that > any use, dissemination, distribution, copying, or communication of this > message is strictly prohibited. If you have received this message in error, > please notify the sender immediately by return e-mail and delete the > message and any attachments. Thank you.
<<image/jpeg>>

