SharePoint Online for UAE businesses: structure, permissions and migration.

Why SharePoint projects go wrong

SharePoint Online is included in most Microsoft 365 plans, so many UAE businesses already own it. The usual problem is not the product but the lack of a plan. Sites are created ad hoc, the old file server structure is copied across unchanged, and permissions are granted to individuals until nobody can say who can see what. A year later the platform is as untidy as the file server it replaced, with the added risk of data being shared outside the company.

This guide covers how to structure SharePoint, how to keep permissions under control, how to move from a file server in stages, and where Teams and external sharing fit. If you would like help rather than a reading list, see our SharePoint services page.

Start with the site architecture

Decide the shape before you create anything. A common and workable pattern is one site per department, project or business function, rather than one giant site with deep folders.

• Hub sites group related sites, such as all finance sites or all client projects, so they share navigation and search scope. A hub is for navigation and discovery, not for permissions.
• Team sites are where a group works on files together. Each is normally connected to a Microsoft 365 group.
• Communication sites publish information to many readers, such as policies, news or an intranet home page.
• Libraries hold the documents. Use a small number of well-named libraries, and use metadata and views for things you would otherwise express as deep folder trees.

Permissions and least privilege

The safest principle is least privilege: people get the access their role needs and no more. In practice that means managing access through groups, not individuals.

• Use the site's owners, members and visitors groups, and add people to those groups rather than sharing single files one by one.
• Break permission inheritance sparingly. Every unique permission on a folder or file is something to remember, audit and explain later.
• Keep the number of site owners small, and make sure each site has at least two so it is never orphaned.
• Separate sensitive areas such as HR, finance and legal into their own sites, instead of hiding folders inside a wide-open one.
• Review access on a schedule and when people change roles or leave. Our Microsoft 365 security baseline covers the identity settings that sit underneath this.

Migrating from a file server

A file server migration is mostly a clean-up job with a copy step in the middle. A sensible sequence looks like this.

• Inventory. List the shares, their size, their owners and who actually uses them. Look at the age of files and note anything that has not been opened for years.
• Clean up first. Decide what to archive or delete before you move it. Moving duplicates, personal files and abandoned projects only carries the mess across.
• Design on paper. Agree the sites, libraries and permission groups with the department owners before any data moves.
• Pilot. Move one friendly team first, let them work in the new structure and change what does not suit them.
• Move in waves. Migrate department by department, set the old share to read-only once a team has moved, and keep it for a defined period before retiring it.
• Support people. Show staff how to sync libraries, share links properly and find files, because adoption decides whether the project works.

Know the limits and the awkward files

Check for file names and paths that SharePoint does not accept, very large files, and old formats or applications that expect a mapped drive letter. Some line-of-business software writes to a network share and will not work from a document library, so identify those early. Our data and email migration page explains how we approach moves of this kind, and the Microsoft documentation lists the current file and path limits, which change over time.

How SharePoint and Teams relate

Teams is a front end. When you create a team, the files in its channels are stored in a SharePoint site behind it, and chat files are stored in the sender's OneDrive. Understanding this avoids confusion about where a document really lives and who can open it. Create teams deliberately, name them consistently and decide who is allowed to create new ones, otherwise you collect dozens of near-duplicate teams and sites.

External sharing risks

Sharing with clients and suppliers is useful, but it is also where data leaves the company. Set the tenant-wide sharing level first, then tighten it per site where needed.

• Prefer sharing with named external users over anonymous links that anyone holding the link can use.
• Use expiry on guest access and on links, and review the list of guests regularly.
• Apply sensitivity labels and data loss prevention to sites that hold confidential material, where your licences include them.
• Make sure staff know what is safe to share and who to ask.

Governance that people will follow

Governance does not need to be a thick document. Write down who may create sites, the naming convention, who owns each site, how long content is kept, and what happens to a site when its owner leaves or the project ends. Assign an owner for the whole platform. Think about retention and records early, particularly if you work under audit or regulatory expectations; where SharePoint alone is not enough for regulated records, a dedicated system such as windream document management may be worth a look. Check your own obligations with legal advice. Also review permissions before enabling AI assistants such as Microsoft 365 Copilot, since they can surface whatever a user is already allowed to see; see Microsoft 365, Copilot and Defender.

Where to begin

If you are unsure how tidy your current setup is, a free IT health check will show where permissions, sharing and licensing stand today. Missan Global has supported UAE organisations since 2004 from its Al Majaz, Sharjah head office, and we are a Microsoft Solutions Partner for AI Business Solutions.