Many of us are planning to move to SQL Server 2012 in the coming year, and one of the feature you might plan to use is AlwaysOn availability group. There are things that you might need to consider before actual implementation, and let talk about each of them in details.

Logins - I hope you already aware that logins are not automatically transfer over to the secondary nodes, unlike SQL cluster. It's not a big deal as we all know how to transfer logins from server to server in the old days of using log shipping (yes log shipping require manual logins transfer as well), but need to look out on this and make sure you have something to cover it.

Port - Unless you are using default instance with default port for your listener (which you cannot have more then 1 listener on the same port anyway), you will need to use a non default port. In the old days, using non default port is not a big issue but there are two options you need to cater:
  1. Application connection will need to specify the given port
  2. Enable SQL browser service
Bad news is that SQL browser will not have you with listener port, meaning you only left with option one, this might or might not have effect on your application if you are allow to modify their connection string, but for some application, especially for upgrades or migration, you might run into issues. The only option you have is using the default port, which limit yourself to have only one listener.

Readable replicas - This might be the most wanted feature for AG, to utilize the idle node to perform reads rather then just sitting there collecting dust. This is not turn on by default, where you will need to configure read only routing manually. To add to that for application to utilize it, they will need to add more option in connection string - ie. ApplicationIntent=ReadOnly, this will tell listener that this connection is readonly and will follow the pre-defined route to active secondary. Keep in mind that MultiSubnetFailover option might be needed as well if your secondaries are not in the same subnet.

Database dependency - For some application that might require database dependency, ie. DB1 needs to online before DB2, you might have problem using AG. As AG does not provide online sequence of databases, meaning database can be online in any order. If that is a must for your application, you might have to give up AG.

All of the above are not limitation (apart from the last one), but rather additional setting that might need DBA to think through, by all means this is a great feature and should look at if you can, this can help you avoid share storage and SAN level replication if you having multiple site (more thought needs to be put in for this).