I'm a little shocked that this is being reported as such, and that the response to customer was what is stated in this article. This is very much a great improvement and not a heavier load on the developer. This is a Fnctional design point, and should be viewed as such.

I'm surprised how this is being portrayed in this article. Yes, the upgrade path for security is not great, but from where I am standing as a technical implementation consultant, my clients would be happy to throw out their existing setup for something more structured and robust. Yes, it will take a bit of figuring out how to fit into the existing roles. But even if you need to create new roles, you can pick and choose high-level duties from a list and not fiddle with a mess of security keys and implied inheritance structures. For upgraded custom code you will need to add security. If your custom code is that heavy that you have a ton of work on security, you will have a tough time upgrading the code itself to 2012 already, and should probably re-evaluate the whole modification anyway, security being a minor detail. As for new customizations, any good design specifies the restrictions of the modification. There is now a NEED rather than a best practice to specify the security implications of a modification. This is part of a good design, and is an extra step for the analyst writing an FDD. The impact on a developer is minor. If the developer is having to come up with the security model for his modifications, you're on the wrong path.