Here's our scenario.

We successfully migrated our SharePoint 2010 Foundation databases to another server using this method and this article. The key point is that we set up an alias from our existing SQL Server (let's call it "SQL1" for this post) to the new SQL Server (let's call it "SQL2") for this post, per the best practice in the article.

The problem is, we have some custom databases on "SQL1" that are used by web parts (don't ask why: legacy code). Those web parts look in the web.config for the original SQL Server name "SQL1", which now has an alias on it.

Since we only migrated the SP environment databases, these custom DBs weren't moved, so now we get errors saying that the custom databases could not be found, because the alias points to "SQL2", where the custom DBs don't exist. How can we get around this without moving the custom DBs? Is it possible to add multiple aliases on "SQL1" to point back to itself (sounds crazy, I know)?

  • Can't you just change the connection string in web.config?
    – James Love
    Commented Nov 29, 2013 at 22:24
  • James, The web configs are not the problem. Anything in the web config pointing to SQL1 will be rerouted to SQL2 if there is an alias rule.
    – Haroun A.
    Commented Nov 29, 2013 at 22:51
  • 1
    I'm not quite following the tasks you're trying to perform, but it is possible to have multiple aliases on the same server but not two aliases on the same instance. But if you already successfully have moved SharePoint databases, can't you just remove the alias on SQL1 and let web.config rule the webpart connection?
    – Benny Skogberg
    Commented Nov 30, 2013 at 6:24
  • Hi Benny, that won't work for us because we "migrated" the SharePoint system databases (admin, content, search, user profile, etc.) to another server, which required the use of an alias. So only using a web config still wouldn't allow SharePoint to function at all without an alias (only the custom DBs could be pointed to) unless I am mistaken.
    – Alex
    Commented Dec 2, 2013 at 17:40

2 Answers 2


Keep your ALIAS as is. In your web.config change all your connection strings for your custom web-parts/apps to point to the IP address of the SQL server.

  • This is a feasible workaround.
    – Alex
    Commented Dec 2, 2013 at 19:02

If you are able to identify which web.config settings should point to SQL1 and which should point to SQL2 then you should change the respective values to point to the correct alias (yes you can have both SQL1 and SQL2 aliases side-by-side pointing to different database servers).

However, you can't route SQL traffic to a specific server from one alias. Think of them as "dumb" pointers. Also, aliases only operate at a server level, you cannot configure them per-database.

  • That sounds good, but the problem is that the custom DBs still reside on SQL1 (and need to stay there because another SP environment is pointing to it), so if an alias was to be created, it would have to point back to itself. Is that even possible?
    – Alex
    Commented Dec 2, 2013 at 17:53
  • 1
    An alias can only point to one server, so pointing back to itself would be an infinite loop (and not work). If possible, moving your app dbs to SQL2 would be ideal.
    – Russell
    Commented Dec 2, 2013 at 22:18
  • Yes, I expected as much that that is not a valid mapping. We know that moving the DBs to SQL2 would do the trick, but it's not feasible to do that in our situation because other environments depend on those DBs being in SQL1. Quite an architecture/integration problem we have on our hands!
    – Alex
    Commented Dec 3, 2013 at 19:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.