The idea of moving logic into stored procedure makes me squeamish. I've only had direct experience with a significant number of stored procedures once, but lots of indirect exposure through friends.

There were two common themes.

The first is that it always seemed to split development into two camps, the non-database developers and the database developers. And too often, friction between the camps built up and hindered progress.

The second one, lack of ability to unit test business logic that had migrated into stored procedures, may have been resolved by now. But when I was dealing with it, the difficulty of writing unit tests for stored procedures really sucked, and slowed down development. You could test functionally, by throwing data at the stored procedure and then probing the database to make sure the right things had happened, but such tests seem to require a lot of maintenance, and tend to miss problems of the type that a mock object would spot right away.

I would need to see a pretty compelling performance argument before I would consider putting any significant business logic in stored procedures. But that's me. YMMV.