Why do Microsoft 365 migrations go wrong for field staff when the office cutover went fine?

Because the office cutover is validated by proximity. When an office user cannot sign in, they raise a hand and someone walks over — the failure is detected and fixed inside a minute, and it never becomes a ticket or a data point. A field user on a jobsite has none of that. Their failure is detected only when they call, and they usually call late, from a place with poor coverage, at the start of a shift when they need the file immediately. The same failure rate that looks like nothing in the office looks like a stalled migration in the field, because the detection loop and the repair loop are both far slower.

How do you re-authenticate a field worker who has no reliable cell signal on site?

You move the sign-in to a place and time where coverage exists, rather than hoping the site cooperates. In practice that means completing first sign-in at the yard, the shop, the trailer office or wherever the crew gathers before dispatch, with someone present who can fix it on the spot; issuing a Temporary Access Pass in Entra ID so a user who cannot complete a normal MFA prompt can still get in and register a method; and having a fallback second factor for people whose phone is the problem, such as a FIDO2 security key that needs no signal at all. What does not work is scheduling the cutover for a weekend and expecting the crew to sort themselves out on Monday from a basement.

Should field users be in the first migration wave?

No, and they should not be in the last one either. The first wave exists to find defects, and it needs users who are physically reachable and articulate about what broke — that is an office and IT population, not a crew scattered across active sites. But leaving field users to the final wave is worse: their problems then land during the tail of the project when the engineering attention, the vendor support window and the change-freeze tolerance have all been spent, and there is no room left to reschedule around weather or a crew rotation. Field users belong in the middle waves, sequenced by crew rather than by department, after the defects are known and while there is still slack in the plan.

What breaks offline for a field user who has not signed in since a Microsoft 365 cutover?

The things that depend on a valid token and a primed local cache. Files that were left as online-only placeholders will not open without connectivity. A mail profile that has not synced since the change may have little or nothing cached. Collaboration apps generally show recent content offline but cannot fetch anything new. And a device whose cached credentials no longer match the identity it is being asked to present will simply refuse, with an error message that reads as a network problem. For a foreman opening a drawing set at the start of a shift, the practical answer is to pin what the crew needs to the device before the cutover, verify it opens with the network switched off, and keep a non-digital fallback for the first shift after the change.

How do you handle shared jobsite tablets with no single owner during a migration?

First, find them, because they are usually missing from the asset list — the reconciliation that works is against the project roster and the payroll run rather than the purchasing record. Then give each one an owner for the duration of the project, even if the device stays shared in daily use; a device with no named person attached has nobody to re-authenticate it and nobody to call when it fails. Where the device genuinely rotates among staff, a shared-device configuration in Intune is the right pattern, because it keeps sign-in and sign-out as the boundary between users instead of one saved account everyone borrows. The trailer-office tablet with a password four people know is the most common finding on a first assessment, and a migration is the moment it stops working.

What happens to subcontractor and temporary crew accounts when the crew changes between project phases?

Unless the process is anchored to something that moves on its own, they accumulate. Construction and trades work rotates people between phases and between projects faster than most industries, and the identity model usually lags — accounts for people who left, guest invitations for design partners on projects that closed, shared logins nobody can attribute. The pattern that holds is a joiner, mover and leaver flow tied to the payroll run rather than to somebody remembering, plus an expiry date attached to every guest invitation at the moment it is granted. A migration makes this urgent rather than merely untidy, because every one of those accounts is a licence, a re-authentication, and a decision someone has to make during the cutover window.

Field notes · 11 min read · August 19, 2026

Microsoft 365 migration with a field-mobile workforce

The field half of a Microsoft 365 migration is scheduled by crew rotation, weather and cell coverage — none of which appear on the project plan.

Someone has told you the Microsoft 365 migration is mostly done. The head office moved, the accounting team moved, the shared drives are in SharePoint, and the project is being talked about in the past tense. Then a superintendent calls from a site at 6am because the drawing set will not open, and it becomes clear that the migration is not mostly done — it is half done, and the remaining half is the half that does not sit at a desk.

This is the pattern we see across construction and trades environments: a plan that is engineered for the office and inherited by the field. The technical work is usually fine. What is missing is that a field-mobile workforce changes the shape of a migration — the devices, the timing, the failure modes and the order you move people in are all different, and none of those differences show up in a standard cutover runbook.

The one-sentence version: the office half of a Microsoft 365 migration is validated by proximity — someone walks over and fixes it — and the field half has no proximity, so every assumption that depends on being able to reach a user in person has to be replaced with something else before you cut over.

The device population you are actually migrating

Start by admitting what the estate really contains, because the asset register almost never does. A field-mobile firm typically has four device classes and only one of them behaves like an office laptop.

Personally-owned phones and tablets. Frequently the largest population, frequently undocumented, and the primary way most field staff touch company mail and files. You did not buy it, you cannot inventory it, and its owner has a reasonable objection to you wiping it.
Shared site devices with no single owner. The tablet in the trailer, the handheld that lives on a specific piece of equipment, the laptop three people use for the same task. Nobody's name is on it, so nobody notices when it stops working until the day it is needed.
Rugged hardware on long refresh cycles. Field-hardened devices are expensive and are kept for years by design. That is a sound procurement decision and a migration problem: older operating systems, older client applications, and enrolment or management agents several versions behind whatever your pilot tested on.
Machines that live in a truck. Rarely on the corporate network, rarely restarted, patched whenever they happen to be online long enough. These are the devices where a policy you pushed three weeks ago may still not have applied, and where you will discover it at cutover.

The consequence is that "we tested the client on a current build" is not a statement about your field estate. Test on the oldest rugged device still in service and on a personally-owned phone that has never been enrolled. Those two results tell you more about your cutover than the pilot does.

Re-authentication is the migration event nobody schedules

This is the section worth reading twice, because it is the largest single scheduling risk in a field-mobile migration and it is almost never on the plan as its own line.

Several ordinary migration activities force every affected user to sign in again, from scratch, on every device they use. Moving to a different tenant is the extreme case — the account itself is new, so nothing cached is valid. But enforcing MFA for the first time, introducing a Conditional Access baseline, or making any change that invalidates existing refresh tokens produces the same practical effect: a population of people, all at once, being asked to prove who they are.

In the office this is invisible. Someone gets a prompt, approves it, and carries on; the handful who fail raise a hand and are fixed before it becomes a ticket. The failure rate is the same in the field. Everything else about it is different:

You cannot walk to the desk. Detection depends on the user calling you, and they call when the thing they needed is already blocking work — typically at the start of a shift, which is the worst possible moment to start a troubleshooting session.
The second factor is often the thing that is broken. The authenticator app is registered to an identity that no longer exists, or is on a phone the user replaced, or was never set up because that person was hired between the readiness assessment and the cutover. Registering a new method requires connectivity at exactly the moment they may not have it.
Some users have no usable phone at all. A device policy that assumes everyone carries a smartphone they are willing to install a company app on will fail for a real fraction of a trades workforce, and that conversation is a labour-relations one as much as a technical one.
Shared devices have no one to prompt. A sign-in challenge on a device with no named owner goes to nobody. It sits there until someone picks the device up and finds it locked.

The failures are not exotic. What makes them expensive is that each one takes a phone call, a person who can hear you, and enough signal to complete the fix — and they all arrive in the same two hours.

What to do about it

Treat re-authentication as a scheduled workstream with its own owner, not as a consequence of the cutover. Concretely:

Pre-register second factors before the change, not during it. Every method that can be registered while the old identity still works is one fewer live failure. Audit who has a registered method and who does not, and treat the gap as a blocking item rather than a reporting line.
Have a bypass ready that does not need the phone. A Temporary Access Pass in Entra ID lets a user who cannot complete a normal prompt sign in once and register a method. A FIDO2 security key works with no signal and no phone at all — a small stock of them is a cheap answer for the people your standard method does not fit.
Do first sign-in where the crew already gathers. The yard, the shop, the trailer before dispatch. Put a person there for the first two mornings of each wave. Fixing it on the spot in the yard is not the same job as fixing it over the phone from a site.
Do not stack identity changes. An MFA rollout and a tenant move in the same window means you cannot tell which one broke a given user, and the remediation for each is different. Separate them, and let the first one settle before the second.
Give the field a route that is not the ticket queue. A named phone number answered by someone who can issue a pass and reset a method, not a portal that requires the sign-in the user does not have.

The identity groundwork underneath this — the Conditional Access baseline, the hybrid identity model, the method policy — is the work described on our Entra ID and hybrid identity page. When the destination is a different tenant entirely, the re-authentication problem is at its largest and its sequencing is covered in the tenant-to-tenant migration playbook.

Intermittent connectivity is a scheduling constraint, not a support ticket

Jobsite connectivity is not uniformly bad — it is unpredictably bad. Good coverage at the gate, none in the basement, none behind steel, none on the rural site until the modem is up. Planning for "some bandwidth" is fine. Planning for "bandwidth at a specific hour in a specific place" is what fails.

First sign-in after a migration is the heaviest network moment in the whole user experience. Tokens are acquired, policy is fetched and applied, a mail profile may rebuild, and file sync starts from a cold cache. That is a long, chatty operation, and it is exactly the operation you have scheduled for a person standing in a place with one bar. It does not fail cleanly either: a partial first sync leaves the user with an application that opens but has nothing in it, which reads to them as data loss.

So put first login somewhere with coverage and enough time — before dispatch, not at the site — and make that an explicit instruction rather than an assumption. Where crews go somewhere with no coverage for days, sequence those crews into a wave that starts on a day they are in the yard. That is a scheduling decision made with the project manager, which is why field waves cannot be planned from the IT calendar alone.

Who is actually holding the device

A migration plan implicitly assumes that every device maps to an employee who will still be there next week. Construction rotates people between phases and between projects far faster than that assumption survives.

Subcontractor staff hold guest identities and sometimes company devices. Temporary crews arrive for one phase. A crew that was on site during the readiness assessment may be entirely different by the wave that moves them. Each of those is an account to migrate or not migrate, a licence to assign or not assign, and a person to re-authenticate or to remove — decisions someone has to make inside the cutover window, usually at speed.

Two things make this tractable. First, reconcile the device and account inventory against the project roster and the payroll run rather than against the purchasing record, because those are the lists that reflect who is actually here. Second, anchor the joiner, mover and leaver process to that same payroll signal, and attach an expiry to every guest invitation at the moment it is granted. A migration is the point at which an identity model that relies on somebody remembering stops being untidy and starts being the reason the cutover slipped. That is the same identity work described on the construction and trades page, and it is worth doing before the migration rather than during it.

Offline and cached access — what a foreman needs at 6am

The practical test of a field migration is narrow and specific: at the start of a shift, on a site with one bar, can the person running that crew open the current drawing set, the day's plan, the safety documents and the contact list? If the answer is yes, the migration is working for them regardless of what else moved. If the answer is no, nothing else you did that week matters to them.

The failures cluster in a few places. Files left as online-only placeholders look present in the file list and will not open without connectivity. A mail profile that has not synced since the change has little cached, so the user sees an empty mailbox and reports it as lost mail. Collaboration apps show what they last held and cannot fetch anything new, which is fine if the crew knows it and alarming if they do not. And a device presenting credentials that no longer match the identity it is being asked for fails with an error that reads like a network problem, so the user tries again in a different corner of the site instead of calling you.

The mitigations are unglamorous and they work: pin the folders each crew actually needs so they are held on the device rather than fetched, let the cache prime fully before the user leaves coverage, verify the whole set opens with the network switched off, and keep a non-digital fallback for the first shift after each wave. A printed set nobody needed is a cheap insurance policy. A crew standing around at 6am is not.

Sequencing: not the first wave, not the last

Field users should not be in the first wave. The first wave exists to find defects, and finding defects requires users you can reach, watch and debrief. That is an IT and office population. Putting a crew in the pilot means discovering your unknowns by phone, from a site, at the worst hour of the day.

Field users should also not be in the last wave, which is the more common mistake because it feels cautious. By the final wave the engineering attention has moved on, the hypercare window is closing, the change-freeze tolerance is spent, and there is no slack left to reschedule around weather, an inspection, or a crew that turns out to be off-grid that week. Field problems arriving at that point have nowhere to go.

Put field users in the middle waves — after the defect list is known and while there is still room in the plan. Sequence them by crew rather than by department, because a crew is the unit that shares devices, shares a schedule and shares a site, and moving half of one is how you end up supporting two versions of everything on the same job. This is the sequencing logic we apply on Microsoft 365 migration engagements generally, and when the move is between tenants it matters more, not less — see tenant-to-tenant migration.

BYOD without a full management stack

Most field-mobile firms are not going to enrol every personal phone, and pretending otherwise produces a policy nobody follows. The useful question is what you can enforce on a device you do not own, and the honest answer has a clear boundary.

What you can do without enrolling the device: apply app protection policies to the Microsoft apps so corporate data inside them is encrypted and requires a PIN; block copy, paste and save-as out of those apps into unmanaged ones; wipe only the corporate data when someone leaves; and use Conditional Access to require an approved client app or a compliant device before company data is released at all, and to block download to unmanaged browsers.

What you cannot do: inventory the device, guarantee its operating-system patch level, control what else is installed on it, or wipe the phone. And no technical control stops someone photographing a drawing on a screen — that is a policy and culture question, not a configuration one.

That boundary is often the right trade for a field workforce. What makes it fail is leaving it implicit. Decide which data classes are allowed on unmanaged devices, decide what the company-owned option is for the people who will not enrol a personal phone, write both down, and say it out loud before the migration rather than during the first incident. Enrolment consent on a personal device is a conversation with people, not a checkbox.

The 30-second version

The office half of a Microsoft 365 migration is easy because it is validated by proximity. The field half has none, so every assumption that depends on reaching a user in person needs replacing before cutover. Inventory the real device population — personal phones, ownerless shared tablets, rugged hardware several versions behind your pilot, and machines that live in a truck. Treat re-authentication as its own scheduled workstream: pre-register second factors, keep a Temporary Access Pass and a signal-free key in reserve, do first sign-in in the yard, and never stack an MFA change on top of a tenant move. Sequence around connectivity rather than hoping for it, tie the account inventory to the project roster and the payroll run rather than the asset sheet, pin what a foreman needs at 6am so it opens offline, and put field users in the middle waves — never first, never last. Then decide explicitly what you can and cannot enforce on a phone you do not own, and say so before someone finds out the hard way.

Questions we get asked

Why do Microsoft 365 migrations go wrong for field staff when the office cutover went fine?: Because the office cutover is validated by proximity. When an office user cannot sign in, they raise a hand and someone walks over — the failure is detected and fixed inside a minute, and it never becomes a ticket or a data point. A field user on a jobsite has none of that. Their failure is detected only when they call, and they usually call late, from a place with poor coverage, at the start of a shift when they need the file immediately. The same failure rate that looks like nothing in the office looks like a stalled migration in the field, because the detection loop and the repair loop are both far slower.
What is the re-authentication event in a Microsoft 365 migration, and why does it hit field workers hardest?: Any change to the identity a user signs in with, or to the policy that governs that sign-in, forces every affected user to authenticate again from scratch on every device they use. A tenant-to-tenant move is the extreme version — the account itself is new — but a first MFA enforcement, a new Conditional Access baseline, or a change that invalidates existing refresh tokens produces the same effect. Office users absorb this silently. Field users hit it on a device that may be personally owned, shared, out of date, or out of coverage, with nobody nearby who can help. Re-authentication is the single largest scheduling risk in a field-mobile migration, and it is almost never on the plan as its own line item.
How do you re-authenticate a field worker who has no reliable cell signal on site?: You move the sign-in to a place and time where coverage exists, rather than hoping the site cooperates. In practice that means completing first sign-in at the yard, the shop, the trailer office or wherever the crew gathers before dispatch, with someone present who can fix it on the spot; issuing a Temporary Access Pass in Entra ID so a user who cannot complete a normal MFA prompt can still get in and register a method; and having a fallback second factor for people whose phone is the problem, such as a FIDO2 security key that needs no signal at all. What does not work is scheduling the cutover for a weekend and expecting the crew to sort themselves out on Monday from a basement.
Should field users be in the first migration wave?: No, and they should not be in the last one either. The first wave exists to find defects, and it needs users who are physically reachable and articulate about what broke — that is an office and IT population, not a crew scattered across active sites. But leaving field users to the final wave is worse: their problems then land during the tail of the project when the engineering attention, the vendor support window and the change-freeze tolerance have all been spent, and there is no room left to reschedule around weather or a crew rotation. Field users belong in the middle waves, sequenced by crew rather than by department, after the defects are known and while there is still slack in the plan.
Can you enforce security on a personally-owned phone without enrolling it in Intune?: Partly, and the boundary is worth being precise about. Without device enrolment you can still apply app protection policies to the Microsoft apps — requiring a PIN on the app, encrypting the app's data, blocking copy-and-paste and save-as into unmanaged apps, and wiping only the corporate data on demand. You can use Conditional Access to require an approved client app or a compliant device before company data is released, and to block download to unmanaged browsers. What you cannot do is inventory the device, guarantee its operating-system patch level, control what else is installed, or wipe the phone. You are protecting a container of corporate data on someone else's hardware — which is often the right trade in a field workforce, but it should be a stated decision rather than an assumption.
What breaks offline for a field user who has not signed in since a Microsoft 365 cutover?: The things that depend on a valid token and a primed local cache. Files that were left as online-only placeholders will not open without connectivity. A mail profile that has not synced since the change may have little or nothing cached. Collaboration apps generally show recent content offline but cannot fetch anything new. And a device whose cached credentials no longer match the identity it is being asked to present will simply refuse, with an error message that reads as a network problem. For a foreman opening a drawing set at the start of a shift, the practical answer is to pin what the crew needs to the device before the cutover, verify it opens with the network switched off, and keep a non-digital fallback for the first shift after the change.
How do you handle shared jobsite tablets with no single owner during a migration?: First, find them, because they are usually missing from the asset list — the reconciliation that works is against the project roster and the payroll run rather than the purchasing record. Then give each one an owner for the duration of the project, even if the device stays shared in daily use; a device with no named person attached has nobody to re-authenticate it and nobody to call when it fails. Where the device genuinely rotates among staff, a shared-device configuration in Intune is the right pattern, because it keeps sign-in and sign-out as the boundary between users instead of one saved account everyone borrows. The trailer-office tablet with a password four people know is the most common finding on a first assessment, and a migration is the moment it stops working.
What happens to subcontractor and temporary crew accounts when the crew changes between project phases?: Unless the process is anchored to something that moves on its own, they accumulate. Construction and trades work rotates people between phases and between projects faster than most industries, and the identity model usually lags — accounts for people who left, guest invitations for design partners on projects that closed, shared logins nobody can attribute. The pattern that holds is a joiner, mover and leaver flow tied to the payroll run rather than to somebody remembering, plus an expiry date attached to every guest invitation at the moment it is granted. A migration makes this urgent rather than merely untidy, because every one of those accounts is a licence, a re-authentication, and a decision someone has to make during the cutover window.

Related service

Construction and trades IT

Written by the team at Pro IT NW · Senior-led Microsoft project consultancy · Seattle / USA-wide.

Share on LinkedIn Follow Pro IT NW