If you have a lot of WR scripts and they work for you leave them untouched and define a 2-3 year migration path where I would advice to build a certain framework which interprets for example a keyworddriven excel script. If you ever have to switch to another tool it becomes much easier.
Encapsulate toolspecific functions with your own functions this will help you in easily switching tools
Regarding converting TSL to Visual Basic (QTP main language) I think it can be done but you have to build your own small converter and not all functionality has a mapping in QTP.
I'm a little skeptical regarding that WinQuick tool. Anyone used it, or know how much it costs? I'm sure it would work with a record / replay kind of script, but with complex functions ? HP had to endorse something - this way they don't have to develop their own tool.
[ QUOTE ]
A sensible approach (and probably cost effective?) is to do what elwin has suggested.
[/ QUOTE ]
Would you want to maintain a library where every function call is wrapped? One of the worst parts about it, when an error is thrown, it's more difficult to track down the source(since the error will be in the wrapper function).