1. If the VTL system is being sold or marketed as a software product, you should conside where the software will run and who supplies and integrates the server, software and storage as well as provides on-going support.

2. What happens when the VTL becomes full or runs out of capacity? While a VTL provides virtual tape emulation, I'm not aware of any VTLs yet (besides in archtecture slides) that provide unlimited real-world virtual capacity, although I'm aware of several products that have exceptional scaling capabilities to dynamically add storage. Likewise, there are vendors that can proactively manage and reduce the amount of storage including leveraging differencing, compaction, factoring, deduplication and singe-instance image capabilities.

3. Some VTLs provide extensive interoperability and emulation capabilities to coexist with existing software configurations and settings. Look into what emulation is provided by a VTL as well as how extensive and robust the emulation is compared to your needs and requirements. Keep in mind that some of your applications or procedures may have hard-coded references that may prove sticky and thus need to be accounted for and addressed.

4. How will you be using your VTL -- will you be using it primarily as a large disk buffer and staging pool with as much data as possible kept on disk, or will you look to actively leverage tape and move data off of disk as soon as possible?

5. What format and how accessible is the data once it is stored on a VTL? Is the data stored as a file representing a tar ball or proprietary backup save set format, or is it stored in a format that lends itself to rapid access? For example, some vendors create relative smaller container files, while others more closely map and mirror to a 1-to-1 correlation between physical and virtual tapes.