Most organisations we meet already own Microsoft 365. What they do not have is a tenant that was designed, an identity model that was finished, a security baseline that is actually enforced, or users who work with the platform rather than around it.
We run Microsoft as a practice, not a project queue. That means the same team advises on tenant and licensing strategy, executes the migration, hardens identity and endpoint, and then either hands over a documented estate or keeps running it. The advisory is not sold by one company and delivered by another.
The migration discipline underneath it is deliberately conservative: coexistence before cutover, backup before deletion, differential sync at the switch, and a monitored soak period before anything legacy is decommissioned. Unglamorous, and the reason we do not lose mail.
The decisions that are expensive to reverse: how the tenant is structured, what you are actually licensed for, and what the governance model is.
Mail, files and collaboration moved in waves with coexistence maintained, so nobody works in two places without knowing it.
The layer everything else depends on - and the one most often left half-configured after a self-service migration.
Defender and Purview deployed as a programme with measured posture, not switched on and left at defaults.
The part that decides whether the investment returns anything - permission hygiene first, then pilots, then measurement.
This is the discipline we apply to every tenant and email deployment. Each phase has an exit gate, a rollback position and an evidence pack in Cogent OS under ITIL change control.
Email and tenant is where most engagements start. It is rarely where they end.
Teams deployment, governance and lifecycle policy, channel and guest-access models, and migration from legacy collaboration platforms.
File estate migration from on-premise shares or a legacy tenant, with permission mapping, sensitivity review and a known-good folder structure.
Where a hybrid posture is required for compliance or a phased move, designed and operated properly rather than left as a permanent temporary state.
Post-acquisition tenant merges: identity mapping, coexistence, licensing rationalisation and phased user migration by business unit.
Zero-touch device provisioning, compliance and configuration policy, application packaging and staged update rings.
Endpoint, Office and identity protection deployed with tuned policy, plus DLP, retention and sensitivity labels under a governance model.
A low-priority MX for the new tenant goes in while the legacy MX stays live and untouched. Mail flows to both, nothing is orphaned, and the switch is a priority change rather than a leap.
No local store, mailbox or file share is removed until its content is verified in the new tenant and a restorable backup exists. This is a hard rule, not a best practice we skip under time pressure.
Mail that arrived during the migration window is synced after the MX flip, so the gap between the last full pass and the cutover is closed rather than accepted as loss.
Every phase runs as a change record with CAB approval, a documented rollback plan and an evidence pack - so the audit position and the project status are the same artefact.
| MODEL | WHAT IT COVERS | COMMERCIAL SHAPE | BEST FOR |
|---|---|---|---|
| Fixed-scope deployment | A defined tenant, migration or security programme with agreed phases, exit gates and hypercare window | Fixed price against a scoped statement of work | A known move: new tenant, tenant merge, Defender rollout |
| Managed Microsoft 365 estate | Ongoing operation: patching and update rings, policy management, security posture, licence optimisation and monthly reporting | Monthly fee per user or per tenant | Organisations without a dedicated Microsoft team |
| Standing practice retainer | Named consultants with a roadmap cadence - quarterly planning, architecture decisions and delivery capacity on call | Retained days per month with a roadmap review | Estates changing continuously, or an internal team needing depth |
Most clients start with a fixed-scope deployment and move the result into a managed estate, so the team that built it runs it. Where you keep operations in-house we hand over the runbook and documentation as a contractual deliverable.
A multi-site organisation was running mail on an ageing platform with historical mail scattered across local stores on individual machines, no consistent backup, and distribution groups nobody could account for. A previous attempt to move had been abandoned after a test cutover lost calendar delegations.
We ran the six-phase methodology: a full domain, mailbox and local-storage audit first, then a tenant built with admin-role separation and the data-residency region set deliberately. A low-priority MX went in alongside the live one so coexistence held throughout, users were created from a validated import, and MFA with Conditional Access was enforced before the first mailbox moved rather than after.
Historical mail was migrated with verified backups retained, shared mailboxes and delegations rebuilt and tested against a checklist, then the MX priority was flipped on an agreed date with a differential sync closing the migration window. The legacy platform stayed live through a monitored soak period and was decommissioned only after sign-off.
Anonymised by agreement. Client names available under NDA.
For mail, effectively none. Coexistence means the legacy MX stays live while the new tenant receives on a low priority, so mail keeps flowing throughout the migration. The cutover itself is a DNS priority change, and a differential sync afterwards closes the window. What users do experience is a new profile on their mail client, which we set up as part of the visit or remote session.
It is audited first - location, size and whether any backup exists - because this is where data is genuinely lost in badly run migrations. Content is then migrated by network upload or staged import, verified in the new tenant, and only then is the local store considered for removal. Backup before deletion is a hard rule with no exceptions for schedule pressure.
It reduces it. Deferring MFA means running a new tenant in a known-vulnerable state during exactly the period when credentials are being reset and users are being phished with migration-themed lures. We enrol users in MFA as part of onboarding with Conditional Access policies scoped so break-glass access remains available, and the enrolment is supported during hypercare.
Often, yes, and the review is part of advisory rather than a separate exercise. The common findings are licences assigned to leavers, over-specified tiers for task-based users, duplicate third-party tools already covered by the suite, and add-ons bought before the base licence changed to include them. We present the finding and the risk of each change rather than simply downgrading.
Yes, where compliance or a phased plan genuinely requires it. What we will not do is leave a hybrid posture in place as an accident with nobody owning it - if it is intentional it gets a documented design, patching and monitoring; if it is a leftover, we plan its retirement.
Tell us the mailbox count, the countries and the constraints. We will come back with the phase plan, the cutover approach and the rollback position at each gate.