Self-Hosted Email vs Microsoft 365 for a Small IT Team

For a small infrastructure team, self-hosted email is not just Postfix and storage. The decision must include identity, calendars, outside collaboration, spam handling, retention, recovery, user support, and the engineering work displaced by operating all of it.

The old stack was capable

The company had a real self-hosted environment: Postfix delivered mail, Dovecot served mailboxes, SpamAssassin filtered messages, and LDAP supplied identity. Nextcloud and OnlyOffice handled shared files and browser-based documents. Mattermost covered chat. Jitsi handled meetings. Some people also had full Microsoft Office because spreadsheets and document compatibility still mattered.

None of those products failed in a dramatic, movie-plot way. Mail arrived. Files opened. Chat worked. Meetings happened. That is exactly why the decision took time. Replacing a broken service is easy to explain. Replacing a collection of working services requires an honest account of the labor between them.

The problem lived in the joins. A mailbox, calendar, meeting link, chat account, shared document, external guest, desktop application, and password were not one workflow. Every seam became a support question, an onboarding step, or a small exception that somebody had to remember.

Two people were carrying the hidden invoice

The infrastructure team was two people. The user population was about 150. Mail was only one responsibility among physical and virtual servers, the network, deployments, monitoring, incidents, backups, and the applications the business actually used.

A self-hosted service does not send an invoice for the interrupted afternoon. Its costs arrive as certificate renewals, storage growth, spam tuning, mailbox repair, client configuration, upgrade planning, failed jobs, account changes, and the knowledge that only one or two people understand the whole path. Each task can look small while the queue as a whole becomes expensive.

I did not have a clean time ledger for every month, so I will not invent one now. I can say that mail and collaboration repeatedly competed with infrastructure work that could not be delegated. That was the cost signal that mattered.

Calendar and outside collaboration changed the argument

Email delivery was not the strongest reason to move. Calendar behavior, meeting invitations, shared documents, and collaboration with outside organizations made the fragmented stack harder to defend.

People could use the individual tools, but ordinary tasks crossed product boundaries. A meeting could begin in mail, turn into a calendar event, require a video link, produce a chat thread, and end with a document shared to somebody outside the company. The old stack made those transitions visible to the user and support team.

Microsoft 365 put Exchange Online, Teams, Office applications, and Entra-backed identity on a path that customers and partners already recognized. In this environment, Teams replaced licensed Mattermost and Jitsi. That consolidation was not philosophically pure. It was useful.

The authentication boundary mattered

I wanted a stronger sign-in boundary than the existing Dovecot client setup provided. That statement is scoped to the deployment I operated; it is not a claim that every self-hosted mail system lacks modern authentication.

Microsoft documents Exchange Online as a hosted messaging service integrated with Microsoft Entra ID. Microsoft also documents tenant security defaults that require multifactor registration, require stronger authentication for administrators, and block legacy authentication paths. Exact controls depend on tenant configuration and licensing, but identity, mail, and administrative policy are designed to meet in one control plane.

That was materially easier to reason about than adding another layer to a mail stack whose clients, protocols, and support history had accumulated over time.

Changing the MX record was a milestone, not the finish line

The mail cutover is complete. The broader migration and administrative handoff are still work.

An MX change directs new mail toward the new service. Historical mail, aliases, application senders, shared mailboxes, mobile devices, and user sign-in still needed separate checks.

Microsoft’s migration documentation treats IMAP moves as batches with status, statistics, synchronization, and errors. It recommends deleting a migration batch only after mailbox data has been verified and mail is routing directly to Microsoft 365. That matches the practical lesson from this cutover: DNS is visible, but verification is the job.

The checklist that mattered included:

• inventorying mailboxes, aliases, shared addresses, forwarders, and application senders;
• creating identities and assigning the intended licenses;
• moving historical mail in controlled batches and reviewing failures;
• changing DNS records and verifying inbound and outbound delivery;
• testing calendar invitations, mobile clients, shared mailboxes, and outside recipients;
• retiring old paths only after logs and user reports stopped finding dependencies; and
• moving routine account administration to the support team with written boundaries.

The spam workload changed, but I did not run a benchmark

The amount of spam and phishing work reaching the infrastructure queue fell substantially after the move. That is an operating observation, not a measured detection-rate comparison. I did not preserve matched message sets, false-positive counts, or controlled before-and-after data.

I am comfortable saying the queue got quieter. I am not comfortable turning that into a percentage or claiming that one filter universally catches more than another. Tenant policy, licensing, sender population, and user behavior all affect the result.

Administration moved; it did not disappear

The old stack concentrated knowledge in Linux and systems administration. The new service makes more routine work accessible to the support team, but the handoff has been bumpy. A different interface does not create judgment.

Somebody still has to own account lifecycle, privileged roles, license assignment, shared mailboxes, retention, mail flow, recovery, support escalation, and the applications that depend on identity. LDAP-to-Entra application migration is also a separate body of work. A mailbox cutover does not modernize every sign-in path behind it.

This is the part a sales comparison tends to hide. Managed software reduces some kinds of operations and creates a new administrative surface. The decision is whether that new surface fits the people who can realistically operate it.

Backup and retention still need an owner

A managed service is not permission to stop thinking about recovery. Microsoft’s documentation separates ordinary service retention from Microsoft 365 Backup policies and recovery windows. A restore also changes live tenant data, which means recovery needs authorization, scope, and verification.

I still want written answers for accidental deletion, malicious deletion, account compromise, legal retention, recovery time, restore authority, and service exit. The platform can supply mechanisms. It cannot decide the company’s tolerance for loss.

The money decision is not a public dollar figure

I have not published the tenant’s license mix, contract pricing, storage profile, or internal labor cost. Quoting a retail per-user price would create false precision because the comparison included mail, chat, meetings, office applications, identity work, support, migration, backup, and the retirement of existing licenses and servers.

I would not tell another organization to buy Microsoft 365 from this account alone. I would ask for the exact license quote, list every service that can actually be retired, estimate monthly operator hours, price migration and coexistence, and name the person who will administer the result. If the old services remain running indefinitely, consolidation savings never arrive.

For this two-person infrastructure team and roughly 150 users, the move was justified. That is a conclusion about a specific operating shape, not a universal verdict on self-hosting.

Use the worksheet before choosing a product

I rebuilt the companion self-hosting decision worksheet around the questions that decided this migration: user workflows, operator time, identity, recovery, handoff, migration milestones, and the services that can truly be retired. It is deliberately not a scored product ranking.

The worksheet is useful even if the answer is to keep the current service. A service with a clear owner, tested recovery, bounded access, and manageable monthly work may be worth operating. A service that survives only because one person remembers its exceptions is already asking for a decision.

What I can still verify

Current product behavior is checked against Microsoft’s official Exchange Online service description, migration batch documentation, Entra security defaults, and Microsoft 365 Backup security and recovery documentation.

The service list, team size, approximate user count, completed mail cutover, ongoing identity work, administrative handoff, and spam-workload observation come from the environment I helped operate. I did not disclose the employer, inspect the tenant for this article, publish license or labor costs, measure filter accuracy, or test Microsoft’s backup product.