2. Only users configured by the DBA can decrypt the data automatically. There are also a number of accounts that are sysadmins on the instance that I would need to block.
Not possible without taking the "SA" priv away from them. In the same vein, you need to fix that problem even if you don't do the migration. No one outside of the DBA group should have any higher than "DBO" and you should be ultra stingy even with that priv. NO public facing application should have any higher than Read/Write/Execute privs.
Unrealistic in most shops but certainly attainable, my personal Nirvana would be that no application would ever have more than PUBLIC privs with exec privs on the stored procedures that the app needs to execute. Of course, that also means no ORMs or embedded SQL.
is pronounced ree-bar and is a Modenism for R
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Helpful Links:
How to post code problemsHow to post performance problemsForum FAQs