Windows 2000: inventory application dependencies before migration

A copied executable does not make an application portable. An old Windows 2000 computer may also depend on databases, network paths, drivers or licensing devices. This guide creates a traceable inventory for a later migration; it installs or repairs nothing and does not certify compatibility with a newer Windows.

1. Record the starting point

Work on the existing legacy system disconnected from the internet. Record the date, computer, signed-in user and application being examined. In the program’s About dialog, record the vendor, exact version and extensions. Gather its installation source and licensing documents in a protected location. Do not put passwords or licence keys in the general inventory report.

2. Save System Information

  1. Open Start – Run and enter msinfo32.
  2. Capture System Summary, including Windows version, service pack, computer name and regional settings. Use the available save or export function and keep a readable text report in a new inventory folder.
  3. Under Software Environment, inspect services, loaded modules, environment variables, network connections and startup programs. Record paths and versions of relevant entries.
  4. Under Components, check printers, ports and special devices required by the application. Reopen the saved output and verify that the required sections are present.

3. Add application-specific details

Create a list with the fields dependency, observed value, evidence, owner, still to check. Fill it from existing program settings, documentation and known workflows:

  • Data folders, templates and configuration files: record them separately from the executable.
  • Mapped drives and actual share targets, database server, database name and required drivers: do not include credentials.
  • Associated services, startup mode, service account and scheduled tasks: document only, without stopping or changing them.
  • Printers, scanners, serial devices, dongles and their matching drivers, plus additional runtime components.
  • Required user rights, file formats, import/export paths and vendor contacts.

4. Explicitly mark gaps

System Information is a snapshot, not a complete dependency checker. A loaded DLL entry does not prove portability; a DLL absent from the list is not proof that it is never needed. A program list alone is insufficient too. Microsoft even documents entries for uninstalled Office applications in the Office 2000 module; many detailed fields are populated only while the application is running. Do not run unknown workflows on the original system merely to complete the list. Mark unclear points as open.

5. Turn the inventory into acceptance tests

With the business owner, define concrete tests for a separate test environment: open a representative data copy, verify the result, save and reopen it, and test required printing or export. Clarify installation rights, licence transfer, available drivers and a verified data backup with a recovery procedure beforehand. Simply launching the program or copying its folder is not a successful migration. Retain the original installation and data until acceptance is supported by evidence.

Sources