Business productivity & collaboration software

The licence decision and the migration are separate purchases

Most disappointing productivity rollouts fail on the second purchase, not the first. The licence is a commercial choice: which edition, which commitment, which users are named. The migration is an operational project: moving mail, files, permissions, calendars and identities without losing anything, and getting people to change habits. They are usually quoted together, which is exactly why they should be separated before you compare anything. Ask what the licence entitles each user to do, then ask separately who performs the migration, what the cutover looks like hour by hour, what happens to mail sent during the transition, and who supports users in the week afterwards. A proposal that cannot describe the transition in that much detail has priced a licence and hoped for the rest.

• Licence: edition, commitment, and who is a named user.
• Migration: mail, files, permissions, calendars, identities.
• Cutover: what happens to messages sent during the move.
• Aftercare: who supports users in the following week.

Size the licence from roles, not from headcount

A headcount is not a licence count. The same organisation usually contains full desktop users who need every application, frontline or shift staff who need mail and chat on a shared device, contractors with a defined end date, guests who need meeting access only, service accounts that send mail but are not people, and a small number of administrators whose roles carry higher requirements. Editions differ mainly in what they permit and enforce, so map each group to the capability it actually needs before deciding. Where a platform offers concurrent rather than named licensing, the arithmetic is worth doing: three shifts sharing a smaller number of licences works only while the shifts genuinely do not overlap, and the peak simultaneous count, not the total staff list, is the number that matters.

• Full desktop users, frontline and shift staff, contractors, guests.
• Service accounts and shared mailboxes, which are not people.
• Administrative roles, which carry separate requirements.
• For concurrent licensing, the peak simultaneous count rather than the total.

Mail and file migration is where projects fail

The visible parts of a migration — the new address book, the new app on a phone — are the easy parts. What determines whether the project holds is the invisible estate: shared mailboxes that a team reads but nobody owns, distribution lists that only one person remembers creating, calendar delegates, mail flow rules, signature templates, retention holds, and the file permissions that grew over a decade of ad hoc sharing. Those need to be inventoried and mapped before anything moves, because they are the reason a migration appears to succeed and then quietly erodes. Ask how permissions are translated when the folder structure changes, whether old mailboxes stay readable during a parallel period, and how a user's deleted items and archive are treated. Then agree how long the old system remains available read-only after cutover.

• Shared mailboxes, distribution lists and calendar delegates inventoried.
• Mail flow rules, signature templates and retention holds mapped.
• How folder permissions translate when the structure changes.
• How long the old platform stays readable after cutover.

Identity, domains and the tenant you own

Productivity suites are identity systems with a word processor attached, so the identity decisions outlive the software decision. Three of them matter in the first week. Who owns the domain registration, and are the DNS records that prove ownership held under an account your business controls? Who holds the tenant administrator role, and is there more than one human who can act if the primary administrator is unavailable? How is authentication enforced, at what assurance level, and does it apply to administrators as well as everyone else? NIST's guidance on authenticator assurance and on multifactor authentication points the same way: the control that decides most outcomes is how a person proves who they are, not which edition of the suite they hold.

• Domain registration and DNS proof-of-ownership under your own account.
• At least two human tenant administrators the business controls.
• Multifactor authentication enforced for administrators as well as users.
• A documented process for provisioning and removing access.

Retention, export and the route out

Retention is a business decision about how long records must exist, and it should be made before the migration rather than discovered during it, because the settings applied during a move tend to become the settings you live with. Decide what must be kept, for how long, and who may delete it; then check that the platform's retention capabilities can express that policy. Ask the same question about departures: when a user leaves, what happens to their mailbox, their files, their chat history and their delegated access, and how long it stays recoverable. The last question is the one vendors answer least readily. If the business changed platform in two years, what exactly would you receive, in what format, and how would it be produced?

• Retention policy decided before the migration, not after it.
• What happens to a departing user's mail, files and chat history.
• How long deleted content stays recoverable, and who can restore it.
• The export you would receive if you changed platform.

What to gather before asking for pricing

Requests for productivity software are quoted faster and more accurately when the counts arrive with them. Bring a user list grouped by role and work pattern, the current mail and file platforms with rough data volumes, the business applications that depend on identity or calendar integration, any retention or sector obligation that applies, and the date by which the change has to be complete. Add the constraints that are easy to forget: whether email addresses must stay the same, whether any system sends mail on the organisation's behalf, whether staff use personal devices, and whether anyone works in a location with poor connectivity. Those details change the shape of the project more than the edition choice does.

• Users grouped by role and work pattern, not a single total.
• Current platforms and rough mailbox and file volumes.
• Applications that depend on identity or calendar integration.
• Any obligation that sets a retention or residency requirement.

Frontline and shared devices are a licence decision, not an edition question

The people who do not need a desktop licence are often the largest group and the easiest to misprice. Microsoft's frontline plans, F1 and F3, are aimed at that population, and the vendor's stated eligibility is concrete: a worker qualifies where their primary device has a single screen smaller than 10.9 inches, or where they share a primary work device with other licensed frontline workers during or across shifts. Shared-device setups are supported through Entra's shared-device mode on managed Android, iOS and iPadOS hardware, and the rule that catches people out is that software accessed from a shared device still has to be covered by the relevant user or device licence. Assign by tier through groups rather than one licence at a time — a separate group for each plan and each add-on — so that adding a person grants the entitlement and removing them returns it. The front desk, the shop floor and the ward share a work pattern; they do not necessarily share a plan.

• Frontline eligibility turns on the device: a single screen under 10.9 inches, or a shared primary device across shifts.
• Shared-device mode covers the shared mobile device, not the software running on it.
• Applications on a shared device still need a user or device licence covering them.
• One group per tier and per add-on, so a leaver returns the licence automatically.

Add-ons ride on a base licence, and some capacity is pooled

A licence count is rarely one number, because the products that attract attention are usually add-ons. Microsoft 365 Copilot is the clearest example: it is an add-on rather than a replacement, so each user needs an eligible base subscription plus the Copilot licence, and the eligible-plan list changes — verify it at the point of purchase rather than at the point of design. Assign the add-on through its own Entra group so the base and the addition can be revoked independently. Capacity models work differently again: Windows 365 Frontline is sold as pooled capacity at the tenant level rather than assigned to named users, providing either several individual Cloud PCs used non-concurrently or a single shared one, and it depends on entitlements that some base plans already include. When a vendor offers both a per-user add-on and a pooled capacity model, the question is not which is cheaper but which counting rule matches how the work is actually done during a shift.

• Copilot is an add-on: an eligible base subscription plus the add-on, per user.
• Verify the current eligible base plans at purchase; the list moves.
• Assign add-ons through their own group so they can be revoked separately.
• Pooled capacity is counted at the tenant, not per named user.

A downgrade is a licence change, not a data migration

Moving a user down a tier looks administrative and behaves like a data event. The lower plan does not carry every service, feature and storage allowance the higher one did, and there is no general guarantee that the data survives the change in usable form: depending on the workload, content may stay in place, become inaccessible, enter a restricted state, or be deleted after a retention period. The affected areas are predictable enough to check first — mailbox size and archive, file storage and sharing, meeting and chat features, retention and e-discovery settings, and the security controls the higher plan enforced. Export or migrate anything the lower plan cannot hold before the change, not after it, and treat the move as asymmetric: going up is usually immediate, while going down can be restricted by the term and the data may not follow. What a user can still reach after the downgrade is worth confirming in writing, because the answer is workload-specific.

• Confirm what the lower tier no longer includes before the move.
• No general promise that data survives a downgrade in usable form.
• Inventory mailbox, archive, file storage, retention and security settings first.
• Export what the lower plan cannot retain; do not discover it afterwards.
• Going up is usually immediate; going down can be restricted by the term.

PUT THE OPTIONS SIDE BY SIDE

Your comparison checklist

Common questions