The packaging backlog that stalls migrations

Blog April 2026

The blocker nobody budgets for

Deployment rings, Autopilot profiles and compliance policies can be built in weeks. A backlog of 400 unpackaged applications cannot. Every device that runs a line-of-business application waits for that application to be packaged, tested and released before it can migrate, so packaging throughput sets the pace of the entire programme. We see this constantly: Windows 10 left support in October 2025, and a good share of the organisations now paying for Extended Security Updates are not buying time for hardware or infrastructure. They are buying time for packaging.

Packaging throughput sets the pace of the entire programme. If you can package ten applications a week and have 600 to do, your migration is a year long whatever the plan says.

Why the backlog forms

Packaging backlogs are organisational before they are technical, and the same four causes appear again and again.

No owner. Packaging falls between teams: the desktop team assumes the application owners will handle it, the application owners assume IT will, and the service desk inherits the fallout. Without a single accountable owner and a tracked queue, requests arrive by email, sit unprioritised and age.

Tribal-knowledge installers. Many business-critical applications were installed once, by hand, years ago, by someone who has since left. The transforms, registry keys and post-install fixes live in nobody's documentation. Recreating that install reliably is investigative work, not packaging work, and it is slow.

Vendor media chaos. There is no definitive source for install media. Versions are scattered across file shares, licence keys sit in spreadsheets, and the vendor download that built the current estate no longer exists. Before anything can be packaged, someone has to establish what the correct, licensed, supported version even is.

The testing bottleneck. Even where packaging itself is quick, sign-off is not. Business users are asked to test with no script, no deadline and no consequence for silence, so finished packages queue behind UAT indefinitely. The backlog looks like a packaging problem but is really an approval problem.

What good looks like

High-performing packaging functions are unglamorous and consistent. They share five traits.

A written standard. Naming conventions, install context, detection rules, logging paths, exit codes and supersedence behaviour are defined once and applied to every package. A package produced by any engineer should be indistinguishable from one produced by any other.

A common wrapper. Frameworks such as the PowerShell App Deployment Toolkit give every package the same structure for pre-flight checks, user prompts, deferrals and logging. When something fails in the field, the log tells you where, in the same format, every time.

Silent-install discipline. Every package installs, upgrades and uninstalls silently, with no user interaction and a deterministic result. If an application cannot be made to install silently, it cannot be deployed at scale, and that conversation needs to happen with the vendor early, not in deployment week.

UAT as a gate, not a suggestion. Each application has a named business tester, a short test script and a timeboxed sign-off window with an agreed escalation when the window lapses. Testing becomes a stage with a duration, not an open-ended wait.

An SLA-driven pipeline. Intake, packaging, QA, UAT and release run as a managed queue with published turnaround targets per complexity tier. That makes throughput measurable, which makes the migration end date forecastable instead of aspirational.

Rationalise first, and the backlog shrinks

The strongest lever is not packaging faster; it is packaging less. Most estates carry far more applications than the business actually uses: duplicate tools, superseded versions, software deployed for people who left years ago. Usage evidence from discovery tooling separates the applications people rely on from the ones that merely exist, and the gap is routinely enormous. On one engagement, rationalisation took an estate of 26,000 application installations down to about 1,000 that genuinely needed to move.

Rationalising before you package means every hour of packaging effort lands on an application with a proven user and a business owner. It also flushes out the vendor and licensing questions while there is still time to answer them. We have set out the wider case in rationalise before you migrate, and our optimisation and rationalisation service exists to do exactly this work with evidence rather than opinion.

Treat packaging as a production line with a named owner, a standard, a gate and a shrunken input, and it stops being the reason your migration slips. Leave it as a shared inbox, and it will be.