Direct answer: A Windows 11 or Intune migration finishes when the last application the business needs is packaged, tested and deployable, not when the last device is upgraded. To know your real date, divide the number of applications still waiting by the number your team packages and tests each week. Then shorten the queue: check whether the vendor's own silent installer will do before repackaging, write one packaging standard, choose the format per application, roll out in pilot cohorts that mirror the business, and keep packaging running between migrations so the backlog doesn't rebuild.
The second year of Windows 10 Extended Security Updates is now under way. Organisations still running Windows 10 devices pay for those updates per device, and under Microsoft's own pricing the price doubles every consecutive year. Every month a device stays on Windows 10 now costs more than it did last year.
That makes the finish date a budget line. A plan that slips by a quarter isn't just late; it's paying for a quarter of extended support it didn't need.
Most migration plans are written around devices: how many have moved, how many are left, how many per week. Devices are easy to count and quick to move. With modern deployment, a device can be rebuilt in an afternoon.
Applications are different. A device can't move until every application its user needs works on the new platform. One application that isn't packaged, or that fails testing, holds back every device that depends on it. So a programme can show 60% of devices ready while the remaining 40% wait on the same handful of applications.
That is why the application list, not the infrastructure, decides the date. Before fixing a migration plan, build a per-application view:
Ask for two numbers alongside every migration update:
Divide the first by the second and you have the number of weeks the programme still needs, whatever the device chart says. If 240 applications are waiting and the team clears 20 a week, the earliest realistic finish is 12 weeks away, before any rework. (Illustrative figures.)
Two more numbers explain why the queue moves slowly:
Not every application needs repackaging. Many vendors ship a supported silent install that can be deployed as it is, with the right parameters. Before an application enters the packaging queue, check:
If the answer to all three is yes, deploy the vendor's installer and record why. Repackage only when the vendor route can't install, configure and remove the application cleanly. That one triage step can take a meaningful share of applications out of the queue before anyone starts building.
And before triage, confirm the application is still needed. The fastest application to package is the one you retire. Our guide to application rationalisation covers how to decide what goes.
When packages are built to individual habits, they behave differently. One installs silently, another prompts the user. One logs failures, another fails without a trace. One uninstalls cleanly, another leaves files and registry entries behind. Each difference is a support ticket waiting to happen, and each package has to be checked again at the next migration.
A written packaging standard fixes that. It doesn't need to be long. It should cover:
The standard makes packages faster to build because nobody has to decide the basics again, and faster to support because they all behave the same way.
Teams often default to whatever format they used last. A better rule is to choose per application and record why:
The right choice depends on the application's behaviour, its dependencies and how often it changes. Recording the reason means the next person doesn't have to work it out again.
"Light the fuse and stand back" is a poor migration plan. Rolling out to everyone at once means every problem lands at the same time, on every team.
Pilot cohorts work better. Build small groups that mirror the business: a few people from each department, each role and each set of applications. Move a cohort, test the applications people actually use, fix what breaks, then widen to the next group. Each cohort is a rehearsal for the next, and the problems shrink as you go.
Cohorts also show you the queue in real terms. If a cohort can't move because two applications aren't ready, those two go to the top of the packaging list.
Many organisations package in bursts: a big push before each migration, then nothing until the next one. In between, new versions arrive, new applications are requested and the backlog quietly rebuilds. By the next migration, the queue is back.
A continuous packaging service keeps the estate deployable all the time. New versions are packaged as they arrive, new requests go through the same standard, and the next migration starts from a current catalogue rather than a backlog. It also makes the cost predictable: a steady service rather than an emergency project every few years. It's one part of application lifecycle management done as a continuous discipline.
We help enterprises and SMEs clear the packaging queue and keep it clear, using our Sync, Align, Optimise approach.
MSI is the long-established Windows Installer format, supported by almost every deployment tool and well understood by packaging teams. MSIX is Microsoft's newer format: applications install in a contained way and remove cleanly. Not every application can be packaged as MSIX, particularly older ones that install drivers or make deep system changes, so choose per application and record why.
An installation that runs without prompting the user, with its options set by parameters. Enterprise deployment depends on it. Many vendors provide supported silent install options; where they configure the application correctly and remove it cleanly, use them before building a new package.
It depends on the application. A straightforward vendor installer may need only triage and testing, while a complex legacy application can take much longer to package, test and sign off. That's why your own weekly throughput is a more useful number than any industry average: it tells you when your migration will actually finish.
No. Start by retiring what nobody uses, then check which applications can be deployed with the vendor's own installer. Repackage only what can't install, configure and remove cleanly any other way.
Request a 30-minute discovery conversation with our team. We'll help you see what's in your packaging queue, and what it means for your Windows 11 date.