The week after cutover has a particular feeling. Mail flows, calendars work, the old server is quiet, and everyone involved wants to declare victory and move on. It is exactly the moment when a new kind of risk begins, because a Microsoft 365 tenant is not a thing you finish setting up. It is a living environment that Microsoft changes monthly, attackers probe daily, and your own staff reshape every time someone is hired, promoted, or leaves.
Moving off an unpatched Exchange server removes one category of risk. An unmanaged cloud tenant quietly builds up another. Here is what ongoing management actually involves, and why we offer it as the standing follow-on to every migration we run.
The tenant you migrated into is not the tenant you will have in a year
During a migration, the tenant is configured deliberately: limits set, domains verified, mail flow tested. Then normal life resumes. New users get created in a hurry with whatever license was handy. Someone grants an app consent to read mailboxes because a vendor's setup guide said to. A departing employee's mailbox lingers, licensed, for eighteen months. Microsoft retires a setting you depended on and enables a new default you never reviewed. None of these events is dramatic; the accumulation is the problem. Managed 365 is, at its core, someone competent noticing.
License right-sizing: the money conversation
Licensing is where unmanaged tenants leak money most visibly. The patterns repeat across every company we take over:
- Licenses still assigned to people who left months ago.
- Everyone on the same plan "to keep it simple," including frontline staff who need a fraction of it and power users hitting quota on it. (Plan tiers and their mailbox quotas are covered in our guide to mailbox and item limits.)
- Paid add-ons duplicating what a bundled plan already includes.
- Shared mailboxes licensed unnecessarily, or unlicensed ones silently past the point where they need licensing.
Right-sizing is not a one-time audit, because headcount and Microsoft's catalog both move. A quarterly review that reclaims departed-user licenses, matches plan tiers to actual usage, and reconciles renewals routinely pays for a meaningful slice of the management fee by itself. That is not a claim about your tenant; it is an invitation to check.
The security baseline: MFA, conditional access, and the defaults you inherit
A fresh tenant with default settings is safer than an Exchange 2010 box, but "safer than end-of-life software" is a low bar. The baseline we implement and then hold in place includes:
- Multi-factor authentication for everyone, enforced through security defaults or, better, conditional access policies rather than per-user toggles that drift.
- Conditional access where licensing allows it: block legacy authentication protocols outright, require compliant or known devices for sensitive access, and challenge risky sign-ins. Legacy auth deserves special mention, because migrations often leave it enabled "temporarily" for an old scanner or app, and password-spray attacks live on exactly that opening.
- Admin hygiene: a small number of dedicated admin accounts, no daily-driver mailboxes with global admin rights, break-glass accounts documented and tested.
- Mail protection tuned, not defaulted: anti-phishing and anti-spoofing policies, plus SPF, DKIM, and DMARC kept correct as senders change.
- App consent governance, so users cannot silently grant third-party apps standing access to company mail and files.
Every item on that list decays without attention. Policies get exceptions "for now." New attack techniques prompt new Microsoft controls that someone has to evaluate and enable. A baseline is only a baseline if it is maintained.
Backup: what Microsoft's shared responsibility model really means
The most common misconception we correct after migrations: "it's in the cloud, so it's backed up." Microsoft's shared responsibility model draws the line clearly. Microsoft is responsible for the service: infrastructure, uptime, and resilience against hardware failure. You are responsible for your data: what gets deleted, overwritten, encrypted by ransomware that reached a synced folder, or purged when a retention setting did not say otherwise.
Native tools help: retention policies, litigation hold, and recycle-bin windows cover many scenarios. But they are compliance tools, not a backup product. They do not give you point-in-time restore of a mailbox or a SharePoint library, and they are only as good as their configuration on the day something went wrong. For most businesses the right answer is a third-party backup service for Exchange Online, OneDrive, and SharePoint, with restore tests actually performed, plus retention policies designed for your legal obligations rather than left at defaults. Deciding that mix is a one-time design task; verifying it keeps working is a standing one.
The ongoing admin nobody budgets for
Beyond money and security sits the steady operational stream: onboarding and offboarding done completely (mailbox, licenses, groups, devices, app access, every time), shared mailbox and distribution list changes, quota and archive monitoring before users hit walls, DNS and certificate upkeep, and triage of Microsoft's continuous stream of service changes, some of which genuinely require action. Individually, each task is small. Collectively they are a part-time job, and when they land on whoever is nearest, they get done inconsistently, which is how tenants drift into the state described at the top of this article.
What this looks like as a service
| Area | Cadence | What you see |
|---|---|---|
| License review and reclamation | Quarterly | A spend report and the changes made |
| Security posture | Continuous, reviewed monthly | MFA coverage, policy exceptions, sign-in risk summary |
| Backup verification | Monthly, with periodic restore tests | Confirmation that restores work, not just that jobs ran |
| User lifecycle | As requested | Onboarding and offboarding completed against a checklist |
| Service change triage | Continuous | Plain-English notice when a Microsoft change affects you |
Why the migration team is the right team to stay on
Any competent MSP can administer Microsoft 365. The argument for keeping your migration partner is context: we already know your mailbox layout, your shared mailboxes and why each exists, the app that still authenticates the old way, the license mix and the reasoning behind it, and where the bodies from the old system are buried, because we buried them properly during PST cleanup and decommissioning. That context is exactly what a new provider spends their first six months rebuilding. Management is optional with every migration we run; most clients take it, and the ones who do not still leave with the baseline configured and documented.
Want the migration and the aftermath handled?
Ask about managed Office 365 when you request your migration plan, and we will quote both together with no obligation to take either.
Plan My Migration