Move the content that matters. Leave the rest behind.
Mergers, divestments, rebrands and the last file server in the comms room all end in the same project. LogiSam plans and runs Microsoft 365 tenant-to-tenant migrations — SharePoint, OneDrive, Teams and the Power Platform — and on-premises file shares into the cloud, in waves, with users still working.
Migrations go wrong in predictable places
Almost never in the copy engine. Nearly always in the decisions that were left open.
Book a migration assessment- The acquisition closed and both companies are still on separate tenants, six months on.
- Nobody can say which of the 900 SharePoint sites are still in use.
- A file server is out of support and the share permissions are a decade of nested groups.
- The last migration moved everything, including 4 TB nobody has opened since 2018.
- Power Apps and flows were forgotten until the week before cutover.
- Users lost their OneDrive sync and the service desk absorbed it for a month.
What actually makes a migration succeed
The tooling is mature and largely interchangeable. The difference between a calm project and a painful one is scope discipline, identity planning and communication.
Cut the scope first
Every gigabyte costs time, risk and storage at the far end. Scanning and pruning before the project means a third less to move and a shorter cutover window.
Identity is the hard part
Accounts, groups, guests, licences and MFA have to land before content does. Permission mapping is only as good as the identity mapping underneath it.
Waves, not a big bang
Small, reversible waves with a pilot group first. Each wave teaches you something before the next one carries more people.
The comms plan is the project
Most migration pain is surprise, not data loss. Users who know what changes, when, and where to get help barely notice the move.
What we migrate
End to end, or the parts your incumbent partner is not covering.
Tenant-to-tenant (M&A and divestment)
Users, mailboxes, OneDrive, SharePoint, Teams, groups and guests between Microsoft 365 tenants, with coexistence while waves run. Deliverable: one tenant, one identity, one directory.
SharePoint & OneDrive migration
Sites, libraries, metadata, version history and permissions — into a target architecture rather than a mirror of the old mess. Deliverable: content in a structure that was designed.
Teams migration
Teams, channels, membership, tabs, files and private channels, with a plan for what happens to chat history and where it realistically cannot follow. Deliverable: teams that work on day one.
Power Platform migration
Solutions exported and imported, connections re-established, environment variables repointed and ALM set up in the target. Deliverable: apps and flows that still run after cutover.
On-prem file shares to the cloud
File servers and NAS mapped to SharePoint, Teams, OneDrive or Azure Files, with the permission model rebuilt properly on the way. Deliverable: a decommissioned server.
Pre-migration clean-up
A read-only scan to find duplicates, stale sites, leaver OneDrives and oversized version history, so you migrate what matters. Deliverable: a smaller, cheaper, faster project.
Do not pay to migrate data nobody wants
Migration cost scales with volume, and most tenants are carrying 40–60% content untouched in over a year. TSO scans SharePoint, OneDrive, Exchange and Teams read-only and tells you exactly what is duplicate, stale, ownerless or hoarding versions — so the scope conversation happens before the statement of work, not after.
- Duplicate groups and oversized version history, with reclaimable totals
- Ownerless sites and leaver OneDrives — the ones nobody will claim in a workshop
- Costed scenarios so you can show what pruning first saves on the project
Read-only · nothing is deleted without owner sign-off
How we run a migration
- 1
Discover
Inventory everything — content, identities, Teams, apps, flows, integrations and the things nobody mentioned.
- 2
Reduce
Scan and prune. Agree with owners what moves, what archives and what is finally allowed to die.
- 3
Design
Target architecture, identity and permission mapping, coexistence model and wave plan.
- 4
Pilot
A friendly group goes first. We fix what the pilot exposes before wave two.
- 5
Cut over
Waves with pre-stage and delta passes, reconciliation evidence per wave, then hypercare and decommission.
What you walk away with
Every engagement ends with something you can use — not a slide deck.
- A full inventory of content, identities, Teams and Power Platform solutions
- A target architecture — not a copy of the structure you were trying to escape
- A wave plan with named owners, dates and a rollback position per wave
- Reconciliation evidence per wave: what moved, what did not and why
- Apps, flows and integrations working in the target tenant
- Decommissioned source servers or tenant, with the licence saving realised
Ways to start
Migration assessment
1–2 weeksInventory, scope reduction and a realistic plan with dates, risks and cost before you commit to anything.
- Content and identity inventory
- Power Platform estate included
- Wave plan and effort estimate
Managed migration
ProjectWe run it: tooling, waves, coexistence, comms, cutover and hypercare, with reporting to your steering group.
- Pilot-first wave plan
- Reconciliation evidence
- Hypercare and decommission
Specialist support
FlexibleYour team runs the move; we cover the parts that are hard — Power Platform, permissions or architecture.
- Power Platform solution migration
- Permission and IA design
- Escalation support during cutover
Built on
Trusted by teams at
Related insights
Microsoft Copilot for DIFC Financial Institutions: A Compliance-First Approach
DIFC-regulated firms face stricter data and access requirements before Copilot rollout. See what a compliance-first Copilot deployment actually requires.
الأسئلة الشائعة عن مايكروسوفت كوبايلوت في الإمارات
إجابات مباشرة عن أكثر أسئلة مايكروسوفت كوبايلوت شيوعا لدى الشركات في الإمارات: أمان البيانات، دعم اللغة العربية، الأسعار، والجاهزية، في مكان واحد.
Microsoft Copilot FAQ: The Questions UAE Businesses Actually Ask
Microsoft Copilot FAQ: straight answers to the most common questions from UAE businesses, data safety, Arabic support, pricing, and readiness, in one place.
Migration: your questions answered
What is a tenant-to-tenant migration?
Moving users, mailboxes, SharePoint sites, OneDrive, Teams and increasingly Power Platform solutions from one Microsoft 365 tenant into another — typically after a merger, an acquisition, a divestment or a rebrand. It is not a file copy: identity, permissions, sharing links, Teams membership, retention labels and the apps built on top all have to land correctly too.
How long does a tenant-to-tenant migration take?
Planning and discovery is usually three to six weeks; the move itself runs in waves over anything from a weekend to several months depending on volume, the number of users and how much coexistence is needed. The variable that moves the date most is not data size — it is how many decisions about naming, retention and ownership are still open.
Can users keep working during the migration?
Yes, with coexistence. We set up cross-tenant mail flow, free/busy sharing and directory synchronisation so people can collaborate across both tenants while waves move. Each user experiences one short cutover rather than a long freeze.
Do Power Apps and flows migrate too?
They can, but not by lifting and shifting. Solutions have to be exported, connections re-established against the target tenant and environment variables repointed — and anything built directly in a default environment has to be packaged first. We inventory the estate before committing to a date; see Power Insights for how we produce that list.
What happens to file shares and on-premises servers?
We map each share to its destination — SharePoint document library, Teams channel, OneDrive or Azure Files — fix the permission model on the way (nested NTFS groups rarely survive a lift and shift intact), migrate in waves and then decommission the server. Long paths, illegal characters and 15-year-old .pst files are the usual surprises.
Do sharing links and permissions survive?
Permissions map where identities map. Anonymous and organisation-wide links generally do not survive a tenant move, which is genuinely a good thing — it is the one moment you can re-establish a clean sharing model rather than carrying a decade of exceptions across.
Should we clean up before or after we move?
Before, almost always. You pay to migrate every gigabyte in time, risk and storage, and most tenants are carrying 40–60% content that has not been touched in a year. A read-only TSO scan before the project starts routinely takes a third off the scope.
Migrate less, and the project gets easier
Start with a free read-only scan of what you are planning to move. Most tenants find a third of it does not need to travel — which changes the timeline, the cost and the risk.
UK & UAE · Microsoft Solutions Partner · tenant-to-tenant and on-premises to cloud