SQL 2008 R2 In-Place Upgrade or Fresh Install to SQL2104

Question

We have a server running Windows 2008 R2 and SQL 2008 R2 currently.  We will call it SQL01.  This houses databases for about 8 different applications and also has the name hard coded into a lot,  I repeat, a lot of various things.
We are at the point where one of our applications needs to be upgraded and it only works with SQL 2014.  So we need to either do an in-place upgrade or fresh install.
The obvious choice to me as a system admin is to do a fresh install, but the development side of the department knows how many places the name "SQL01" is hard coded and they want to do an in-place upgrade to avoid all the issues that would show
up if we changed names.
I have several questions, and I'd appreciate that the answers address them all if possible.
1.  What are people's experiences with in-place upgrades from SQL 2008 R2 to SQL 2014?
2.  To avoid this naming and coding issue, do companies use a permanent alias for their SQL servers?  Like with exchange, we have an alias or A record pointing "mail" to the current Exchange server.  As we do upgrades and the Exchange
server names change, the "mail" entry will always be pointed to the current one.  Do people do this for SQL as well to avoid our issue of hard coding names?
3.  I've head that you can also have both SQL 2008 R2 and SQL 2014 on the same server running together.  This really doesn't help though if the SQL 2014 instance would need to be something other than the default which everything is currently pointed
to correct?
4.  Is there any advice about a better way to go about this?  Or a better way to do this moving forward?  Other than not hard coding which I can't change now?
Thanks!

Answer 1

Hello,
Adding to the answers provided above, please consider discontinued features no longer available on SQL Server 2014.
I often see company configuring SQL Server aliases when installing SQL Server on SharePoint environments. You can certainly use DNS or use the following article.
http://msdn.microsoft.com/en-us/library/ms190445.aspx
An in-place upgrade is easier but is difficult to rollback in case something goes wrong. Meanwhile, a side-by-side upgrade provides you more control over what is upgraded, it keeps the legacy server online during the upgrade allowing you to easy rollback if
needed, but is not an automated process and the instance will not keep the same name, requiring you to use aliases or other ways to avoid client redirection.
Since you cannot change the application, go for a side-by-side upgrade and try the DNS alias or the client-side alias as I provided the procedure above.
Hope this helps.
Regards,
Alberto Morillo
SQLCoffee.com