A modern endpoint does not mean you have modern applications

August 25, 2026 at 02:08 PM

There is a point in many endpoint projects when the new environment appears to be ready.

<![CDATA[ <article> There is a point in many endpoint projects when the new environment appears to be ready. Devices are enrolled, policies are in place and physical endpoints and <a href="https://www.techradar.com/best/virtual-desktop-services">virtual desktops</a>—including Cloud PCs—can be provisioned. From an infrastructure perspective, most of the difficult work seems to have been done. The applications often tell a different story. Moving an older application onto a new platform does not alter its underlying behavior. It may still rely on ageing components and expect administrator access to write files and registry entries across the device. Its update process may also be largely manual or poorly documented. A well-managed endpoint is valuable, but it cannot make a difficult application easier to maintain simply by <a href="https://www.techradar.com/web-hosting/best-web-hosting-service-websites">hosting</a> it.<h2 id="a-successful-deployment-can-hide-the-real-work">A successful deployment can hide the real work</h2>Modern management platforms have made it much quicker to enroll devices, assign software and apply policies across an organization. <a href="https://www.techradar.com/best/best-cloud-computing-services">Cloud services</a> and virtual desktops have also taken much of the effort out of provisioning the underlying environment. These are genuine advances, but they can create a false sense of completion. An application may open in the new environment and appear ready for production.The problems tend to emerge later. An update arrives and the packaging process has to be recreated. An <a href="https://www.techradar.com/news/best-alternative-operating-systems">operating system</a> change exposes a dependency that was never recorded. A certificate expires, or a new release behaves differently from the version originally tested. None of these issues are solved by the fact that the application was delivered through a modern platform. Deployment gets an application to the user; modernization determines whether IT can continue to manage it once the project team has moved on.<h2 id="old-assumptions-follow-applications-into-new-environments">Old assumptions follow applications into new environments</h2>Enterprise application estates tend to grow gradually. Software is added over many years, often under different teams and different versions of Windows. Some applications expect access to folders or <a href="https://www.techradar.com/best/registry-cleaners">registry</a> locations that would not be considered appropriate today. Others rely on old runtimes, fixed paths or components installed so long ago that nobody is entirely sure why they are there. Accompanying <a href="https://www.techradar.com/pro/best-it-documentation-tool">IT documentation</a> is rarely complete. The original installer may have disappeared and the person who understood the application may no longer work for the organization, yet the software itself may remain essential to a finance team, production line or clinical process.Moving to modern endpoint management such as Intune, a Cloud PC or a new virtual desktop environment does not remove those assumptions. In some cases, it exposes them because modern environments place tighter limits on what software is allowed to change. A launch test will reveal only part of the picture. <a href="https://www.techradar.com/best/it-management-tools">IT management</a> also needs to know how the application installs, what it depends on, which parts of the system it expects to access and how it is updated and removed. Age alone is not a reason to replace an application. Many older line-of-business tools remain useful and business-critical. The aim should be to understand the software well enough to manage it properly, rather than carrying its old behavior into a new environment without examining it.<h2 id="modernization-does-not-have-to-mean-rewriting-software">Modernization does not have to mean rewriting software</h2>Rewriting every legacy application would be impractical for most businesses and may deliver little value where the existing software still performs its function well. A better test is whether the application can be supported throughout the rest of its working life. That requires a clear view of its files, services, dependencies and interaction with Windows. Once those details are known, compatibility problems can be addressed deliberately rather than discovered by users after deployment.Packaging is part of that work, although it is not the whole answer. On Windows, formats such as MSIX can give an application a clearer identity, require digital signing and separate more of its activity from the underlying operating system. They can also support cleaner removal and more controlled updates. MSIX can provide a more secure and manageable foundation, although applications with legacy middleware, undocumented dependencies or highly specialized configurations may still require additional work. This is why organizations need to identify complex applications early. Testing must also reflect real use: opening the main window does not show whether employees can complete the tasks they rely on, whether the next update will install successfully or whether the application will continue working when another part of the environment changes.The scope becomes clearer when organizations view the modern endpoint as a set of interconnected components. A desktop comprises three core elements: the operating system, the user profile, and applications. Hardware is the fourth component, but the same principles apply whether the machine is physical or virtual. The applications work is therefore a project in its own right. Applications must be brought under control, secured, and kept up to date and delivered to the right users, with the control and compliance an organization requires.<h2 id="bring-applications-into-the-project-sooner">Bring applications into the project sooner</h2>Applications are often treated as the last stage of an endpoint program. The platform is selected, the environment is built and only then does the organization begin working through the software estate. By that point, timelines have been agreed and assumptions about compatibility may already be built into the plan. Difficult applications emerge as late exceptions, when there is the least room to deal with them.Bringing application assessment forward gives IT a clearer view of what it is migrating. Teams can establish which applications are in use, which are business-critical and which depend on technology that may not be available in the new environment. They can also separate routine applications from those requiring deeper technical or business knowledge. I have worked in this industry since the late 1990s and have seen enterprise desktops move from early thin-client systems to virtual desktops and, more recently, cloud-hosted PCs. The infrastructure has improved enormously, but the questions around applications have barely changed. A modern endpoint is an important step, but the real measure of modernization is whether the organization can understand, update and support the applications running on it.<a href="https://www.techradar.com/news/best-endpoint-security-software">We've rounded up the best endpoint protection software suites</a>.This article was produced as part of <a href="https://www.techradar.com/pro/perspectives" target="_blank">TechRadar Pro Perspectives</a>, our channel to feature the best and brightest minds in the technology industry today.The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: <a href="https://www.techradar.com/news/submit-your-story-to-techradar-pro" target="_blank">https://www.techradar.com/pro/perspectives-how-to-submit</a> </article> ]]>

Read the full article on TechRadar

Read Full Article →