By Chris King – Senior Technical Engineer
October 11, 2017
In this series we cover a unique Office 365 migration scenario known as “Tenant to Tenant” migration. Our goal with this series is to educate stakeholders so they can make educated decisions regarding this type of migration, as there are potential risks to be avoided as well as opportunities to save money in the process. We do so by defining key factors, providing example scenarios, and outlining cutover strategies.
In Part 1 below, we provide background information on Office 365 tenants and define important key terms so that everyone involved in your migration project can start off on the right foot.
Part 1 – Office 365 Tenant to Tenant Migration – Key Concepts & Terms
This part of the series aims to identify, define, and disambiguate key terms relating to the Office 365 “Tenant to Tenant” migration scenario. Skip straight to the bottom for a glossary-style definition of key terms.
While discussing our target audience for this series, we realized that not only could there be multiple reasons to migrate tenant to tenant, but also that there could be multiple departments and interests involved. While some stakeholders may be tech savvy IT administrators, others may have insight only into certain aspects of Office 365 like billing or day-to-day operations. Furthermore, we’ve found that in the case of hosted, or “syndicated” Office 365, our customers have often been kept in the dark about what is really going on under the hood, so as consultants we often start each project off by bringing everyone up to speed. Based upon this realization, I decided the best way to begin the series would be to simply explain the Office 365 tenant concept and go from there.
An Office 365 tenant is an individual and unique customer account that provides an environment for controlling Office 365 users, services, and data. Each tenant exists next to thousands of other customer tenants beneath the same Office 365 “umbrella” so to speak. From the perspective of an Office 365 customer, a tenant might be visualized as a browser-based management portal, but from the perspective of a Microsoft engineer, a tenant might be visualized more like an account in a large database. Each tenant has the potential to independently host the infrastructure for multi-division enterprises consisting of tens of thousands of users with multiple terabytes of data and complex networks of productivity tools.
Tenants are typically created in one of three ways:
- The suggested method is by signing up for a free trial of E3 or any other business class license.
- The most common method is to go through a third-party vendor from whom Office 365 licenses and support services are purchased.
- A third method, which we discuss in a later article, is to purchase a tenant, licenses, and technical support as a prepackaged suite from a hosting provider. This is known as “syndication”.
For the first two options, the customer maintains full administrative rights to their tenant and gets to choose a custom subdomain (also called the Initial Domain) to distinguish themselves from all other Office 365 customers. This Initial Domain determines a customer’s SharePoint Online landing page and default email addresses among other things.
The syndication option grants the customer only limited administrative rights and a random, serialized domain name which is issued by the hosting provider. Configuration and many other administrative functions are generally taken care of by the host, which can be appealing to some customers.
When creating your own Office 365 tenant, choose a subdomain you like, as it cannot be changed down the road. This subdomain determines your SharePoint online URL, also called a “team site”.
Tenants are hosted on Microsoft’s cloud servers, which are redundantly backed up and spread out all over the world. Except for security patches that get pushed out regionally, and certain tenants serving geo-politically sensitive nations, all tenants are created equal and include the exact same underlying features. In other words, all tenants start off the same but differ only in how they are configured.
Office 365 tenants are used in a variety of ways depending upon the needs of different customers, and licensing determines which features get unlocked. The base Office 365 infrastructure (with no licensing) includes everything necessary to preconfigure tenant settings, create and manage users, purchase and manage licenses, create and manage Microsoft support requests, and everything else an IT admin would need to prepare for an Office 365 deployment or onboarding project. Once licensing has been applied to users, a vast array of services, like email hosting, reporting, auditing, Office Pro Plus, and SharePoint Online become available to both users and administrators.
A bare-bones tenant without licensing contains only two Admin Centers. After adding an E3 subscription to a user, other Admin Centers become “hydrated” and appear in the console.
Licenses, Subscriptions, and Billing
Office 365 is unique in that rather than a traditional device-based licensing model, where licenses are assigned to devices (OEM, VLK, etc.), all Office 365 licenses are identity-based and assigned to users. This makes management of licenses very easy and cost-effective. If a user leaves the company, admins can simply assign that user’s license to their successor with a few clicks of a mouse. This also provides the additional bonus of making mailbox and software provisioning much simpler than in the past.
Licenses are charged on a subscription basis and are purchased either directly from the tenant or through Microsoft Partners. Subscriptions can be cancelled or downsized at any time, for example when a license is no longer needed. Partners (including hosting providers) often charge a premium for their licenses in exchange for some sort of value-added bonus (direct support hotlines, etc.), but often markup is negligible. Bills can be paid in any number of ways; either through the portal or through partner agreements. In the case of a tenant being syndicated, invoices would come from the host rather than from Microsoft.
Identity Management refers to the creation and administration of users, contacts, groups, and other “who” objects in an IT environment. This includes, but is not limited to, the management of usernames, passwords, attributes (display name, telephone number, title, etc.), security permissions, and licensing.
While identities are generally managed from the Office 365 administrative portal, the data itself resides in a separate system called Azure AD (Azure Active Directory). Azure AD works just like on-premises Active Directory, only it was designed to support Office 365 and other Microsoft cloud services. Every tenant comes with Azure AD Basic at no cost to the customer, but for organizations who have advanced Identity Management requirements, premium tier licenses are also available to unlock additional management features.
Note: Microsoft Azure is a separate Microsoft cloud service that has an account/portal experience that is referred to as a tenant. For the sake of this blog series however, when we refer to tenants, we are only talking about Office 365.
Office 365 users are managed in the Office 365 administrative portal, but user information is stored in Azure Active Directory.
There are two ways in which identities are created and managed in a tenant:
- The most common is for identities to be manually created and managed directly from the Office 365 admin portal.
- A second option is to deploy a tool to sync existing local Active Directory users and passwords to Azure AD. The most popular tool is Microsoft’s Azure AD Connect, but third-party tools also exist and work well.
The first option works well for small organization where managing passwords in multiple places isn’t a concern and email or security requirements aren’t complex. The second option is generally chosen when simplifying workflow or migration projects are desired. Typically, the configuration of a sync tool is considered a permanent installation.
As previously mentioned, the domain name designated when a tenant is initially configured is called the Initial Domain. This is a subdomain of the onmicrosoft.com domain and looks something like ssaas.onmicrosoft.com. All Office 365 customers get an onmicrosoft.com domain for their tenant, and all Office 365 users are assigned an email address with this domain which can receive mail. Migration engineers often refer to these domains as “Routing Domains” because they allow data to be migrated in the background even if users do not have an official company email address.
Custom domains are domains that customers like you or I purchase to represent our companies. They are used for anything from websites to email servers. As long as we can prove to Office 365 that we own the domain, we can utilize custom domains in our tenants. For example, Strategic SaaS’s Initial domain was ssaas.onmicrosoft.com when we created our tenant, but, through a simple process called Domain Verification, we proved to Microsoft that we own strategicsaas.com. Once this was done, we could create users in our tenant with strategicsaas.com usernames and email addresses, as well unlock many other features that would not have been available otherwise.
Domains play a key role in determining the proper course of action for each tenant to tenant migration– the main factor being that a domain cannot be verified in more than one tenant at the same time. This adds an additional level of complexity when the release of a domain lies in the hands of a hosting provider who doesn’t necessarily want their customer to cancel services.
Access to a Global Administrator account is typically required to successfully meet most tenant to tenant migration guidelines. Unfortunately, many Office 365 hosting providers will not grant such privileges to their customers or third-party technicians.
Administration Rights & Global Administrators
For the sake of tenant to tenant migrations, there are only a few unique points regarding administration rights and they will be repeated throughout the series:
- The top-tier administrative role in Office 365 is the Global Administrator. Global Administrators have rights to perform all actions in a tenant, like removing domain names and accessing migration data behind the scenes without password resets.
- Having access to a Global Administrator account is generally considered a necessity in order to meet most tenant to tenant migration project criteria of minimizing cutover times, data loss, service windows, and user impact.
- Often customers under syndication are not granted Global Administrator account access, thus adding complexity to migration projects.
Tenant to tenant migration can be thought of like moving your business into a new building.
Logistics & Moving Day
When it comes to tenant to tenant migration, you can think of the process very similar to moving your business into a new building. You will have physical assets, documents, and people who all need to be moved from one place to another, and they can’t exist in two places at once. Those considerations require a lot of planning and logistics to make them happen as quickly and as smoothly as possible so that you can all get back to business ASAP.
Almost all tenant to tenant migrations are performed as “cutover” or “big bang” migrations. With this type of migration, some things, like office furniture, can be set up in advance, but then you pick a final day where the whole staff moves to the new building at the same time. The cutover also refers to the actual window of time during which the data is moved and the final settings are reconfigured. Cutover usually requires a third-party migration tool to copy data from one tenant to another, and licensing fees will apply. Once the move is under way and everyone can confirm that the old tenant is no longer of any use, user computers and mobile devices will need to be reconfigured, either manually or in some sort of automated fashion.
What about DNS, mail flow, and OneDrive? Aren’t you leaving a lot out?
There are many other specifics that relate to identity and data migration, but they go beyond the scope of what this series is trying to achieve. While I will visit basic mail flow and data migration scenarios as they relate to tenant to tenant migrations in later articles, I believe there is already plenty of material out there covering those topics in the same level of detail that I would be able to achieve here, ad nauseam.
Key Terms & Definitions:
Tenant – In the case of Office 365, this term describes a single, unique, free, cloud-based environment for controlling Office 365 users, services, and data. A tenant is a customer account, a management portal, and a dynamic platform for enterprises to grow their business. A single tenant has the potential to host services for multi-division enterprises made up of tens of thousands of employees who require complex collaboration systems. Features are determined by licenses purchased.
Syndication – Microsoft has partnered with many hosting providers to sell Office 365 as a prepackaged product & service suite. When a customer buys a subscription to this suite, they get access to a tenant, licenses, and intermediary administrative support from the host. This is different than Microsoft resellers who simply sell Office 365 licenses to customer who want to set up their own tenant. Typically, customers who buy into these agreements lack full administrative rights to their tenants, thus adding complexity to tenant to tenant migrations projects.
Initial Domain – A free subdomain established during tenant configuration used to uniquely identity and route data to and from an Office 365 organization. Often referred to as a “routing domain” because it allows user data to be migrated tenant to tenant even though user accounts do not have proper company usernames or email addresses assigned. It can be troublesome, however, because it cannot be changed. Example: ssaas.onmicrosoft.com
Custom Domain (Vanity Domain) –A domain purchased, owned, and controlled by an Office 365 customer, which can be verified in a tenant for the purposes of branding, mail flow, etc. Example: Tenant ssaas.onmicrosoft.com can host user email@example.com if ownership of the strategicsaas.com custom domain is verified.
Domain Verification – The process of altering public DNS records so that ownership of a Custom Domain can be verified by Office 365. This is done so that a Custom Domain can be used in Office 365 for branding, usernames, email addresses, and other services. A custom domain can only be verified in one tenant at a time, adding a level of complexity to tenant to tenant migrations.
Team Site – The primary root URL of a tenant SharePoint Online site. For example, domain ssaas.onmicrosoft.com would have Team Site URL https://ssaas.sharepoint.com, but this cannot be changed once it has been established. Changing a Team Site name is a primary reason for many tenant to tenant migrations.
Global Administrator – The highest level of administrator available in an Office 365 tenant. This level of administrator has the access necessary to successfully execute a migration of any type, including tenant to tenant, but often tenants under syndication are denied this role, thus adding a layer of complexity to projects.
Cutover – Refers to a type of migration and the act of moving from tenant to tenant. A “cutover migration” requires that all data and settings move over at once after pre-configuration of the new tenant has taken place. “The cutover” is a window of time in which services may be down for users while data moves and settings are changed.
Migration Tool – A third-party tool designed to copy data from one tenant to another. They are used to minimize migration complexity and data loss. These require licensing fees.
Identity Management – The “who” of IT infrastructure planning and administration. This refers to users, contacts, security groups, email lists, and any other objects in Office 365 (or IT organizations in general) to which licenses and security/authentication can be applied.
Active Directory – Refers to on-premises Active Directory Identity Management technology. Identities from Active Directory can be synced to a tenant using AD Connect or any other directory synchronization tool.
Azure Active Directory (Azure AD) – Microsoft’s cloud-based Identity Management technology. Azure AD handles all Office 365 Identities for a tenant and acts as the connection point for Azure AD Connect and other directory synchronization tools that are configured to sync Active Directory identities to the cloud.
Azure AD Connect – A free Microsoft tool used to sync local Active Directory users to Azure AD. Users that get synced can then be licensed and managed in Office 365.