Print
Close Window
From: www.itworld.com
Migrating your apps to Windows 2000
December 13, 2000 —
WHENEVER there's a major software release, IT directors face both good news and bad
news. True, embracing the new approach may bring improvements in functionality, but
then there's the inevitable hailstorm of glitches. This scenario is especially
pronounced when it comes to an OS like Windows 2000, which includes thousands of
modules and measures disk storage in hundreds of megabytes.
In this Test Center Action Plan, we'll show you how to make sure that your code
will work on the new Windows 2000 bed. For information on the new development
infrastructure that Windows 2000 offers, such as COM+. Here we'll focus on porting the
applications "as is," or without making code changes.
Take stock of what you have
The first step in your migration project is to create or update your company's
applications inventory. Without a portfolio of applications, you can't make a precise
estimate of the effort required to move to Windows 2000.
You may be able to use an old inventory left over from the Y2K project. But for
Windows 2000 migration, your inventory should be more comprehensive: You'll want to
detail each application module, track the flow of relationships between modules, and
classify them by programming language and application environment.
Make sure you're playing by the rules
Next, assess how much work (if any) each application requires to be a good Windows
2000 citizen. This is the most difficult part of the job and may require compromises.
To help identify compliance issues in your code, you could use Rational Software's
TestFoundation for Windows 2000, a free package that tests how your applications stack
up against the Windows 2000 specification. The program is at
ts/teamtest/w2k/w2kds.jtmpl.
Thankfully, Windows 2000 is binary-compatible with previous Microsoft operating
systems, so existing software should work. Just bear in mind that whenever you move to
a new environment, the probability of success depends on how compliant the applications
are with safe programming practices.
For example, in DOS, it's possible for a program to access the file system without
using the standard APIs, but an application that does this won't work on Windows 2000.
Actually, a DOS application that bypasses APIs won't work on Windows 98 or NT 4.0,
either. But Microsoft has imposed even more demanding rules of behavior for apps
running on Windows 2000: Among other things, applications must now perform proper
version checking, recognize overwrite rules, and install and uninstall according to
Windows 2000 standards. (You can download a list of the specifications at
ion/appspec.asp.) Depending on the complexity of your software, you may be faced
with significant rewrites.
On the other hand, following those requirements verbatim could significantly
increase the effort required to move your applications to Windows 2000. Our
recommendation is to evaluate the costs and risks associated with each of Microsoft's
suggestions, then create two lists: a "must-do now" list and an itemized follow-up of
points to address after the migration to Windows 2000. After all, not every
modification is mission-critical. For example, one of Microsoft's new rules is that
your software should not make changes or read from system configuration files such as
cconfig.sys, autoexec.bat, win.ini, and system.ini. If you have more important issues
to address, you may want to make the system configuration adjustments after porting
your applications to Windows 2000, ensuring that, until then, your system files remain
consistent with your applications.
Other times you won't have that option, because some of Windows 2000's new
standards will prevent your software from running -- such as the feature that won't
allow key operating system components to be replaced. If your software setup replaces
system modules or fonts, you'll have to make changes.
Test your applications on the new platform
At this stage, you have a detailed inventory of your applications, and you know
what's needed to make them compliant with your migration project. At the end of this
exercise, you should have some dollar figures to put in your migration budget. Your
next step should be to run your software on a test bed to ensure that everything works.
Have a test plan ready for each application defining the individual elements of
your testing activity. For example, you'll want to ensure that your application will
install and run correctly on a Windows 2000 machine, that it will survive an update to
the new OS, and that changing code to comply with Windows 2000 won't cause your
software to fail on previous versions of Windows.
To test these behaviors, you'll have to prepare several clean testing scenarios,
making sure that you can back up your systems to pristine status after each test cycle.
This calls for a lot of configuration work that, fortunately, can be lessened using
tools such as Ghost from Symantec. Similarly, Rational's TestFoundation for Windows
2000 can take snapshots of your Windows registry and file system before and after
installing an application, automatically documenting changes and compliance problems.
Migrating applications to a new platform can be such a tedious project that, in
many cases, the effort involved convinces IT departments not to migrate at all. But
Windows 2000 will ship with many excellent features -- with the promise of much more to
come -- that could, in the end, make your system easier to program and less expensive
to maintain.
Migration step-by-step
1. Take an inventory of your applications. Document relationships among modules and
group your applications by OS and programming language.
2. Analyze Microsoft's application specifications for Windows 2000.
3. Define, according to the time and resources available, a minimum set of
requirements for the migration.
4. Analyze each application and define Windows 2000 compliance actions. Estimate
the time and resources required for conversion and testing.
5. Prepare test bed and start the testing cycle. Revise deployment documentation
after each cycle.
www.infoworld.com