Re: Cost of migrating to .Net

That's pretty much what we stick to here. Don't rewrite unless it's
necessary and won't add very much time. We haven't yet rewritten a complete
application, however we have rewritten components of applications. The first
one is core to everything else we write. Instead of relying on a pretty poor
design of our older, relativley poorly designed components, we rewrote them
(only took 8 days) and turned our existing ones into a wrapper for the new
.NET ones. Turns out the benefit of using .NET assemblies through interop
inside our core VB dll's increased the speed of execution dramatically
(30-50% speed boost I would guess) and warrants the cost of rewriting.

We are also slowly rewriting other things when they make sense. For
instance, one application is changing so dramatically that an entire rewrite
is taking only about 5 or 6 days longer than modifying what we already had.

We're moving another component that an application uses to .NET, simply
because of some of the benefits of an OO language (compared to VB)
drastically outweighs any rewrite time.

We do, however, have a number of other components and applications that are
staying exactly as they are, simply because there's no need to rewrite them.
If we need the components from .NET, we use interop. If we ever change the
components so drastically that the changes and a rewrite wouldn't differ
very much in time, I think we would probably rewrite in C#, however I doubt
that will happen very often.

-----Original Message-----
From: Brian G. Rice [mailto:[email protected]]
Sent: Friday, June 21, 2002 5:14 PM
To: [email protected]
Subject: Re: [DOTNET-ADVOCACY] Cost of migrating to .Net


But the point isn't to move your existing applications to .NET, unless you
have a good reason to do so.  New development can be done in .NET at about
the same cost (cheaper, once the learning curve has been
conquered) as new development in VB6.0.  Since in .NET you can continue to
use your existing business rules that live in COM+ components, I would have
to have a very compelling reason to move those rules to .NET (for instance,
they had to be changed in some major way).