Why application modernization must start before endpoint migration
When you purchase through links on our site, we may earn an affiliate commission. Here’s how it works.
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 virtual desktops—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 hosting it.
Sign up to the TechRadar Pro newsletter to get all the top news, opinion, features and guidance your business needs to succeed!
Modern management platforms have made it much quicker to enroll devices, assign software and apply policies across an organization.
Cloud services 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 operating system 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.
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 registry 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 IT documentation is rarely complete.
