This article applies if you’ve recently made changes to your device hardware and are trying to upgrade to Windows 11. Hardware changes might affect your upgrade eligibility, though you’ll need to take a few steps to see your updated eligibility in Settings. This article might also apply if messages in the PC Health Check app and the Windows Update page in Settings don’t match. If you recently made any changes to your hardware and want to see if your computer now meets the requirements for Windows 11, the easiest way to do that is with the PC Health Check app: If you haven't yet, install the PC Health Check app here. Press Windows logo key + S or select Search, type pc health check, and select PC Health Check from the list of results. Select Check now. It can take up to 24 hours for Windows Update to refresh your eligibility info. If your eligibility info is not updating in a timely manner, you can also manually refresh the Windows 11 eligibility assessment using the following steps. Note: Changing your hardware doesn’t necessarily mean your device will be offered Windows 11 immediately. The upgrade will roll out over time to in-market devices based on intelligence models that consider hardware eligibility, reliability metrics, device age, and other factors. We intend to roll the upgrade offer out as quickly as possible, while ensuring a high-quality experience. You can refresh the Windows 11 eligibility assessment by either using Task Scheduler or running it from an administrator Command Prompt.
Upgrade to Windows 11: FAQ Windows 11 System Requirements Can I upgrade to Windows 11? Ways to install Windows 11 Installing Windows 11 on devices that don't meet minimum system requirements One of the primary tasks in preparing for testing is to write a test plan. In the test plan, you specify the scope and objectives for the testing and describe the methodology you are going to use. When you develop a test plan for testing application compatibility with Windows, include the following: Scope: What priority levels you address during testing? Methodology: Who does the testing involve? Requirements: What hardware, software, personnel, training, and tools you need to perform the testing? Criteria for pass-fail: What determines if an application passes or fails? Schedule: How do you plan to complete the testing by the scheduled date? If your organization uses many applications, you may not have time to test all of them as thoroughly as you would like. Test the highest priority and the most frequently or widely used applications first. Test both server-based and client-based applications. Client-based applications are usually the most difficult and time-consuming to test because of the amount of applications. When you plan the methodology, consider the following: Where will the testing take place? Who will perform the tests? How will you communicate with and involve participants? How will you schedule the testing? How will you manage application problems? If your organization has a group of application testers, we recommend that you use them. If you do not have such a group, look for ways to use a variety of resources to achieve the best results in a reasonable amount of time. For example, you can use a few experienced testers to develop a battery of test cases, which they can train others to run. Alternatively, you might have the experienced testers perform a core set of tests and then coordinate with business units to have their experts come to the lab to perform the functions they use in their work. Devise a process for scheduling test days and communicating with the testers. For example, you might set up a Web site on your intranet where anyone can view test dates, status reports, contact names, and other relevant documents. As you plan for application compatibility testing, keep in mind the future state of your computing environment. Are you planning to upgrade some of your software to versions that fully use new Windows features? Are you planning to implement new standard desktop configurations or use Terminal Services? Issues such as these determine the resources that you require and the applications that you are going to test as a suite. If you plan to deploy new applications with Windows during the rollout, test these applications with the current applications. You can facilitate testing by setting up a lab where testers can conduct their tests. In such a lab, you can have the necessary tools and equipment available at all times. In the lab, set up the test computers for dual or triple boot so that testers can quickly access the mode they need to install and test their applications. For example, you might need Windows NT 4.0 and Windows 2000 to test the applications through the upgrade path. To make it easy for testers to restore the computers to their prior state, make disk images of the drives with the base operating systems. Define a procedure for testers to know when and where they are to log application problems and issues that you want to resolve. To define the criteria for pass and fail, consider issues such as the following:
Your testing schedule depends on many conditions, including:
Many commercial applications have already been tested to determine how well they support Windows 2000 and later. Microsoft provides a directory of applications for Windows 2000 where you can look up the status of the applications you use. The directory uses the following designations:
The goal of your application testing is to verify that everything that works on your current platform also works on your current version of Windows. If an application was written for an earlier version of Windows, it does not necessarily use new Windows features, but its functionality should work in Windows 2000 as it does on your current platform. For commercial applications, the first step is to run Setup in check-upgrade-only mode to check for potential incompatibilities. When you run Setup in this mode, Windows checks the installed software against a list of applications known to be incompatible and logs any that it finds. The command line format for check-upgrade-only mode is: winnt32 /checkupgradeonly Although this tool can alert you to potential compatibility problems, it addresses only a small percentage of your applications and only the applications installed on the computer you are checking. The next step is to check the directory of Windows applications to determine the compatibility of the applications you use. Even if you find that some of your applications have already been tested by others, you should test them in your environment. In this case, focus your testing on the way your organization uses the applications. For example, test the following:
Remember to test your antivirus software. Many of these applications need to be upgraded because of their use of file system filters. Many Windows NT 4.0 files system filters might not work on Windows 2000 or later due to changes in the NTFS file system. If you use custom third-party products or develop applications internally, you need to develop a more extensive testing strategy than for pre-tested commercial applications. Even if you are testing an application which you did not develop, the Windows 2000 Application Specification can provide insight into testing. The MSDN Web site at http://msdn.microsoft.com includes a downloadable version of the specification. The MSDN Web site also contains other important information about testing, such as white papers about exploratory testing and the method that independent testing organizations use to test the functionality of applications vendors submit for certification. NOTE: The testing suggestions in this section are not comprehensive and do not apply to all situations. They are provided to help you start thinking about how to test. Test installing and running your applications using the scenarios you plan to use during deployment. For example, you might plan to deploy by installing on clean computers or by upgrading from Windows 95 or Windows 98 or an earlier version of Windows NT. If you plan to upgrade, you might keep the applications on the computer during the upgrade, or you might uninstall them and reinstall them after the upgrade. Because of differences between Windows 95 or Windows 98 and Windows 2000, some application installations work differently depending on which operating system you use for the installation. For example, if you install an application on a computer running Windows 95 or Windows 98, and then you upgrade the computer to Windows 2000, the application might not work the same way as it would have if you had installed it in Windows 2000. In this case, you might need to uninstall the application and reinstall it after you upgrade or obtain a migration dynamic link library (DLL). A migration DLL allows an application that was originally installed on Windows 95 or Windows 98 to function correctly after the computer is upgraded to Windows 2000. Migration DLLs can resolve application problems by performing the following actions:
If you are planning to upgrade your computers:
If you are planning to install on reformatted computers:
Test application installation in a variety of ways, such as the following:
Test applications using the features, configurations, and application suites you use to accomplish business tasks. Try to access data in a variety of ways, such as the following:
Print a variety of document types with a variety of printers, such as the following:
Applications developed for previous versions of Windows might not take full advantage of new features, such as Active Directory or IntelliMirror. This section does not address these new features.
When you encounter application compatibility problems, you need to prioritize them and then assign someone to resolve them. You should have a plan for how to assign problems. Assigning the appropriate personnel to research and resolve problems is critical to the success of your application testing. Problem resolution might encompass a wide variety of activities, such as the following:
As you research the cause of a problem, consider various approaches to determine the most effective solution. For example, you might choose to:
Always be sure that a problem does not occur on your current platform before researching it as a Windows 2000 compatibility issue. Some of the available resources for researching Windows 2000 compatibility issues are:
|