NETApp is very good for what it was designed to do, which is, taking very fast snapshot backups of entire drives. This is an awesome tool from a storage tech's point of view. Not so much for DBA's. Where we are in our adoption of this tool is that we have no choice but to convert from backups on local drives or SAN drives (Tivoli) to using this volume backup methodology.
NetApp recommends that system database files remain local to the SQL Server physical server, while all other database files are split out on LUNS that are on the NetApp appliance. So my mdf files reside on one LUN, and my ldf's on another, with additional LUNS available for tempdb, and finally backups. And SM only likes 35 dbs on a LUN. So if I have 75 DBs on my server, I should have at least 8 luns with database files going to several locations. Think of the documentation to maintain and having to find the needed files during an emergency.
Moving to the new LUNS requires coordination between the storage folks, the server folks, the DBA team, and the user-base to move the files to their new homes. That is a lot of work.
One of the most highly touted benefits of SM is Fast backup and restore. You should know that this is only true if you plan on restoring ALL of your databases that are assigned to the LUNs that contain the data. Otherwise, your restore time and complexity INCREASE because the entire contents of the backed-up drive must be mounted, and then searched for the relevant database bits to restore. Problems we have encountered include
1) not having enough space to mount the drive allocated;
2) increased recovery time for a single database when many are assigned to a set of LUNs;
3) occasional SnapManager hiccups that make backups stop working;
4) The software backups manage the Log Sequence Numbers (LSNs) so if you take a native backup, you will have to recreate the backups using the SM tool, which is ok but not great. It will create a job to perform the backups, but we were kind of wanting a way to script this for standardization, and that still eludes us.
5) requirement for multiple backup strategies because system db backups are not part of what SM does. So now you have to have a backup plan for system db's, and one for user db's, if you didn't split those out before.
6) Determining the mix of databases to place on the same LUNs can be very problematic to triage. Business critical dbs should be on their own LUNS, and so should highly transactional dbs, but do you want to become a SAN specialist ? You will if you have to carve out LUNS for each special db on a server with 100 dbs.
Hope this helps.