Question: My client is currently using SQL Server for their app. At this time they are using SA account everywhere. For security reasons we need to disable the SA account. The solution I've is create another power user (not admin), like standard user and root user. The development only needs access for CRUD operations. So, what should be the rights/roles/privileges for this new account? We need to replicate the same model to the internet server where only read rights are required (from viewer's end). How do I go about it?

Two different versions, 2008 R2 and 2012.

Answer: 
On your development server, you can grant the standard users the `db_datawriter` and `db_datareader` roles. You probably want to grant the `db_owner` role to the power user. As these are database level roles, you have to repeat this for each of your databases. Regarding the web server, you should create a limited user that only has been granted the `db_datareader` role.

As the `sa` login is hardcoded to be a member of the sysadmin server, you can't limit the permission of this account. The best way to migrate is to replace all the connection string you can find and then finally disable the `sa` account.
A good practice is to create an equivalent login to 'sa' and then disable the 'sa' account.

It is also good practice to create login/user combinations that allow you to follow a practice of assigning least privilege to any logins to your system. This not only provides you with a better audit trail, for seeing who is making changes to the schema, but it also provides better security.

The 'sa' user has db\_owner privileges on all databases on your instance, to create the equivalent login do the following. Create a login with some , grant the sysadmin role to the login, map a user to all of your databases and add the db\_owner role to the user.

For your other users create login/user combinations that only have access to those database objects/operations that they need.

After you've created these login(s), you will be able to assign the needed permissions. In the environment the user is added to the db\_reader group and then explicit permissions are granted revoked on a per object basis. 

You can streamline multiple users by creating a new database role and managing the granted/revoked privileges there and simply adding the users that need those permissions to that database role.