{"id":3564,"date":"2023-04-27T15:17:05","date_gmt":"2023-04-27T19:17:05","guid":{"rendered":"https:\/\/www.tmurgent.com\/TmBlog\/?p=3564"},"modified":"2023-04-27T15:21:53","modified_gmt":"2023-04-27T19:21:53","slug":"anatomy-of-a-migration-project-from-app-v","status":"publish","type":"post","link":"https:\/\/www.tmurgent.com\/TmBlog\/?p=3564","title":{"rendered":"Anatomy of a Migration Project from App-V"},"content":{"rendered":"\n

You probably saw my post about the end of life for App-V About Microsoft App-V End of Life \u2013 Confessions of a Guru (tmurgent.com)<\/a> <\/p>\n

In this post, I’ll highlight a summary of what a migration project looks like.  You have time, but if your organization depends on App-V today, someone should be starting a planning project now.<\/p>\n

 <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

App Assess\/Rationalize:<\/strong> This step involves determining the list of applications that will be migrated. On most migration projects, the determined list will be augmented by about 20% by the end of the project.\u00a0 This is represented by the\u00a0Continual App Discovery<\/strong> item, where things that exist but were not initially known are found, and new business requirements appear.\u00a0 In migrating from App-V, you should have a pretty good initial list already so I might lower that 20% but fear that the coming “AI everything” wave will cause an increase in new business apps (many of which will be short lived).\u00a0 So your plan should expect project scope increases.\u00a0 Don’t skimp on the rationalization part either; determine if the app is still used\/needed or if maybe a better way exists to meet the business need today.<\/p>\n\n\n\n

Tech Assessment\/Plan<\/strong>: <\/strong>First, this should be consulting with other groups in the organization to understand other potential migrations. Maybe, for example, there is a plan to drop Citrix for AVD, on conversely maybe move towards Citrix and turn all of those pandemic laptops that won’t run Windows 11 into thin-clients. Once you understand what scenarios you’ll need to support, then you can look at the options for how to prepare\/deliver the apps. It might be the Microsoft answers, or sometimes third-party solutions. It will probably be a combination of techniques, which is why the drawing has both a Primary Migrations <\/strong>and Secondary Migrations<\/strong> path.<\/p>\n\n\n\n

Business Impacts<\/strong> is the part of the plan that covers other impacts on the business. For example, training the help desk, or re-training employees. <\/p>\n\n\n\n

Rollouts.<\/strong> Everybody loves a good rollout. You should try to roll out in pieces as you go along, rather than a big-bang style roll out at the end of the project. But that isn’t always practical.<\/p>\n\n\n\n

<\/p>\n\n\n\n

Other:<\/strong> Although not shown, there is an argument to be made that this is a great opportunity to implement a full application lifecycle strategy going forward. Like operating systems, applications are moving to shorter lifecycles and the idea of install-and-forget is making less sense. With the implementation of proper automation, this can lead to less work for IT and happier end-users. This might include:<\/p>\n\n\n\n