Microsoft 365 and Azure, built properly from the first day

Most Microsoft 365 problems we are called about are not faults. They are decisions taken quickly at the start, by whoever set the tenant up, that nobody revisited — a licence model that no longer fits, sharing left wide open, mailboxes that grew into a filing system, devices nobody can account for. None of it breaks loudly. It just gets more expensive to unpick each year.

• Tenant design and setup — domains, DNS, mail flow, licensing that matches how people actually work, and the naming and group structure everything else hangs off.
• Migration — from on-premises Exchange, from Google Workspace, from another tenant, or from a hosting provider's mailboxes. Mail, files, calendars and contacts.
• Identity — Microsoft Entra ID, conditional access, multi-factor authentication, joiners and leavers that follow a process rather than a memory.
• Devices — Microsoft Intune enrolment, compliance policies, and machines that arrive configured rather than being configured at a desk.
• Security baselines — sharing and external access policy, mailbox auditing, retention, and the defaults that Microsoft ships open.
• Azure — virtual machines, networking, backup and site-to-site connectivity where a workload genuinely belongs there rather than in the cloud by default.

This is the most common way we start. You already have Microsoft 365. It works, mostly, and nobody is certain what is in it.

1. Audit Licensing, identity, security policy, mailbox and file permissions, device state, and what is actually being paid for against what is being used.
2. A written plan Findings with priorities and costs, in order of what would hurt most. That document is yours — act on it with us, with your current supplier, or in-house.
3. Staged cleanup Changes go in in waves, each one reversible, so nobody loses access on a Monday morning because a policy was tightened on Friday.

We do not require you to move away from whoever set it up, and we do not open with a proposal to replace what you own. Where something genuinely cannot do the job we will say so and price the difference.

A migration is judged on one thing: what Monday morning is like. Ours run in planned waves, usually outside business hours, with tested rollback at every step. Users are moved in groups small enough that a problem affects a handful of people rather than the company, and each wave is verified before the next one starts.

Before anything moves we publish and test the mail authentication records — SPF, DKIM and DMARC — because the failure nobody plans for is not a lost mailbox, it is a month of invoices quietly landing in customers' junk folders.

It is part of the project, not a separate line on the quote. MFA from day one, managed devices, conditional access that reflects how your people actually work, and configurations documented and handed to you.

Backup is treated as a separate question from Microsoft's own retention, because the two are not the same thing and the difference is usually discovered at the worst possible moment.

Documentation, always. Tenant configuration, identity and policy decisions, device standards, and the reasoning behind them. The test we hold ourselves to is simple: if you replaced us tomorrow, the next engineer could pick it up without guessing.

That matters more in cloud work than in cabling. A patch panel can be traced by hand. A conditional access policy that nobody documented is discovered when it locks somebody out of a building on a Sunday.