I recently stumbled upon this weird white paper from MD Consulting: http://www.md-consulting.de/PortalData/2/Resources/download_techn_infos/Migration_bestehender_TD-Anwendungen_nach_C_.pdf
It's in german, but the translation is quite clear to understand.
MD talks about the differences between porting and migration. The term porting refers to our technology, The Porting Project. Whereas migration refers to the technology now owned by Unify, a product called Sabertooth. (Unify bought this "migration" technology a few years ago from Active Data for US$ 420k). While both approaches seem pretty similar on first sight, there are differences in terms of concept, functionality, and completeness between the two offerings. We are certainly in agreement on this with MD Consulting.
The whitepaper explains the different implementations of the converted .NET code for SalTblPopulate(), claiming that the Porting Project is actually trying to emulate SAL, while Sabertooth is offering pure and clean C# code that doesn't emulate SAL. This is the code that the two migration technologies produce:
Sabertooth: tbl1.Populate(hSql, "SELECT...", SalGrid.TBL_FillAll);
Porting Project: tbl1.Populate(hSql, "SELECT...", Sys.TBL_FillAll);
Do you see a difference? To me it looks pretty much the same (despite the namespace used for the system constant TBL_FillAll). This is something we did not understand in the whitepaper.
So while we are in agreement on how to best solve migration or porting of SalTblPopulate(), there are some differences in how to implement other items. Let's look at another example:
Data fields in SQLWindows can hold different data types. This is important functionality in terms of data entry and validation. The data type of a data field can be changed by just flipping a property. It is not easy to port this to .NET, because the equivalents to data fields in SQLWindows (named text boxes in .NET), are not aware of data types. All data entry and validation logic has to be done by hand or with custom classes.
Unify's approach to port a data field class of type date/time is to map this to a SalTextBoxDate class that holds all the entry and validation logic. On first sight, not a bad move. But the truth is that this is prone to errors and would have broken many applications that we ported throughout the last years.
Imagine a data field is used as a base class for other data fields. They are derived a couple of times and finally used on a form or in a dialog box. What happens if the data type property is changed somewhere in the inheritance tree? Assume the base class is of type string while the derived class is of type date. If this is done in several places, the conversion process will actually break existing applications (and it would have happened to most applications we ported).
Where is the point in porting or migrating at all? Preserve the existing investments and reduce the risks in going to a new platform and starting from scratch. In a complete rewrite, the development effort is not the most critical effort, it is rather testing and making sure that the application works just like before. That's the reason why many banking, insurance, and flight booking systems are still developed and maintained in COBOL code that has been written 20, 30, 40 years back.
With more than 1000 ported applications, we have found best practices to minimize the risks as much as possible. And we have numerous development teams that consist of both, SQLWindows developers now working in C#, as well as true C# developers that have never used SQLWindows before. They work happily together on ported code and appreciate the fact that they can finally evolve ported applications without throwing away tremendous investments in existing products.
We are confident that we have made the right decisions in our porting library based on the experience of our 100% success rate together with the large list of references that we have made public. Compare the details!