Best Practices for Microsoft 365 Domain Moves

Good afternoon, everyone. I'm Richard Dean, Senior Manager of Technical Product Management. I'll be introducing Lenny Yu, product owner and Senior Technical Manager. And today we're going to do a deep dive into the five best practices of tenant to tenant domain consolidation. So what's on the agenda today? So first I'm going to try to answer for you why do customers have multiple tenants. Next I will try to answer for you what is a domain consolidation so everybody understands what we're talking about. After that, I'm going to talk about the business drivers for domain consolidations. I'm going to briefly go over the known challenges we've identified over our years of practice. And I'm going to briefly talk about when should things actually occur? What is the migration path and planning path? And then finally I'm going to hand it over to Lenny that's going to do the top five best practices for planning domain consolidation. So why do customers have multiple tenants? It's a good question. So did you know in 2020, Microsoft stated that over a third of administrators manage multiple 365 tenants every single day. Over one third. And over a half of enterprise customers E3, E5, manage multiple 365 subscriptions every single day. So why do customers have multiple tenants? What are those reasons. First and foremost is data sovereignty. So an organization requires that certain data be kept in a certain location for regulatory and requirements reasons. So simply that they need the data in a certain location because it's perceived as safer. The next reason would be autonomy. Many organizations operate in many different ways. For example, maybe an organization has many different business units in each business unit, acts autonomously, has their own IT, has their own Microsoft 365 subscriptions, meaning that the entire company as a whole has multiple tenants. The next common reason is proximity. Maybe you have a team in a remote location that requires better connectivity to their tenant and you've identified this as a problem. So either you have to purchase a new subscription to move them to that tenant that's closer to them or move them physically to another location. The next good reason is research and development. No matter what your organization does, there's always time and reason to have multiple tenants in place, maybe non-production tenants, that actually you're using for testing and design purposes. And then the final reason, the main reason that we're going to focus on today is mergers, acquisitions, and divestitures. You can imagine a company acquires another company they acquired all the data they required all the resources. And that means they also acquired the multiple or manage multiple 365 tenants. So what is domain consolidation? So what is domain consolidation? Domain consolidation, simply put, is the transfer of one exchange online accepted domain to another. That's it. So you're moving or transferring the email domain from one tenant to another, it's as simple as that. However, domain consolidation is just one small part of the larger general project of moving or consolidating a tenant. So you have to consider while the domain consolidation is very complex, the overall project is very complex. And you're going to have to determine what are those pieces that need to happen in what order. So before I go on, I wanted to give you illustrate for you a common example of a typical M&A journey for an organization. So here we have Ampla Enterprises who was established in 1999. About 40,000 users and they live across two tenants right now. So they're working fine. But in 2021, they went through an M&A sprint and they purchased Parvus, it's a competetor of theirs. About 2000 users and they acquired another tenant. They did the same thing in 2021 with Dadas Research. They added another tenant, another 4,000 users. And then they finally wrapped up that M&A sprint by purchasing Scientia Tech in 2022. They added another two tenants in Azure and picked up another 4,000 or so users. So now Ampla is spread across five tenants, 5 continents, sorry 6 tenants, 5 continents, 25 domains, and approximately 50,000 users give or take. So they're going to have to come up with an M&A journey and strategy. So let's go through that. So ambitious transformation strategy. So they've decided to take Parvus, their competitor, and consolidate them so they're going to migrate all the users, all the data, all the domains. And that results in a market consolidation and an expansion of their portfolio of services and software products. Next, they're going to take Dadas' research and divest five properties or brands domains and about 2000 of their users and then migrate the remaining of it into their North American tenant. Resulting in Dadas transforming into a new department within Ampla for research and innovations. Next they took Scientia Tech and consolidated both of those tenets into the European tenants. Resulting in a merging of Scientia into the products and engineering departments. So Dada Scientia is born. So we completely transform the company. We've consolidated everything. We're now down to 2 continents, 2 tenants about 20 domains, SMTP domains, and a little under 50,000 users. So you can see this is a complex process right? It's lots of moving parts. Much to consider and plan for, one of which is just the domain consolidation overall. But in the bigger scheme of things we have to also plan for the entire tenant consolidation if that's part of your exercise. So what drives domain consolidation? What are the business drivers for companies consolidating today? I have to take I have to pause and say that not only is this a domain consolidation, but in many cases, you're going to find that a domain consolidation is being driven by the tenant consolidation itself. There are instances like divestitures where maybe you just split off a portion which you could take some domains and some users in some of their data, and that tenant stays in place. But in most cases, that tenant consolidation is going to also drive domain consolidation. But the first driver is always in most things is cost, right? Every organization wants to reduce costs. They have additional subscription, they have ongoing maintenance they have ongoing administration. And just general overhead of managing multiple tenants across the globe can be very costly. So that's one of their drivers. They want to reduce costs. The next major one is branding. Today, many organizations or organizations can't share domains between tenants. So what they end up doing is consolidating a tenant. So they have to take those users and move those and those domains and move them into one tenant so they can all have the same email domain. That may change in the future. But for now, that is a key driver for tenant consolidation. The next thing is just purely efficiency. Customers want to be more efficient. They need to reduce their costs, they need to reduce their risk, they need to reduce complexity so that they can be more efficient as an organization. So it's always a driver to be more efficient within an organization. And if that means condensing and consolidating a tenant, then that's what it will be. The next driver is risk. Risk and exposure. The more infrastructure you have, the more attack surface you have. And the more attack surface you have, the higher risk you're at. So if you reduce that or consolidate those tenants, you're essentially reducing that risk. Complexity. Managing, maintaining, securing multiple tenants. And most tenants are hybrid tenants so that means you're also managing a Hybrid Active Directory Forest and that could be many forests. And then on top of it you're also managing the SMTP domain topology. None of that is easy. It's none of it is inexpensive. And it takes a lot of different tools and it takes many skilled engineers to keep those systems running. So having multiple tenants and that level of complexity can be a key driver to consolidating those tenants. And then the final one is obsolescence. Simply, resources are no longer required. Maybe you had tenants for testing purposes in laboratories or compliance reasons, and those are falling out of favor. Maybe you had a brand that's no longer a brand for you so you want to consolidate those. So any obsolete features or systems, those you want to eliminate, and those can be common driver for domain consolidation. So what are the known challenges? So what are those common obstacles that we've seen in our experience? First and foremost is the complexity of these projects. I've mentioned it here previously, I'll continue to mention it. These are very complex projects and you have to keep in mind that this is only one portion of a larger tenant consolidation, which would include migrating identities, migrating resources, migrating data, migrating applications. All of those pieces and the domain is just one small part. And you have to decide when that domain is actually going to migrate versus the actual resources itself. So one of the core obstacles the challenges of actually executing one of these projects is that they're very complex. And if you haven't done them before, they're not always easy to identify those complexities. The next thing is downtime. And when I say downtime, I'm talking about email downtime. It is inevitable that you are going to have email downtime. There are services out there that do address rewrite. Of course, those cost a certain amount of money and they have their pros and cons. But in terms of actual domain consolidation when you're planning one, you should plan for downtime. And the reason is when you remove a domain from a tenant and then actually add it to a tenant, there's a limbo time, a time when it doesn't exist in either. And when it doesn't exist in either of them, mail cannot flow to the intended mailbox. So you have to plan around downtime. And we're going to get more into this and Lenny is going to get more into this. The other big obstacle or challenge is that this process is very manual. There are very little native tools at all to do this. You have to manually step through it and control everything. If you want to try to mitigate all the manual steps involved, then you've got to move into scripting. That means you have to add a particular skilled person to your team that's going to be executing this plan that can script and automate this as much as possible. And then if they are going to go down that road and try to script this as much as possible, you're going to need privileged access. Some of the portions of this process require a global administrator. So you're going to have to plan for not only scripting it and testing it, but also what levels of access do I need for certain pieces of it. Because not all pieces need global admins but certain pieces as well. And if you're doing things like Hybrid Active Directory you're going to have to have permissions to touch those objects as well. So there's a lot of different privilege permissions involved in this process. And then the biggest challenge that I would say is dependencies. You're talking about app dependencies, any dependency you have in terms of dependency on that domain. For example, you could have an app that authenticates to this domain to capture your data. It may be it's a business critical app and you weren't aware of it. And then you downed that domain it can no longer authenticate it, can no longer perform its business critical function, and you've caused downtime for your organization. So understanding the challenge or understanding the dependencies is going to be paramount. And again Lenny is going to get more into this. So when should things actually occur? And so what are those steps? We've briefly identified a five phase process of actually planning and executing your domain consolidation. I will briefly go over these. Lenny is going to deep dive into these. First and foremost, you have your analysis. This is where we're going to gather our data our inventory, recognize our dependencies, talk to our business, identify the risks and limits of where we're at. Once we moved into analysis, then we move into planning and strategy. We're going to decide what kind of end user experience should we expect? What kind of downtime do we have to have? What are the implications of service accounts? How am I going to, when am I going to move the domain versus when am I going to move my users? After I've analyzed the data, I've strategized on how it's going to be executed. Now I'm going to go test the plan. I want to actually pilot it. I want to trial it. I want to trial the communications. I want to validate that the process that we put in place through analysis and strategy is correct. And then I want to tweak it and refine it. Next, I want to execute it. This is the go no call team where we actually execute the entire process. And then finally, we remediate. This is where we validate that the process was successful and that all systems are working, and that we communicate the end result to the stakeholders. So now I'm going to hand it over to Lenny and he's going to deep dive into the five best practices. Thank you Richard. My name is Lenny. I'm a senior product owner at Quest Software. Part of the R&D team that's developing solutions for customers doing my intended to 10 migration for their domain migration, directory syncing, and also migrating their device to Azure AD. So today I'm going to talk about the five best practice as Rich has mentioned. So with any type of a project planning or doing a project, and like the one that we're talking about right now is domain migration, the key ingredients to have a successful project is to have a good planning. Now to have a good plan, we must have a full understanding of our environment. The reason is our production environment could be with us for years and we have gone through many changes. And these changes are so much that we need to record them, we need to do an assessment so that we know what they are. So before we begin the migration planning, so it is always to start by assembling a big picture of the environment so that you can have a holistic view to the tenant that you are working with. And that holistic view will be the first step towards a good migration planning. Now over the years, Rich and I have come up with six areas of focus areas that we believe we should all follow during the planning phase of the domain migration. So let's take a look at them. First, we shall always assess the tenant and generate a comprehensive report, inventory report. Second is we need to identify all the dependency related to the third party application that is utilizing the domain that is being transferred. We shall also plan for hybrid organization that is using a federated authentication or we have some type of email system located on prem that is being communicated, that is being used to transfer mails to the cloud. We should also review our Directory Sync tools and when we're working in a hybrid environment. Now as Rich has mentioned, in order to remove the domain we have to ship all the address domain address from all the objects. Now if we're working with a hybrid environment is imperative that we remove the domain reference on the local ad first so that they can synchronize to the cloud. So that is why it is important to review the Directory Sync. The next true area of concern is related to your business continuity requirements. And after we review the continuity and requirements for your business we should then rank the risk and the limitation that may impact our businesses, core business operation. Now let's take a deep dive in each of those focus area. Inventory your tenant-- always assess the tenant and generate this comprehensive inventory report so that you can understand the domain footprint to all your objects within your tenant. Now, this report should include all the users, groups, and teams. This report should also have some type of a category-- you should also categorize your objects in this report. What I mean by categorize is, not only categorize them based on their object class so that we know what type of object they are, but we should also categorize based on their location, whether we're working with Cloud objects or whether working with a remote object that is being synced to On-Prem AD to the Cloud. Also, when we're removing the domain from a tenant, the domain name needs to be removed from all of the attributes. Some of these attributes are email, UPN, and SIP. Unless we remove them or unless we remove them from all the objects, we simply cannot remove the domain from one tenant and transfer it to another. The last thing we need to include in this report is the Orphaned Objects. Now, what I mean by Orphaned Objects is sometimes, based on our experience, the project that we have done in the past where we have seen certain objects have male attributes. They have email address, proxy address, they may even have a male attribute stamp. However, when we are looking at them in Azure AD Portal Exchange Online, they are not being reported as mail-enabled objects. Because they are not mail-enabled object, we won't be able to use Exchange Online PowerShell or Graph to remove the domain reference from the object. So it is possible that you may having end up to remove them completely from the tenant. And having them in the report will help you to communicate this information to our team member so that they're not going to get caught by surprise when some objects are being deleted from the tenant when we're trying to move the domain. Now, after we come up with a comprehensive report, we should then take a look at the tenant's Hybrid setup and also it's Directory Sync. Now when we're working with a hybrid tenants, we should take a look at what kind of synchronization tool it's using. They may be using Azure AD Connect or they may use a MIM. And we need to understand what type of Azure AD Connect topology that we're working with. Is this a single forest, single tenant setup? Or this is a multiple forest and a single tenant setup? So these are the things that we should capture in our inventory report. Second is we should always plan for a Hybrid organization that is utilizing a Federated Authentication Service for their users. One of the example is we could have Active Directory Federation Service configured and also have single sign-on enabled for our users to log in to the tenants. Now, if one of the requirements for the project is that we need to make sure the user will continue to have access to the source tenant for some period of time, then we, most likely, will have to modify the ADF configuration in order for those to continue to work. Another thing we need to review, as part of the Hybrid Directory section, is we need to take a look at the Azure AD Connect filter. As mentioned before, when working within a Hybrid environment, the changes that need to take place is going to actually be on your local AD part. So we want to make sure there isn't any filter in place that may prevent whatever the changes that you're making to your local object being synchronized into the Azure AD. Third, we should also take a look at On-Premise Active Directory Topology. Some of you may ask, when we're moving a domain from the tenant, where we're working with the Cloud environment. Why do we care about local AD? Well, when you're working a Hybrid environment, as mentioned earlier several times, that the change actually does take place in the local AD part. You have to remove the domain from your local AD object for Hybrid, remote Hybrid setup. Therefore, you want to make sure whatever the tool that you are using or whatever the automation script that you're using will have complete access to the AD. And in addition, you want to make sure there is any type of AD replication issue that, where you're making changes to domain controller one, however, whatever the changes are making to domain controller one, isn't being replicated across the entire forests, which may, ultimately, prevent the changes being synchronized to the Cloud and prevent you from removing the domain. The last thing we should also look at is the synchronization rules. Some of us maybe have some type of a special attribute transformation rule in place. And you have those types of things in place, we want to make sure we review them so that they're not going to prevent the object to be updated in the Cloud. And we have personally seen in the past where, when we were helping the customer to migrate domain name from one tenant to another, there are attributes that we're trying to make and update, change simply isn't going to the Cloud because they have some type of special transformation in place. So therefore, these are the information that we must review as part of our Inventory Assessment Report for our Hybrid tenants and Directory Syncs. The next thing we should take a look at is application dependency. We have to remember email is not going to be the only system that is depending on a domain name. There are other component in the system that's also relies on the domain name. And each of these, the domain's functional, actual functional role is going to be different based on the application that we're using and also based on the business. So one of the examples we can use is, many of us are probably has been working in the area of the IT Administrators. Throughout our career, we probably have many scripts, apps, or service principles that we use to manage our day-to-day IT operations. Now, if we're removing the domain from the service principle, from the app that we're using, these application, or service principal, and the scripts is probably not going to be usable once the domain has been removed. So therefore, we need to plan a remediation to make sure that those accounts, scripts, apps will continue to work after we have removed the domain. Third-party applications-- depending on the business of origin, the company that working with, we may have a support ticketing system, or a CRM system that is utilizing the domain to send and receive emails. Now, as Rich mentioned earlier, during the course of a domain migration, email downtime may be unavoidable or something that we miss, take account into. So if the email downtime is not an acceptable outcome, then this will become considered as a business requirement that we must address during our planning phase. Otherwise, your business is can not function as they should during the course of a domain migration. The last thing we should take a look at on the application dependency is a legacy email system. Maybe you have some type of an exchange server 2003, if you still have it or 2007, 10, or maybe you even have a Domino server in your organization that is being used to transfer mail between the local AD, and also the Cloud, utilizing the very same domain that are trying to move. So you want to capture this information during the assessment phase of the project. Next, we should take a look at the business requirement and the risk. Now, each type of organization is going to have different business continuity requirements. It's often based on their business model, and also based on their regulatory requirements. So if I'm in a health care system, if I'm being a financial Institute, so it is probably going to be required for my company, or the organization we're working with, to have a constant line of communication open to our customers. And one of these communication could be email. So it is paramount to capture these input from all the stakeholders within your organization, or our organization, even sometimes, you need to also consult these things with people outside of the organization so that we can all understand the process that is required to move the domain and also understand the known technical limitation and constraint that will come with a project. Example is, email could be delayed or email may not work when the domain is being migrated. Or the single sign-on may not work during the domain is being migrated. So after we're getting the business requirement, we should then, take a look at the risk. Always rank the risk and the limitation that may impact organization's core business. Over the years, Rich and I had come up with four known risk limitation that all Microsoft 365 Cross-Tenant domain migration project would encounter. The first one, in general, all organization must decide if and how long the email downtime is going to be acceptable. If this is not an acceptable outcome, then we must think of as a third-party solution that will help you to relay or reque the message. Other common areas incur, things that we need to consider is when you're moving the domain from one tenant to another, most of the Microsoft 365 servers, such as email, calendar, authentication, hybrid directory integration, team meeting or SharePoint may be affected. Some of them may not even be accessible. So as a best practice, it's always recommended to do this type of migration during your off-business business hour. Now, when you migrate in data and contents across one tenant to another during our tenant-to-tenant migration, you can do that, the mail content and OneDrive migration, even when the user is working. But once we're working with a domain-mode migration, it is important to do that during off-business hour. Another thing we need to take a look at is when we're removing a domain. Depending on the scope of the project, some project may just say, hey, you know what, let me just remove all the user groups from my source tenant because I no longer need to use them. So if this is one the approach that you're taking, it's going to be a lot simpler. However, this is not the case in most cases. Sometimes you need to make sure your users still continue to use the source tenant resource or maybe it's by law, it is required for you to keep those objects around for a specified period of time because this is regulated. So if that is a case, then we must provide a replacement domain and stamp this replacement domain to all the objects in the source tenants. Now in a hybrid scenario, we probably don't want to put a Microsoft address against local objects because it's not going to work. So our recommendation is to choose a custom vanity domain that's going to be used for this very purpose. And use that to replace all the objects from your source tenants. Another risk is your desktop application. When we're doing the domain migration, depending on when the end user's desktop application switchover take place, if they were switch over-- if the switch was taking place before the domain migration or after, depending on when we do this switch, the desktop application may have to be reconfigured, or they may have to be re-authenticated. So if that's the case, we need to make sure we have communicated this to our help desk, and most importantly, our end user, so that they have a clear understanding Monday morning when they come into the office, they need to follow X,Y, Z, these series of steps to perform the desktop reconfiguration, whether it's re-authenticate it, or they will have to recreate the outer profile, reconnect their OneDrive or team. This process can be a manual process or, if they don't want to use a manual process, they can use some type of third-party solution to automate the entire reconfiguration process for them. So after we take a look at the inventory assessment report, the second best practice we want to take a look at is to actually formulating a strategy and also avoid some of the known pitfalls that may occur during the domain migration. So let's take a look at some of the pitfalls that we want to make sure we are aware of. Email downtime-- we have mentioned several times already, while a domain is being transferred, email cannot be delivered to the source tenant because all the address has already been removed from the objects, user teams, and groups. And also, the domain itself, will have to be removed from the Exchange Online as the accepted domain. So it also cannot be easy to deliver to the target tenant because account being migrated simply may not have the address domain, the email address, added at the time, nor the domain was added to the tenant as an accepted domain. So therefore, for our IT, our business coder, we must decide and determine if email downtime isn't acceptable during the transfer domain, as it may take several hours, or even take days to complete. It's purely based on the number of objects that you're working with, number of a domain that you're working with, and how large the environment is. So if email downtime is not acceptable, there are other solutions out there that can help you to relay those message. Because even if you try to say, let me put the MAX record into a non-deliverable domain, wouldn't these email be queued and will be delivered later on? Yes, that is true. However, if we do that, the user is not going to get the email until you restore that MAX. So if the domain transfer takes, let's say, 10 hours to complete, email is not going to deliver. So therefore, you can use a third-party solution to really those message during the domain migration. Service dependency, mentioned before as well, during the tenant assessment phase, we have already identified a list of the service accounts that is going to be using the domain that we are trying to move. So we should come up with a remediation plan. And a backup solution should be in place so that these accounts will continue to function once the domain has been moved. The third thing is the backup contingency plan. I think this is going to be one of the most important pitfall we should avoid in a domain migration project. Migrating a domain name space across two tenants has a lot of complexity. There's a lot of dependency around it. And it really requires a careful planning execution. But no matter how careful you're planning, no matter how careful you execute this project, things may go wrong. And they may not go as planned. And when that happens, the business may well come and tell you or say, hey the system is down. I need you to perform a rollback. I want you to report a domain migration and revert whatever the changes you have making into the original state. So if that happens, the administrator must take backup recovery into the consideration during the planning phase. Having a well-documented process that can be used to perform the rollback in the event domain what migration needs to bore is going to go a long way to ensure the successful project execution. And we speak this from our experience. Several years ago, we actually helped the customer to perform the domain migration using one of our system. What happened for this customer is, they actually did a very good planning. They did that inventory assessment. They have also identified all the dependency that is related to this domain. What they did not do, is they forgot to do two things. The first thing is they forgot to communicate all this to all the stakeholders. Some of the business stakeholders did not know that one of dependency may not work during the domain migration. The second thing is they don't have a recovery plan. They never thought about that things could go wrong. So what they did, is they just went ahead and started domain migration. And it was on a Sunday morning, 2:00, 3:00 in the morning, and they realized that something went wrong. Their help, their support system, started getting phone calls. And one of the third-party party applications stopped working. And the business realized this is actually very important. And they must perform the rollback. Now, they don't have a rollback plan in place, nor they have an AD recovery solution. So they were kind of in a limbo stage. So lucky for them, we were helping them to do the domain migration. We had the assessment report. We have the inventory for all the objects. So we were able to use that to write a script to restore everything for them. Now, if we weren't there, I don't know what they would do because their business wouldn't function. Because Monday morning, a couple of hours later, their user, it wouldn't be able to log in or that third-party application wouldn't work. So it is paramount to have a contingency plan in place in your planning. Another thing that we need to avoid is, we should also identify, is the point of no return. There's always going to be a time that, during the course of the migration, a rollback solution, a rollback, or an abort is simply not an option anymore. Maybe when the domain is already removed from the source tenant, it's already in a target, we just can't abort anymore. So we need to identify this point of no return and communicate this to the business stakeholder and the decision makers so that they are fully aware of it. Once we reach this milestone, domain migration cannot be aborted. It has to go forward, per the plan, and there can be no rollback. So having considered all these, as part of a planning, is important. Now, after we take a look at the pitfalls, and then, I think that we should take a look at in our planning phase. We need to define the desired experience. So there's a couple of things we need to look at. How do we want the source tenant to look like? Do we simply just remove the objects from the source tenant because we're not going to use it anymore and the tenant will be decommissioned shortly after? Or it is required for us to keep those objects in place, regulatory requirements, or maybe we still need to plan to use those objects even after domain has been moved to the target. If that's the case, then we must provide a replacement domain to all my source objects. And that replacement domain should be choose carefully. Don't use an all Microsoft address if you're working with a hybrid environment. You use a custom manager domain. And also, we mentioned already, decommissioning. What are we going to do with the source tenant? Do we just simply decommission it or are we going to keep them around because people are still planning to use it for some other reason? Now target tenant-- what are we going to do it out with our target tenant? How does the user in my target tenant is going to use this domain name? Are we going to use the domain name as their primary email address? Are we going to use the domain as the secondary? Or we're going to want to change our users UPN? So we need to decide what we want to do. Is everybody going to use the new domain that we move as primary or only a subset of the user? So this type of user experience thing, we need to define that in our planning. Next, we should take a look at how we're going to actually perform the cutover event. It this going to be a big-bang migration or this is going to be a multi-phase events that we're going to do? Now typically, in a big-bang migration, it's going to be, potentially, be the cheapest one. It's going to be cheaper than the multi-phase one because the business only have to do this once. They only have to do that once only. However, because we have to migrate users contents and desktop application at the same time, it's going to have a higher risk because there's less room for change. Example, if the content cut over is taking longer than anticipated, it's going to eating into your domain migrations window. So that's something that we need to be aware of. Now for phase and stage approach, obviously, it's going to be more costly, not only in the planning phase because we have to plan a multiple times, and also during the execution. Now the pro of this approach is it has much better risk mitigation potential because we have user content, application, and domain as a separate events, the risk will be distributed across evenly. Now, we're not going to take a side on either approach because both approach is right. But we need to understand the pros and cons of each approach. And the business will have to decide which one is more suitable for them based on their business model and business requirements. The third best practice Rich and I believe we should follow is once you have the plan, we should always put the plan into test. Let's test it out. Never put this the plan that you're drafted and go into production right away. That's not recommended. Test it first. So what we mean by test, is we want to pilot the entire process that you have come up with during your assessment and the planning phase. And test it using a temporary vanity domain. So as part of the trial, we need to make sure the trial domain, the test domain that you're working with, has set up all the objects that will exercise each of the third-party dependency that has outline during the assessment phase. So if you're working with Teams, and all 365 groups, you want to make sure you have test objects ready for Teams and also all 365 groups. Another thing we should do as part of the testing the PoC trial is communication. We need to inform the business stakeholders during each stage of PoC migration. The team could be related to your network team, their DNS team, local AD team. Because during the migration process, we have to tell them to do certain things. Example, we have to update the MX record. So we have to, then, reach out the DNS team. So all the business stakeholders should be available and we need to communicate that to them. Document-- We should document all the time that's going to need it for each stage to complete. That time it's going to be used as the metric number for us to come up with an estimation on how long this production, one, is going to take. Because at certain point of the project, the business is going to ask how long this process will take. And the only way we can give them that estimation is based on the metric number that we have captured during the PoC migration. Once the test-managed domain has been moved, we should perform the audit. We need to make sure the test-managed domain and its associated objects has been all updated correctly in the target tenant. Whether they need to have the UPN changed, they need to have the primary SNTP changed, everything need to be validated to make sure our process has updated everything correctly. And lastly, refinement-- We need to refine the migration plan based on the results that we have been receiving during the PoC. And also, we need to capture the feedbacks from the stakeholders and all the lessons have learned during the PoC so that we can incorporate those changes to our final planning for the real production migration. So the fourth best practice is related to the actual migration, itself. So we need to do is we need to now, after we have completed the inventory, we've reviewed the risk, we have tested the trial run, now will be a good time for us to assemble the team, and let's put the plan in motion. And let's just migrate this domain. So the first thing we do is we need to double and triple check the plan that we have drafted, and made sure the process and the strategies that we're using is a correct one. And then we need to include this review process with all the key decision makers. Scheduling-- mentioned before as well, we should always plan the cutover event, especially for domain move, during off-business hour. We do not want to do that during business hour, like a Monday morning or on a Friday, Thursday night. Let's not do that. Let's do it during a long weekend, or weekend time, or when there's a holiday. Do it during that time. Communication, again, is key component when we putting the plan in motion. Transparent communication between the migration team and the business cutover is key. We need to tell them, inform every stage of the migration. The last one is the Go and No-Go bridge. That's also important. All the members of the migration team, whether you are working on the directory sync side or your DNS team, they should all be available, including the stakeholders. And the final decision makers should also all be available in a bridge where we can communicate and reach out in the event that, like the story I mentioned before, that we have to perform a rollback. We don't want to start hunting down the decision makers when we try to do a rollback where we just can't find them. All these people should be available in a bridge that is readily to be accessible by the entire migration team. Last best practice we should take a look at is, what should we do after domain has been migrated? So the first one is enumerate. Just like we did with our source tenant during our inventory assessment report, we should also generate inventory report that will capture all the target tenants objects. We want to make sure all those objects have been updated correctly, just like we did in our PoC audit space. So that's something we need to do. Next, we should also validate and confirm all the mail is flowing all direction. There is nothing else that's going to prevent your mail being received and sending. And also repair any anomalies that may have identified. Some of these things could be, when you are moving domain name from one tenant to another tenant, you're probably going to update your UOP study, like the signatures, your OSPF records, and most recently, you're probably going to update your MTA-STS policy to make sure the mails are flowing. So these are the things that you need to do at this time. Communication, again-- at this time, once you reach this stage of the migration, you should tell all the stakeholders, and especially your end users, that the domain migration has completed, business has returned to normal operating state, that everyone should start using their target user accounts. You do not want your users to try to use their source old 365 resource and trying to access the email because they're not going to get any email. They're not going to get any updated OneDrive file. They should all start using the target resource. And lastly, decommission-- a lot of people will say, once I move the domain and my target, and my users are already using the target, my project is done. Not necessarily. The project is not done until you decommission the source tenants. So you need to decide when you want to decommission, whether you're going to decommission a tenant right away or you're going to decommission at the later time. And continue to allow your users to use the source tenants resource. So these are the five best practice Rich and I have come up with based on experience and the past projects that we have done in the past. So we hope that these best practices will help you in your domain migration project. Thank you. [MUSIC PLAYING]