Microsoft 365 Migration Services, Delivered Remotely Worldwide

Most Microsoft 365 migration services are sold on the cutover — the weekend where mail moves and everyone holds their breath. The cutover is the easy part. What decides whether the migration was any good is the six months afterwards, when somebody needs to add a user, change a policy, or work out why a shared mailbox behaves differently to every other one.

We do this work remotely for businesses in South Africa, the UK, Europe and further afield, and on site across the Helderberg and Cape Town where we are based. A tenant migration needs nobody in the room; the shape is the same either way.

What Microsoft 365 migration services actually involve

Four phases, and the first one is the phase most quotes skip.

Discovery. What mail platform is in use, how big the mailboxes are, where the files live, what still authenticates against the old system, which applications send mail through it, and who owns the domain. This last one derails more migrations than any technical problem: a domain registered a decade ago to a person who has left, with a registrar login nobody has.

Tenant design. Naming, licensing, groups, the identity model, sharing defaults, retention. These are decisions, not settings, and they are cheap now and expensive later. A tenant name is permanent. A licensing mix chosen without reading the feature matrix costs money every month forever.

Staged cutover. Mail, then files, then identity, then devices — with a pilot group first and a defined way back. The pilot is not a formality. It is where you find the one accounting package that only speaks to an on-premises server.

Handover. Written documentation of what was built and why, given to you. Not a login sheet — the design decisions, the exceptions and the reasoning.

The decisions that are hard to reverse

Some choices in a Microsoft 365 tenant are trivially changed later. Others are effectively permanent, and it is worth knowing which is which before someone picks one on your behalf on a Friday afternoon.

• The tenant domain (yourcompany.onmicrosoft.com). Cannot be changed. It appears in enough places to be annoying for years.
• The identity model. Cloud-only, synchronised, or federated. Changing later is possible and unpleasant.
• Data residency. Set at tenant creation based on the country you declare. Relevant if you have contractual or POPIA obligations about where personal information is processed.
• The licensing baseline. Not permanent, but a Business Premium versus Business Standard decision changes which security controls you can even turn on, and retrofitting is a project rather than a checkbox.

None of these are exotic. They are simply decided once, usually quickly, and then inherited by everyone who touches the tenant afterwards.

Migrating off a platform that is being retired

A significant share of migration work right now is not greenfield — it is moving off something Microsoft has announced the end of. Exchange Web Services is the current example: it is being withdrawn from Exchange Online in stages, and applications still using it need to move to Microsoft Graph.

That kind of deadline changes the sequencing. There is no value in a beautifully designed tenant if a line-of-business application stops being able to reach mailboxes six weeks after go-live. We check for these before scoping anything, and the detail on the current one is in our write-up of the checks the EWS retirement demands.

Microsoft publishes the authoritative deprecation list in the Microsoft 365 roadmap and change documentation. It is worth someone reading it on your behalf on a schedule, which is one of the things a virtual CIO engagement is for.

What we hand over at the end

The deliverable is not "it works now". It is a document set you keep:

• The tenant design and the reasoning behind each decision.
• An identity and licensing map — who has what, and why.
• Conditional access and security baseline configuration as applied, with the exceptions listed and justified.
• Every integration that touches the tenant: what it is, what it authenticates as, and what breaks if it is removed.
• The domain, DNS and registrar position, in writing, with the access confirmed as yours.

That last point is worth being blunt about. Your tenant, domains and licences should be registered to your organisation, not to whoever set them up. This is the most common form of lock-in in this industry and it is entirely avoidable at the start.

Security is part of the migration, not a phase after it

A migration is the one moment when changing the identity configuration is cheap, because everything is moving anyway. Multi-factor authentication, conditional access, blocking legacy authentication protocols and setting a device baseline all belong in the migration plan. Retrofitting them afterwards means a second round of user disruption for the same outcome.

It also matters because identity is now where the attacks land rather than the network perimeter — the reasoning is in our analysis of the gaps MFA alone does not close. A tenant that goes live with legacy authentication still enabled is a tenant that goes live with a known open door.

What this costs and how it is scoped

Any number quoted before discovery is a guess dressed as a quote. What moves the price of Microsoft 365 migration services is genuinely predictable, though: the number of mailboxes, the volume of file data and where it currently sits, how many integrations authenticate against the old platform, whether identity is staying cloud-only or synchronising with an existing directory, and how much documentation already exists.

An estate with a current inventory is meaningfully cheaper to migrate than one without, because discovery is shorter and there are fewer surprises mid-project. If you have nothing written down, the assessment produces it — and you keep that document whether or not you go ahead with us.

We scope discovery as its own fixed piece of work for exactly this reason. It ends with a written plan and a real number, and you are free to take both elsewhere.

Getting started

The first conversation is not a sales call, it is a scoping call: what you are running now, what is forcing the change, and what the deadline is. If a migration is the wrong answer — and sometimes it is, particularly when the real problem is a single application — that is a more useful thing to hear early than late.