The Skypoint team has been using Microsoft Teams long before it became ubiquitous, and our clients love the experience of collaborating with us on MS Teams over the years.
When we joined Skypoint, we had to move tenants. The migration process was super complex. It was nothing like flipping the switch. But there’s a method to the madness. We drew from our experience and learned a lot from the process.
So instead of running our usually scheduled program where we share our trade secrets with app dev, business intelligence, and data strategy—today, we’re talking about the best way to optimize one of the most popular and important platforms your team is using on a daily basis…Microsoft Teams.
Optimize Your Microsoft Teams Architecture in 4 Steps
I know you’re excited to get this party started, but the best piece of advice I have for you is to sloooooooooooow down.
Before moving anything, take the time to map out your MS Teams architecture. Setting a vision and planning the migration upfront will save you a lot of time and frustration down the road. Here’s what to consider to design an optimal Microsoft Teams architecture that withstands the test of time.
1. Teams
Decide if you’re setting up teams based on the domain (i.e. development, marketing, HR) or if every department is going under the umbrella of the company domain. Start with fewer components to keep things manageable. If you decide to separate departments into individual teams, you should have a good reason for it.
For example, we set up a “leadership” team, which has specific security requirements as a private team instead of a private channel to maintain the full fidelity of Teams (more on that below.) We also created an IT support team to leverage Team apps, such as Virtual Agents, to handle support tickets more efficiently.
2. Channels and Access
After creating a team, you need to decide what channels go into it. Don’t make the mistake of creating too many channels. (MS Teams user with 20 channels, oh I’m definitely looking at you.)
It takes a lot of time and effort to manage your channels, especially if you go overboard. Think about it. If each channel has a different SharePoint site for files, shit gets complicated real fast when you have 20+ channels.
Next, consider who will access your channels:
- Which channels should be accessible to everyone (i.e. an all-hands internal channel, the watercooler channel)?
- Should you set up private teams and private channels?
Private channels have limited capabilities. You can’t take advantage of Microsoft technologies, such as task boards and other features that depend on Azure Active Directory (AD).
Be thoughtful when creating private channels and use them sparingly. We have a separate team for each external client and a private channel within the team for internal conversations. We also use Azure AD to manage access when appropriate.
3. File Structure
Our SharePoint used to be disconnected from Teams (thanks to the good ol’ SharePoint intranet days), and things were a hot mess.
For the Skypoint migration after the acquisition, we decided that our SharePoint should follow the structure of Teams—an approach that would make sense for most organizations unless you need to address some specific use cases. We now put everything in Teams instead of having a separate SharePoint site that’s disconnected from Teams.
Next, decide how you’d organize the files.
We keep the file folder paths simple by putting files under the general channel so people see everything all in one place. We treat the rest of the channels as communication paths and keep them rather barebone. If you need to add files to a specific channel in the future, try to keep the structure clean and intuitive.
4. Wikis and OneNote
We used wikis a lot for project information and enjoyed its simplicity. However, you can’t migrate wikis unless you painstakingly copy-and-paste everything into Microsoft Teams.
To avoid this issue, use OneNote for:
- Project notes
- Meeting notes
- Really…any information you want to share with the team.
OneNote is more flexible in the world of Teams. Create a OneNote tab to share notes with your internal team or clients without worrying about moving the information again during future migration. The copy section or tab function works like a charm.
MS Teams Architecture is a Collaborative Venture
While your organization structure and communication needs may change, pivoting to meet shifting requirements will be much easier if you have the core concepts and building blocks we discussed above in place.
Appoint a dedicated person to design the MS Teams architecture and manage access to teams and channels. Start small and keep it simple, then expand when necessary.
Keep in mind that setting up Teams architecture isn’t just an IT undertaking. Business and IT must collaborate closely because various business operations pieces must fit into the puzzle to optimize efficiency.
If you’re moving tenants, don’t forget to orchestrate cutovers for various applications within the Microsoft 365 family (Hint, hint: Outlook meetings that had your old Teams meetings) because the global connections will affect one another. You can’t have everything happen all at once, so planning out the transition is the key to minimizing disruptions.
Lastly, draw a line in the sand and decide when you’ll make the switch over. Be prepared for a few hiccups but stick with it…you’ve got this! And, if you don’t “got this,” hit us up and we’ll do our best to help you make a smooth transition by answering your MS Teams questions.
