Migrating your apps to Windows 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
href="http://www.rational.com/products/teamtest/w2k/w2kds.jtmpl">www.rational.com/produc
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
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
Symantec Backup Exec 12 and Backup Exec System Recovery 8 deliver industry leading Windows data protection and system recovery. Download this whitepaper to find out the top reasons to upgrade and how to get continuous data protection and complete system recovery.
Data and system loss — from a hard drive failure, malicious attack, natural disaster, or simple human error — can happen anytime. Don’t leave your business vulnerable. Make sure you have a secure recovery strategy in place. Symantec's latest backup and system recovery technology can efficiently restore critical applications, individual emails and documents and even restore your entire system in minutes in the event of a loss.
Businesses face a growing challenge to ensure that the IT environment is properly protected. Backup Exec 12 integrates with other applications in the Symantec family of products, to complement your current data protection strategy, keep your data securely backed up and make it recoverable when you need it most.







