New SQL Server
We have a Capita UNIT-e database server (Further education MIS system), currently on Windows 2003 with SQL 2005.
Now I've built a new Windows 2008 R2 server with SQL 2012 - Both supported by Capita so no problems there.
However, our in house developers link in to the SQL server with their custom reports and the like.
If the new server has the same name as the old one (Obviously not at the same time!!), the same database instances, the same SA user password, would any links just work as if nothing had changed?
Also, is there any benefit in then upgrading the MIS database to SQL 2012 schema? (Maybe I need to ask Capita on that one...)
I don't know about Capita, so this is in general terms only: it's *probably* OK to do so, as the connections will probably just care about the server name, instance name and user.
The sa password shouldn't matter, unless you're using the sa account for the applications/links - but that is very bad form indeed (on a par with logging in as the domain admin to read your email).
The other thing to watch out for with SQL Server is that Microsoft deprecate features between releases - a project I work on had to be updated for SQL 2008 after some 2000-only features disappeared, for example. You're usually OK if the devs are doing basic SQL, but it's wise to check . . . .
Depending on how they've implemented things, especially considering some workarounds for working with SIMS, you might have IPs thrown into .ini files rather than server names, so it could cause a problem if the ip is not the same. Otherwise, so long as dns is up to date i'd say it's okay.
Be careful of stricter security settings on win 2008 though, because, the SQL ports won't be open. I'm pretty sure the SQL installation will warn you, not sure how it works with 2012.
I think you'd have to upgrade the database to be 2012 compatible. Usually there is a migration routine. I don't think you can just drop your old db backup onto the new SQL setup.
I'd be tempted to make a test server in a sandbox VM or on a private ip range and then bring in the custom scripts for testing, as well as seeing if things work in general.