Picture yourself in this scenario: your organization has been using Office 365 for a few years, and adoption levels with your end users have been fantastic. Your organization is utilizing all of the collaboration tools Microsoft has developed to the fullest and your footprint in the cloud begins to grow every day. As the business begins to grow, however, change becomes inevitable. Whether that is an organizational name change, the purchase of another company, or the merger with a competitor, that change requires some flexibility out of your usage on Microsoft’s cloud. It all starts with your organization’s Tenant.
A Tenant is your siloed existence on Office 365 Azure Active Directory. Consider it, if you will, your Cloud internal domain name. All data and services used by your organization’s staff is stored within the walls of this Tenant. Moving data from this Tenant (Exchange Online mailboxes, SharePoint Online content, Skype for Business Online message logs, etc.) should be taken with the same type of cutover approach used for moving data from on-premises technology into Office 365 from the start. After all, a Tenant is essentially just your environment in Office 365 and is wholly separate from the new Tenant that you would be migrating to. Tools will be configured, and data will be transferred. But this is the easy step.
Vanity domains (as Microsoft refers to them) are the custom routable/SMTP addresses used by the organization for any public interaction (email, messaging, and authentication). As part of your original migration to Office 365, you would have confirmed ownership and integrated use of the domains in one or a few different ways. One way was using DNS specific records—like MX, SIP, or CNAME—in order to carry traffic for that domain to Office 365 for services like Exchange Online or Skype for Business Online. Another way was integrating your Active Directory Domain into Office 365 for authentication and synchronization based off the AAD Connect tool and associated services. These are all services that you would have considered a requirement when moving to a new domain—and rightfully so. Office 365, however, is not as flexible when removing an integrated vanity domain as it is when you configure it from the get go.
When a domain is removed from Office 365, removing an MX record to an SMTP address—or disabling AAD Connect from your AD Sync Microsoft—will require a period of no less than 72 hours (and potentially more) to elapse before that domain is able to be used again in a different Tenant. This would, at default, require at least three days to pass before your new Tenant is able to be used fully by your organization. Considering this drawback to an increasingly common migration scenario, Connection has partnered with organizations who have developed tools to help automate the domain association process to ensure that downtime is kept to an absolute minimum. If you are considering the switch to a new Office 365 Tenant, for whatever reason, reach out to your Connection account team. We will help develop a migration plan to minimize the downtime you would experience.
Patrick Renzi
Patrick is a Solution Architect for Microsoft Cloud Services at Connection. He specializes in Microsoft Office 365, Intune and Azure Active Directory. In his free time, he enjoys Skiing, Golfing, Gardening and Hiking.
One thought on “Tenant-to-Tenant Migration: What You Need to Know Before Making the Switch”
“no less than 72 hours (and potentially more)” is incorrect. It could take up to 72 hours. Depending upon your skill level, preparation, configuration, and the number of objects in your directory, it realistically takes 4-15 hours for most mid-size businesses from my experience.
Comments are closed.