As companies begin in earnest to upgrade their computer applications to Year 2000 compliance, they are finding that there are many complex and time-consuming issues that they had overlooked when they first tried to size and scope the project. Much of the Year 2000 discussion and activity has concentrated on finding analyzing and changing the code. While these aspects are very important, they consume at most one-third of the effort of the Year 2000 compliance project. There are other issues of Year 2000 compliance which will take a great deal more effort than has been allocated by most organizations. The paper explores several of the forgotten issues of the Year 2000 upgrade, including: Year 2000 compliance for purchased application packages; upgrading versus replacing existing applications; avoiding a freeze of in-house production software while the Year 2000 project is underway; creating test data beds containing intelligently aged date fields; and verifying the accuracy of application tests. While these issues would be important for any upgrade, for the Year 2000 upgrade there is a special significance. For the first time in data processing history, we have an application project for which there is no easy fallback position and no way to move the deadline.