Reader’s note: This blog post doesn’t provide step-by-step technical instructions on how to “teamify” a site; there are plenty of resources on the web that provide instructions. Below are links from two reliable sources that can help you out:

SharePoint Maven: How to Connect a SharePoint Site to an Office 365 Group

Microsoft: Connect a classic experience SharePoint team site to a new Microsoft 365 Group

One of the emerging new words on the modern workplace scene I get asked about by clients and see used in the larger Microsoft 365 (M365) community is “teamify”. It is an emerging power phrase spurned on by momentous excitement of Microsoft Teams (and rightfully so!) But in simpler terms, this is the process of taking a SharePoint site with no M365 Group connected (usually an older and/or “classic” SharePoint site) giving it a Group, and thereby grooming it for collaborative use in Teams and other multiple M365 apps (hence where the term is borne from). Teamify has weaved it’s way into client and consultant vernacular – but it can introduce some shades of grey if both the business and technical context behind it aren’t fully understood.

So what’s the right approach to teamify in your organization?

There’s really two parts of the process to consider: the business side, which addresses why “teamification” is needed (another power word!), and the technical side, which concerns how teamification is achieved.

Before you proceed to teamify your SharePoint site, asking the right questions and mapping your vision to technical capabilities will go a long way to making this a successful endeavor for your organization.

The Business Considerations of Teamify

Identify your Business Requirements

As with any software or tech project, it’s best to articulate what your organization needs are before performing a teamify project. What does teamifying a SharePoint site do for your relevant business users? For your organization and its goals?

Additionally, what is your organization looking to gain by this effort? What does your “before” and “after” look like? What functional capabilities do you have now that can remain consistent and what needs improving?

Have a business analyst or consultant engage the M365 site owners, as well as the related stakeholders. Identify the requirements your organization needs, and prioritize them based on importance (e.g. do you need to collaborate on site content? Do you need to assign group tasks around the content? Are workflows required to interact with business data?)

It’s alright not to know everything up front; often times these answers will come from deep discussions and/or iteratively designed prototype sessions. Requirements are fluid, and use cases through constant feedback loops can help identify new requirements, change existing ones, and refine improvements where needed.

Identify the “Champions” to Help Take you There

In my experience, the best projects with the highest succes rates are when the client organization has an individual (or group of individuals) who understand the need for technological change and champion the introduction of the new technology. They also become the “cheerleaders” for others in the organization to get onboard (“passive adoption”), and can also be the technical resource for assisting others and identifying emerging upgrades.

For example, a Finance team may have a junior analyst who is the SharePoint site administrator for the business’ financial documents, but also has experience using Teams in her previous role. This person knows how quickly and easily it is to share documents, collaborate on in-progress financial sheets, and create discussion through team chats. This person would be a great resource to include on your Teamify efforts.

Position your Teamify Project Within the Larger Vision of your Enterprise Architecture

Is there an enterprise architecture strategy or a technology roadmap in your organization? Would enabling Microsoft 365 collaboration features for SharePoint sites fit into that vision? While the general obvious answer is yes, this needs to be considered in your organization. For example, if OpenText Core Share is what your company is investing in for the long-run, beefing up old SharePoint sites might be a futile exercise if users are expected to use OpenText as their main collaboration platform, or if users are managed from OpenText Directory Services (and not through Azure Active Directory integration).

The Technical Considerations of Teamify

At the core of the teamify concept, an organization takes a SharePoint Site and wraps it around Microsoft Teams functionality so that it can stand to be used in a modern workplace and Microsoft 365 environment.

For posterity, to teamify technically means to beef up your site with the following:

• Provisioning a new Microsoft 365 group connected to your site collection;
• Replacing the home page with a modern SharePoint home page;
• A shared mailbox and calendar in Outlook;
• Task Management through Outlook, Planner and To Do 365 apps;
• Option to add a team with Microsoft Teams; and,
• Shared group identity with associated lifecycle and policies.

From my experience, the process to teamify is usually performed on “classic” SharePoint sites with sufficient amounts of relevant content (ergo, older sites that are still in use). These sites often result from being migrated into a Microsoft 365 tenant from an on-premise environment, created with an M365 Group governance strategy, or created by an untrained site administrator out of convenience and familiarity (do any of these sound familiar?)

Reasonably, then, the SharePoint site itself contains intrinsic value in which it must be retained long-term. At the heart of the matter, the content on the SharePoint Site is most likely the reason to teamify. If not, the site is more likely useful as an archive or as transitory/static content that doesn’t need collaboration.

Is the SharePoint site a central tenet in which users needs to collaborate on? Are there documents such as templates, charts, and reports that require users to discuss, share, and co-author in a Microsoft 365 environment? Is there an existing, more appropriate site collection that reflects the organization’s business units or teams already in existence instead? These are the initial technical questions to consider.

Information Architecture Considerations

For the site you intend to teamify, you must identify what type of site it is – is it it’s own site collection? Or is it a subsite of a site collection site? If subsites exist, which subsites need to be teamified? SharePoint sites must exist as stand-along site collections before you can teamify a site. You will need to consider the following:

• Is your current SharePoint site in an on-premise environment like SharePoint 2013 or 2016? Will you need to migrate the site to SharePoint Online, and do you have the tools/expertise to perform this task?
• Does your new site need to follow a SharePoint information architecture, such as using Site Columns, Content Types, Taxonomies, or information management policies? Are these requirements for all sites or simply the site being teamified?
• Are there workflows that impact content on the site? If so, do workflows run on content types or do they run on items in a list or library?

Write down the current state elements of the SharePoint site, and match it to what needs to exist in the “future state” of the site. This includes a feature-by-feature comparison of what you expect when the teamification is done. This is where an experienced SharePoint administrator, business analyst, or Microsoft 365 consultant can help you articulate the mapped properties and features.

User Implications

As we now know, to teamify a site is to groupify a site. That is, you are adding a Microsoft 365 Group to a site. This has implications on the users and their ability to navigate and use the new site but also to navigate/use the features of the Group, including Teams, Outlook, Planner, Power Automate, etc.

Note that in teamifying your site, there is still a separation between the Site Collection permissions and the M365 Group. The former does not imply full membership of the latter and vice versa. When in the process of teamifying and thereby creating Group users, they are automatically added to the related site collection permission groups (Group Owners become Site Owners, and Group Members become Site Members). Note that you also can’t add Distribution Groups, Azure Active Directory Groups, or Microsoft 365 Security Groups into M365 Groups – only users. Visitor groups will remain untouched as Site Collection permission groups.

What about external users?

Consider the teamify experience as a chance to clean up permissions for your site -you’re essentially forced to do so by way of creating an M365 group and having to perform a permissions audit on owners and members. Once the site has been teamified (or even beforehand), it may be good to review just who needs access to the site, where they need it, and what level of permission is appropriate. Don’t forget to ensure your external sharing capabilities are enabled in the Microsoft 365 Admin Center to allow for external user access with appropriate levels of access and security.

Any Rules of Thumb?

At the end of the day if you have to make a quick decision, ask yourself three things:

• Is the site still relevant to users and the content needing collaboration?
• Do you need M365-exclusive capabilities for the Site, including integration with Microsoft Teams?
• What are the governance rules around teamifying a site and in doing so is there a governance policy you might be in violation of (or in violation by not doing?)

If you’re not sure where to start or if this is part of your effort to modernize your workplace, consider getting in touch with Cogito Hive partners to help you out. We can walk you through with an assessment of your current state, a picture of your future state, and if teamifying an old site is right for you and your organization.