I never actually did this, but did mull over how you might approach the problem at one stage - nothing too detailed, but it might spark some ideas...
Non-GUI stuff (functions, logic etc) would definitely have to be manually converted. If you were trying to convert thousands of scripts it would probably be worthwhile trying to write some kind of scripts to munge your most common chunks of code. (I realise this is something of a self-defeating argument as your most common chunks of code would - hopefully - exist as functions and not be replicated in multiple areas ).
Object recognition files (.inc in Silk, .gui in WinRunner) could also probably be munged by script to some basic working state, as they exist in known, standard formats.
The neatest suggestion I heard was to do with converting the actual GUI interaction stuff existing in scripts and was a great piece of lateral thinking... Assuming you have your .gui/.inc file created, put your 'new' tool (WR) in 'record' mode and your 'old' tool (Silk) in 'play' mode and sit back...
Sounds to me like it might work, but assumes your have all your object recognition and non-GUI stuff working 100%. I don't know if this is realistic, given a lot of this code will depend on GUI interaction to start!
Hope this is of some help...
[This message has been edited by Automatrix (edited 04-04-2001).]
Automatrix's suggestion of recording on WR while playing back on SilkTest is probably the only viable solution. The ROI on writing a macro to convert existing files would be close to nonexistent. The difficulty lies in the fact there is not really a one-to-one relationship between the respective programming languages, one being more OO based than the other.
Our company recently merged with another and we are now "converting" their SilkTest code into WinRunner.
There is no automatic mechanism. The idea of playing back one and recording the other is cute, but I don't think much useful code will come of it. I took the Silk functions written and wrote WR functions for them. I was able to import most of the data-driven methodology (some objects ARE different, however). The architecture developed in ST ported nicely to our WR framework. The actual testcases() will have to be re-written from required functionality.
Be aware of the differences in the two tools' capabilities and sharpen you coding pencils!