Device refresh readiness checklist

Why run this

What this checklist is for

A device refresh is the cheapest opportunity you will get to change your endpoint management model, and the easiest one to waste by ordering hardware before deciding how it will be configured.

It is also the point at which the academic calendar becomes the binding constraint. A refresh that slips into registration week costs more than the hardware.

Run it with

IT Director

And with

Endpoint and desktop teams

And with

Faculty and estates representatives

The checklist

20 checks, in the order we would run them

Tick only what you can genuinely evidence today. An item you intend to do is not an item you have done, and scoring yourself generously here only produces a comfortable number and an uncomfortable project.

Section 1

Procurement and registration

Decisions that must be made before the order, not after.

Supplier will register devices to your tenant at the point of purchaseThis is a purchasing conversation. Without it, somebody has to collect hardware hashes manually, which reintroduces the physical handling you were removing.
Device models tested with your actual application setSpecialist teaching and research software is where compatibility problems live. Test before you commit to a model.
Loan and student-issued devices included in the planThese are frequently treated as a separate problem and end up unmanaged.
Disposal and data sanitisation arranged for outgoing devicesOld devices hold institutional data. Sanitisation certificates matter to your information governance team.
Delivery scheduled around the academic calendar, including a peak freezeAgree the no-change windows with faculty before the supplier proposes a schedule.

Section 2

Configuration

What determines whether a device works on arrival.

Autopilot profiles built and tested on each hardware modelProfiles behave differently across models more often than expected. Test each one.
Separate configurations for staff, shared and personal devicesOne configuration across all three is too restrictive for staff and too permissive for labs.
Enrollment Status Page blocks on essential applications onlyA user watching a progress bar for forty minutes on day one generates a support call and a poor impression.
Compliance policy defined with grace periods appropriate to your usersA zero grace period locks out somebody whose device has been in a basement or off campus.
Assessment and exam configurations built and verified in advanceA policy applying for the first time on the morning of an exam is a crisis with no good outcome.

Section 3

Migration and data

The part users experience directly.

User data migration path defined and tested end to endIncluding somebody with a large local profile and somebody who has never used OneDrive.
OneDrive known folder move enabled and verified before the refreshDo this first. It converts a data migration problem into a sign-in.
Application licensing checked for reassignment to new devicesSome specialist software is licensed per device and needs deliberate reassignment.
A rollback path exists for a user whose device does not workSomebody will be blocked on day one. Decide in advance whether they get their old device back.
Timing measured: sealed box to productive, on the actual modelIf the answer is measured in days rather than hours, the provisioning process is the constraint, not the budget.

Section 4

People and support

Where a technically sound refresh still goes wrong.

Communications sent to users with dates and what to expectIncluding what they need to do beforehand. Most refresh support calls are avoidable with better notice.
Support capacity increased for the fortnight around each waveRefresh weeks generate several times the normal ticket volume, predictably.
A pilot completed with a real department, including a difficult caseThe design lab with specialist software, the lecturer who travels, the shared workstation with poor signal.
Staff trained on anything that has genuinely changedIf sign-in, printing or file locations have changed, say so explicitly rather than hoping people adapt.
Success measured against something, not merely completedProvisioning time, first-week ticket volume, and the proportion of devices compliant within 24 hours.

What your score means

Read this against the number above

These bands are deliberately blunt. The middle band is where most organizations honestly sit, and it is a perfectly reasonable place to proceed from — provided the gaps are written down with owners rather than carried as optimism.

0–59%Significant gaps

Do not proceed yet. More than four in ten items are unaddressed, and the ones that fail here are usually the foundational ones that make everything after them harder.

60–84%Mostly ready, with known gaps

Proceed on a defined scope, with the outstanding items written into the plan as risks with owners and dates. This is the most common honest position.

85–100%Ready

The remaining gaps are small enough to handle during delivery rather than before it. Confirm the unticked items are genuinely minor rather than simply unexamined.

Your score highlights automatically as you tick items above. Nothing is saved, sent or tracked — refreshing the page clears it.

Closing the gaps

If you could not tick these, start here

The four items below are the ones whose absence causes the most trouble downstream. If your unticked items include any of these, they are worth addressing before the rest.

Supplier not registering devices

Ask them. Most can, and it removes the single largest manual step in the whole programme.

One configuration for all populations

Split it before rollout. Retrofitting separate configurations across a deployed estate is considerably more work.

Exam configuration untested

Verify it on the actual hardware in the actual room before the assessment window. This is not a risk worth carrying.

No pilot with a difficult case

A pilot of cooperative office staff proves the configuration works under ideal conditions, which is not the question.

Want a second opinion on your score?

Give us one hardware model and your application list and we will build and test the Autopilot profile, then run the pilot with your most demanding department.

Talk through your result Read the related guides We reply to every message within one business day.

Keep going

Related checklists

d365-sales

educationReadiness

Enrolment cycle readiness checklist

Twenty checks before a recruitment cycle opens, covering data, communication and the melt window most institutions leave unmanaged.

January 31, 2026 · 20 checksOpen

sharepoint

educationReadiness

Student records and information architecture audit

Twenty checks on whether student information is organised, protected and findable across a federated institution.

January 17, 2026 · 20 checksOpen

fabric

educationReadiness

Student data platform readiness

Twenty checks before building an institutional data platform, covering governance, access and whether anybody will act on the output.

November 8, 2025 · 20 checksOpen

What this checklist is for

Run it with

And with

And with

20 checks, in the order we would run them

Procurement and registration

Configuration

Migration and data

People and support

Read this against the number above

If you could not tick these, start here

Supplier not registering devices

One configuration for all populations

Exam configuration untested

No pilot with a difficult case

Want a second opinion on your score?

Related checklists

Enrolment cycle readiness checklist

Student records and information architecture audit

Student data platform readiness

Tell us what you're trying to fix

Let’s get started on something great

Phone

Email