ARTICLE

From on-premise Exchange to Microsoft 365: a practical guide

ILS Networks August 26, 2026 An 8-part guide

Support for Exchange Server 2016 and 2019 has ended. This guide covers what happens after that decision: how to choose a migration method, what to measure first, what actually breaks, and what a rollback looks like when something goes wrong.

Most Israeli IT managers are no longer debating whether to move to Microsoft 365. They are stuck mid-decision on how: which migration method, which licensing, what happens to the systems that generate mail, and what to do if mail stops arriving on Monday morning.

This guide is written for exactly that point. It does not argue that the cloud is good — it sets out what to check first, what order to work in, where these projects break, and what can be reversed.

ILS Networks is a Microsoft Cloud Solution Provider and has supported enterprise IT infrastructure in Israel since 2009. At Galmarine we ran this exact move — mail migration from an on-premise Exchange 2019 server to Microsoft 365. At Combe we delivered a full workplace migration including the file layer, alongside preparing the organization to meet information-security requirements set by government institutions.

What is forcing the decision now

Before comparing methods, understand that the clock is already running. This is not a decision that can quietly wait another year:

Support for Exchange Server 2019 and 2016 has ended. In Microsoft’s own words: "Support for Exchange Server 2019 and 2016 ended on October 14, 2025."
The server keeps running — but with no security fixes, no bug fixes, no technical support, and no time-zone updates. On a risk register, that is an unsupported system holding your enterprise mail.
Three legitimate destinations: Microsoft 365, an on-premise upgrade to Exchange Server Subscription Edition, or a combination. Staying on 2016/2019 is not one of them.
Exchange 2019 upgrades in place to SE. Exchange 2016 does not — it goes via Exchange 2019 CU14/CU15, or by joining an SE server into the existing organization.
For Israeli organizations working with government institutions or customers with information-security requirements: an unsupported mail server is an audit finding waiting to happen, not technical debt you can roll forward.
The decision date is not the migration date. Inventory, pilot, and cutover are measured in weeks and months — not in a single weekend.

Inventory before you choose a method

The method follows from the data, not the other way round. These are the numbers that need to be on the table:

Mailbox count, total size, and the largest single mailbox separately. The item size limit for a migration is 150 MB per message.
Shared mailboxes, resource mailboxes (rooms and equipment), and public folder mailboxes counted separately. Public folders are the single most common reason a "simple" migration stops being simple.
Every system that generates mail: ERP, scanners and multifunction printers, monitoring, backup alerting, and line-of-business applications. Record the sending IP, the authentication method, and the daily volume for each.
File servers: total size, file count, deepest path, longest name, largest file — and who actually holds NTFS permissions, not who is supposed to.
Identity: are user accounts mastered in on-premise Active Directory, and is Entra Connect already deployed? The answer decides whether directory synchronization is a requirement or a choice.
The existing DNS zone: MX, the SPF TXT record, autodiscover, DKIM — plus whatever someone added seven years ago that nobody remembers the purpose of.
Archives, journaling policies, and any third-party archiving appliance sitting on the mail path.

Choosing the migration method

Microsoft supports several paths, and the difference between them is mostly how much coexistence you need and what it costs you in complexity:

Cutover — every mailbox in a single batch, with no coexistence and no directory synchronization. Supported up to 2,000 mailboxes, but Microsoft qualifies that it is more reasonable to migrate 150 users or fewer.
Staged — migration in batches; requires directory synchronization. Relevant when the source is an older Exchange version.
Minimal hybrid (express) — a one-time batched move with directory synchronization but no long-term coexistence. The balance point for organizations that need waves but do not need cross-premises free/busy.
Full hybrid — real coexistence: cross-premises free/busy, unified routing, and the only native method that also moves mailboxes back on-premise. Its big practical advantage: the mailbox GUID does not change, so Outlook profiles and OST files survive the move.
IMAP plus PST import — mail only, no calendar, contacts, or tasks. A fallback for non-Exchange sources.
Third-party tooling — earns its licence when you need granular scheduling, repeated delta passes, complex permission mapping, or a source the native tools do not reach.
Microsoft’s own guidance in the decommissioning article: "We strongly recommend consideration of cutover or staged migration for organizations with fewer than 2,000 mailboxes." Hybrid buys coexistence and pays in complexity.
The working rule: pick the simplest method that satisfies the real coexistence requirement — not the most impressive one.

Licensing: match the plan to the workload

Licensing is settled before the pilot, not after — because it determines mailbox size, archive behavior, and therefore what you can move at all:

The Business family (Basic, Standard, Premium) is capped at 300 users per tenant across the whole family. Above that, enterprise plans.
Business Basic and Standard include Exchange Online Plan 1; E3 and E5 include Plan 2. The practical difference: a 50 GB mailbox versus 100 GB, and how archiving behaves.
Not everyone needs the same plan. Enterprise, Business, and standalone plans (for example Exchange Online Plan 1) can be combined within a single tenant.
Shared and resource mailboxes do not need their own licence — but without one they are capped at 50 GB. A shared mailbox holding years of correspondence needs a deliberate decision.
Licensing through a CSP — ILS Networks is a Microsoft Cloud Solution Provider — keeps licensing, tenant, and support with one party, including seat changes and plan moves.
Price the target state, including shared mailboxes, service accounts, and users who left. A migration is the best chance you will get to clean up the user list.

The other half: file servers

Mail gets all the attention, and then the file server sinks the project. This layer has its own rules:

Decide the destination per share, not per server: single-user content goes to OneDrive; team content goes to a SharePoint library or Teams.
Do not copy the folder tree as it stands. Permissions and structure are designed before the move; a 1:1 copy carries the mess across with the data.
What migrates and what does not: files, folder structure, item-level permissions, and metadata migrate. Explicit deny permissions, hidden file attributes, and files over 15 GB do not. Microsoft states it directly: "After migration, all advanced NTFS permissions are removed."
Names and paths: remediate before you migrate. The right fix for a deep folder tree is to split it, not to fight the limit.
Run an assessment scan before moving a single byte — SPMT offers a scan-only mode that produces the findings report.
Pre-provision OneDrive for users before pushing content into it.
Copy incrementally in the background, then run a single cutover event. Leave the old share read-only rather than deleting it.
Throughput is not unlimited: background migration traffic is throttled harder during weekday business hours and runs faster evenings and weekends. Build the schedule around that, not around hope.

What actually breaks: DNS, relay, and limits

Most migration incidents do not happen inside the mailbox move. They happen in the layers around it:

External DNS: one MX record pointing at the tenant, and a single SPF record. Microsoft is unambiguous: "you can only have a single SPF record for your domain." The DNS lookups that record resolves to are capped at 10.
Internal DNS too, not only external: an autodiscover CNAME to autodiscover.outlook.com, and the SCP values removed from the on-premise servers. An old server still publishing an SCP will keep pulling Outlook back to itself.
SMTP relay — this is where most organizations fall over. An Exchange Online mailbox is capped at 30 messages per minute and 10,000 recipients per day. The ERP that fires invoices overnight will meet that limit in week one.
There is also a tenant-level external recipient limit (TERRL) derived from your licence count. Check it in advance if internal distribution is heavy.
Public folders need their own batch migration and their own decision: migrate them, convert them to shared mailboxes, or accept that they justify keeping a server.
Outlook profiles and mobile devices: with any non-hybrid method the profile is rebuilt and devices must reconnect. That is helpdesk load — budget for it.
Shared mailbox permissions, delegate access, and send-as rights do not always survive. Test them explicitly in the pilot, not in production.
Configure DKIM and DMARC after SPF. Microsoft notes that SPF alone does not cover every spoofing technique.

Harden the tenant before the first mailbox moves

A new tenant is an open tenant. Hardening happens before there is data in it, not afterwards:

Multifactor authentication is no longer optional: Microsoft enforces MFA for sign-in to the admin centers, and since October 1, 2025 also for resource-management clients — Azure CLI, PowerShell, SDKs, and the REST API.
Break-glass and emergency access accounts are in scope. The official recommendation is a passkey (FIDO2) or certificate-based authentication — not a password in a safe.
Any script authenticating with a username and password (the ROPC flow) will break. Find those before enforcement finds them for you.
The Entra Connect synchronization service account is not affected by the requirement — one item on the list you can tick without work.
Conditional Access requires Entra ID P1/P2 licensing. Without it, security defaults — which is still far better than nothing.
Access policy, blocking legacy authentication, and named locations are configured while the tenant is empty. That is the difference between a configuration task and a production change.
For organizations working with Israeli government institutions, the hardening and the documentation of it are part of the deliverable, not an appendix. At Combe we prepared the organization for exactly those requirements alongside the migration itself.

Cutover, rollback, and the last on-premise server

The project does not end when the last mailbox moves. It ends when someone has proven everything works and decided what happens to the server left behind:

Pilot group first: the IT team, one business team, one heavy Outlook user, and one user who works only from mobile. That combination surfaces nearly every issue.
The rollback plan for a cutover is DNS: lower the TTL before the cutover, not after, and keep the old MX record ready to restore.
The rollback plan in hybrid is moving a mailbox back on-premise — the only native method that supports that direction.
Once directory synchronization is active, recipient attributes are mastered on-premise. Removing every Exchange server leaves you unable to manage cloud recipients.
Two legitimate exits: turn off directory synchronization and manage everything in the cloud, or keep Entra Connect and keep one (better two) servers for recipient management — upgraded to Exchange Server SE.
What actually keeps the last server alive is usually public folders or SMTP relay. Make that a deliberate decision rather than a discovery.
Before decommissioning: verify inbound and outbound mail flow, free/busy, mobile devices, archive access, delegate permissions — and a real restore from backup.
Then update documentation, monitoring, and runbooks. ILS Networks provides 24/7 support for the environments it manages.

SOURCES

Official sources for the key facts

Every date, limit, and threshold in this article comes from Microsoft’s official documentation. The links are here so you can verify each figure against the source before you make a decision.

What this looks like in practice

Microsoft 365 services Case study: Combe

ABOUT THE AUTHORS

ILS Networks

ILS Networks is a Microsoft Cloud Solution Provider and has supported enterprise IT infrastructure in Israel since 2009 — cloud and mail, networking, information security, and backup — with 24/7 support.

Published: August 26, 2026 · Updated: August 26, 2026