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 href="http://msdn.microsoft.com/certification/appspec.asp">msdn.microsoft.com/certificat
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.