Welcome Guest!
Create Account | Login
Locator+ Code:

Search:
FTPOnline
Channels Conferences Resources Hot Topics Partner Sites Magazines About FTP RSS 2.0 Feed

email article
printer friendly
more resources

12 Considerations for .NET App Migration
You need to weigh a wide array of issues before you move your applications to .NET—use these 12 as a starting point.
by Jonathan Goodyear

For this solution: Visual Studio .NET

With the release of Microsoft's .NET Framework and Visual Studio .NET (VS.NET), you can no longer afford to sit on the sidelines with a "wait and see" attitude (see the sidebar "Weigh the Cost of Waiting"). If you're a Windows development shop, you'll need to contend with a wide variety of application development concerns to prepare for this landmark paradigm shift. In this article, I'll list 12 of these issues, explain how they could affect your migration, and offer suggestions for how to streamline your migration process.

1. Evaluate Project Status
If you live in a Microsoft world, you need to begin embracing the .NET lifestyle—but that doesn't mean you must migrate all your projects at once. Rather, evaluate each project to determine whether it's an immediate candidate for .NET migration, if you should migrate it later, or not at all. Start with the project timelines and determine where each of your applications is in the development life cycle. For new projects, consider developing with the .NET Framework. Projects already in development, on the other hand, shouldn't be converted to .NET until the next major release because changing platforms midstream can be costly and time consuming. You should migrate existing, completed applications or components that need to interface with your new .NET applications and components first. Because you incur a performance penalty for calling unmanaged COM components from .NET managed code components (and vice versa), you'll want to eliminate that bottleneck as soon as possible. If you have applications and components that exist in a vacuum, and are adequately meeting business needs, you don't need to convert them to .NET in the immediate future.

2. Determine Your OS
The operating system (OS) platform you plan to target can also have a substantial impact on your .NET migration plan. When paired with Windows 2000 or Windows XP, you can take full advantage of the .NET Framework's feature set. Therefore, if your user base hasn't upgraded to one of the latest Windows operating systems, you might want to explore upgrading them at the same time you do your .NET migration. Although the .NET Framework works on Windows 98 and Windows ME, these platforms don't offer full access to everything .NET offers. For example, .NET applications deployed on Windows 98 or ME won't have local COM+ support, because it's not baked into the OS (Note: Microsoft recently renamed COM+ as .NET Enterprise Services). Also, on these two OSs, the Internet capabilities of the .NET Framework will be limited. Of course, if you're moving to an ASP.NET Web application architecture, the client OS is less of a factor (possibly none at all).

Back to top

Printer-Friendly Version











Java Pro | Visual Studio Magazine | Windows Server System Magazine
.NET Magazine | Enterprise Architect | XML & Web Services Magazine
VSLive! | Thunder Lizard Events | Discussions | Newsletters | FTP Home