SAN MATEO (02/03/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+, see page 51. 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 www.rational.com/products/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 msdn.microsoft.com/certification/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 config.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 platformAt 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.
Mario Apicella, a technology analyst for the InfoWorld Test Center, is a former programmer and database administrator. You can reach him at mario_apicella@infoworld.com.
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.