1) While certainly possible to write a tool to convert VBScript into java., but the difficulty of doing so is on the same order of magnitude difficulty as writing a compiler.
2) As for object repo, you won't be able to do a 1 to 1 conversion. They use very different technology even though they they automate the same type of applications. What I mean is this.. the object hierarchy will be different between both tools. While simple controls might remain similar. Parent containers such as tables and groupings may look different by how their object proxies are designed. For example, QTP has lots of short cuts while something like a DataTable has a convenience object at the table level. RFT you may be dealing with rows, and cells. Generally object mappings are not portable between tools, even if they are both XML based.
Generally only 3 layers are portable between tools, even tools that use the same base language. Data, Configuration, and Business logic. All other lower implementation and object recognition layers will generally have to be redone from scratch.
This would be an awesome gig though. No arguments about requirements, or false data, just scripts in one tool to convert to another tool.
When I first used RFT after many years of QTP I quickly learned what was good about my QTP style and what wasn't. I am much more modular in my approach and my awareness of the limitations of QTP was enhanced. Refactoring! Is it so hard to implement HP?
You may have already done some of the following, so obviously skip steps where applicable. I also may be over-simplifying, but thats what I feel is important in process creation. Simplification of your delivery model will give the greatest visibility to risk identification and handling.
These are the steps I would follow with the process:
Stage 1: Prep your QTP scripts!
1. Ensure working set of scripts in QTP has all elements linked with a current pass in the test environment.
2. For each test script, identify the objects used in execution and change them to descriptive rather than object repository. These should then be migrated into their own fnuntion library and called as required. Re-run to ensure execution.
3. Move the scripts to a function library and call them from the main test. Ensure they execute with no OR linked.
Stage 2: Prep your ALM/QC migration
4. For each test set, create a QTP test that has the same execution flow as designed in the QC test set. Call the functionalised tests in sequence. Execute to ensure process flow is correct.
5. Migrate the execution flows into their own Function Library (with appropriate naming for easy identification of workflow). Re-run to ensure execution.
6. Data in Excel files is re-usable. You just need to either save each file as a CSV (easily scripted) or leave them as Excel and build an RFT import technique so they can be used directly from RFT (my preference)
You now have a series of functionalised tests and business process execution flows that can be methodically converted to RFT.
Stage 3: Conversion!
7. Convert the object repository function library into RFT scripted objects
8. Convert the test functions into RFT scripts with appropriate calls to the data
9. Convert the Execution flows into RFT scripts
None of these steps are easy (with the possible exception of the Excel to CSV conversion) and it will take time to do. In some ways it looks easier to dump it all and start from scratch in RFT, but don't lose faith. There is an amazing amount of business wealth in captured test scripts, automated or not, and migrating the scripts will save the business a massive overhead in lost IP, time and $$.
Also, I may have missed something in my "conversion process" but I am sure the helpful team here will point it out
While I have been working for Businesses that are Vendor partners with HP, IBM and Microsoft, my opinions and advice is my own.
The solutions provided are either sourced from my own scripting libraries or from a quick Google Search.