We currently have our SCCM 2012 R2 SP1 site database hosted on the same server as everything else related to SCCM. We are running SQL 2012 on this server. We want to move the database to another server running fresh just installed SQL 2014.

Anyone did that before?

Do i have to upgrade first SQL 2012 on sccm server to SQL 2014 and then move database to new server?

Is it recommended to keep database on another server or will it just slow down sccm?

Any other problems I might get?

How many clients are we talking about? I'd keep SQL local if possible.

Hey,

moving your database to another server should not become an issue. I did it already several time for customers. You do not need to update the current SQL server.

There is a well written blog about.

http://blogs.technet.com/b/configurationmgr/archive/2013/04/02/how-to-move-the-configmgr-2012-site-database-to-a-new-sql-server.aspx

I hope that helps.

Best Regards,

Udo

Although technically valid to do so (per the blog link posted by aladin), I concur with Torsten (as does just about everyone else). Keeping the SQL DB local has many advantages and is just plain "simpler" which is almost always a better path to choose.

Jason or Torsen would you be able to provide info about this. For some reason i always tough that having SQL running on is own box would be a lot better and easier to manage resources. Since i always end up putting the WSUS DB on the same server.

SO you are saying that just making sure i have dedicated disk from a dedicated data store for example for the SQL DB i should be fine managing 50k client with Primary site having the DB role on it and making sure i have my MP/DP/SUp on a second server ?

Steve did that for us :-)

https://stevethompsonmvp.wordpress.com/2014/12/20/why-you-should-not-use-remote-sql-server-with-configmgr-2012/

As additional info, one of the largest ConfigMgr sites in the world, about 350,000 managed clients, uses all on-box SQL even for their CAS. Yes, this is technically unsupported and I'm not saying to necessarily do unsupported things, just that it works well for them because it simplifies their configuration and eliminates any connectivity issues to the DB from the primary site server.