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.
Why the Date Matters More This Year
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.
Why the Device Count Misleads
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:
- Needed: is the application still used, and by whom?
- Owned: is there a named business owner who can sign it off?
- Deployable: does it install and run cleanly on the target platform?
- Repackage: does it need a new package, or will the existing one do?
- Dependencies: what does it rely on, and what relies on it?
The Queue Maths
Ask for two numbers alongside every migration update:
- How many applications are still waiting to be packaged and tested?
- How many get packaged and tested each week?
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:
- How many have failed testing, and why? Repeated failures usually point to inconsistent packaging, not bad applications.
- How many have no named owner? An application nobody can sign off can't leave the queue.
Shorten the Queue: Triage Before You Repackage
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:
- Does the vendor provide a supported silent install?
- Does it configure the application the way the business needs?
- Does it uninstall cleanly?
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.
Write One Packaging Standard
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:
- Naming and versioning: so anyone can tell what a package is and which version it holds.
- Install behaviour: silent by default, with documented parameters.
- Logging: where install and failure logs go, every time.
- Removal: every package must uninstall cleanly.
- Testing and sign-off: what is tested, by whom, and how it's recorded.
- Format choice: how the team decides which format to use, and where the reason is written down.
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.
Choose the Format by the Application, Not by Habit
Teams often default to whatever format they used last. A better rule is to choose per application and record why:
- MSI: widely supported and well understood, a sensible default for many traditional Windows applications.
- MSIX: a modern format with clean install and removal, worth using where the application supports it.
- App-V: application virtualisation, useful for isolating applications that conflict with each other.
- The vendor's installer: where it's supported, silent and removes cleanly, it's often the least effort to maintain.
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.
Roll Out in Pilot Cohorts, Not All at Once
"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.
Keep Packaging Running Between Migrations
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.
How Camwood Helps
We help enterprises and SMEs clear the packaging queue and keep it clear, using our Sync, Align, Optimise approach.
- Sync: see the real queue. Our application readiness assessments build the per-application view (needed, owned, deployable, repackage, dependencies) before the migration date is fixed, so the plan is built on the applications, not just the devices.
- Align: package to one standard. We package to a written standard, triaging for the vendor's silent install first and choosing MSI, MSIX, App-V or the vendor's installer per application, with the reason recorded. We run pilot cohort rollouts that mirror your estate and widen one group at a time.
- Optimise: keep it current. Our continuous packaging service keeps the catalogue deployable between migrations. With ALICE, our application lifecycle platform, new upstream versions are checked on a schedule and built as new packages using the previous configuration, while a person still sends each release through testers and phases.
A Checklist for Your Next Migration Update
- Count the applications still waiting to be packaged and tested.
- Measure how many are packaged and tested each week, and divide.
- List the applications that failed testing, with the reason.
- Name an owner for every application in the queue.
- Retire what nobody needs before it's packaged.
- Check for a supported vendor silent install before repackaging.
- Write, or update, one packaging standard and use it for every package.
- Record the format chosen for each application, and why.
- Plan pilot cohorts that mirror the business.
- Decide how packaging continues after this migration ends.
Frequently Asked Questions
What's the difference between MSI and MSIX?
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.
What is a silent install?
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.
How long does application packaging take?
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.
Do we need to repackage everything for Intune or Windows 11?
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.
See What's in Your Packaging Queue
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.
