Agree on the comment about the driver issue. The SQL Server native client (SNAC) driver doesn't ever need the port as long as it's the default port. But the choice of driver you use to make your connection is always based on the application context; and there are a lot of arguments in favor of using the ADO.Net type of connections rather than ODBC. If you do that, you'll find that ADO drivers also do not need the port specified.

In this case, if you really need Kerberos, you may be stuck having to deploy application changes after the migration. Or another option might be the use of a "failover partner" parameter in your app connection string--assuming you're using ADO and can thus take advantage of it. Details are here http://msdn.microsoft.com/en-us/library/ms366348%28v=sql.105%29.aspx . Although I will caution you, I haven't tried this approach in situation where there wasn't actually mirroring involved, and this connection string example is for the situation where you have mirroring. You may want to try it and see if it works in your situation too. If it does, then you'd still probably want to deploy yet another connection string after migration is completely done, because you'll be losing the original primary server.