Triage first, because intermittent on hardware of that vintage means the clock is running, then the exit, because 2000 has no other responsible ending.

The error log is the triage center: in 2000 it lives under the instance's LOG directory as ERRORLOG files, readable in any text editor or through Enterprise Manager. Read the recent files for the actual error numbers behind the intermittent behaviour, and what you find sorts into two piles. IO errors, 823 and 824 style, mean the disks are dying under the database, the pile that turns triage into evacuation. Everything else, login failures, resource errors, application misbehaviour, buys time to plan.

Two commands while you are in there, era appropriate versions: DBCC CHECKDB against each database verifies whether corruption has already arrived, on 2000 run it in a quiet window since that era's CHECKDB blocks heavily, and sp_who2 remains the who is connected view when the application misbehaves. And the single most valuable command on any 2000 sighting: BACKUP DATABASE to somewhere off that machine, tonight, verified by restoring it elsewhere, because whatever the errors mean, the fossil's data now exists in the present day.

The exit has a path despite the age gap: modern SQL Server refuses direct upgrades from 2000, the stepping stone is restoring the backup onto SQL Server 2008 or 2008 R2, running the upgrade there, then restoring that result onto a supported version, testing the application against each hop. The application, built for 2000, is the real risk in the exit, so the test environment matters more than the production cutover. Where the vendorless application simply cannot leave, the fallback containment is virtualizing the whole machine so the fossil at least lives on modern hardware with snapshots, isolated from the network's sharp edges, while the data itself, extracted via that backup, feeds whatever replaces it eventually.