Know What's Cooking - Stay up to date.
21

.NET or Team Developer, that is the question. Of course there are other options: a) rewrite it in Java; b) Packaged Solution; c) drop the application; d) assembler. However, for this article I'd like to focus on one simple dilemma:

Option 1: Change the platform to Microsoft .NET

Option 2: Do not change the platform and stay with Team Developer for a long time (in IT years).

Now that Oracle (the other "evil empire") bought Java, in my opinion Java is simply a different kind of .NET not fully compatible with Windows.

Let's analyze the pros and cons of each option. For simplicity, we categorize the different issues into 4 simple groups: A) Cost; B) Features; C) Time; D) Risk. We also assume that Option 2 (staying with Team Developer technology) implies migrating to one of the latest versions (5.1, 5.2, 5.5, or 6.0) since Unify (the company that now owns Gupta) has dropped engineering support for versions prior to 5.1.

A) Cost

The Cost component includes several parts: migration to .NET or Team Developer 5.x, cost of finding and retaining developers, cost of developing new functionality, cost of fixing bugs, cost of supporting new Windows platforms, etc.

Once you factor in all the cost components I believe that the cost of moving to Visual Studio and .NET is actually lower than the cost of migrating to TD 5.x.

Consider that Visual Studio is the most widely used development platform and toolset in the world, .NET provides tons of solid libraries and components, integration with testing tools and code management systems is seamless, you can see why the migrating to the "same old" carries a high cost potential.

B) Features

Features is a word that can include many different things. In our case I will stick to simple items, such as: elegant OO language (C#), tons and tons of solid code and libraries, full support for many standard technologies (XML, WFC, SOAP, Web Services, SOA, MSMQ, Windows Visual Styles, Common Controls, ADO.NET, Visual Studio endless list of tools and integrations, ...).

C) Time

Moving to .NET using a proven and standard methodology and support library takes much less time than you may think. Depending on the size and complexity of the application we can have a running system in few weeks and a fully modernized and QA'd application in a few months.

If we include other time factors, such as time spent debugging problems related to Unicode, database connectivity, Windows compatibility (64bit, Vista, 7, Azure), the migration to .NET may actually end up being faster than the migration to the same platform.

D) Risk

We have moved so many complex (and huge) applications from Team Developer to .NET that I'm absolutely certain that there is nothing out there written in Gupta that we cannot convert to .NET within time and budget and at virtually no risk.

Why?

My final reflexion is... if I have to go through the trouble of migrating my system, debugging it, fixing new errors introduced by the new target platform, coding workarounds, debugging it, dealing with the vendor and technical support, dealing with unhappy users (users are always unhappy), why on earth would I want to migrate to the same limited platform I'm coming from?

If I have to pay the price for a migration project the logical choice for me is to go to a modern environment where I can get all the benefits that I don't have now.

Actions: E-mail | Permalink |