Dynamics 365 and Office 365 in different tenants – How to consolidate !!

We have run into many scenarios where a company has Office 365 and then orders Dynamic 365 from a CSP (Cloud Service Provider) and their systems end up different tenants.  As Microsoft moves to the model where there can be more than one partner of record and various flavors of Dynamics 365 (Finance and Operations, Business Central, Customer Engagement, etc..),  I can see this problem getting more prevalent over time.

When your Office 365 and Dynamics 365 are in different tenants it becomes quite the challenge and inconvenience.   A few major issues are as follows

1. Server-Side Sync – only supports single tenant.
2. Single sign-on – need to log into two systems.
3. Two systems to manage
   1. Users
   2. Licensing
   3. Notifications
   4. Double the security concerns
   5. Double the competencies efforts
   6. etc… 

You say, heck this is easy, let’s just move our Dynamics 365 to the other tenant.  If it were on Premise it would be a couple of days work tops.

Hold one second.  This is not quite so easy with online tenants.   Microsoft has a process that takes time and they are currently swamped which makes the process slower than it should be.    Currently it is taking 6 – 8 weeks to get a tenant moved to the same tenant.  Microsoft does all the heavy lifting!!

Licenses are not transferred over

You cannot transfer licenses from one tenant to another.  You have to subscribe to the new licenses and then disable the old ones once the process is complete.   Chances are you might have to pay for two sets of licenses while the process is being completed.   Microsoft says you can start with a trial but chances are the process won’t finish in time for the trial to be converted to production.

As the admin of both systems, transferring data to the other tenant isn’t so easy but Microsoft will help

Since you don’t have access to the back-end, you cannot just copy the database from one server to the next, nor can you use a third-party tool to move the data.  You can export and import if you don’t need to keep relationships but most people don’t have that luxury or have tons of data.

Lucky for us, Microsoft has a specific service to help you with this process.

TENANT MERGE INSTRUCTIONS

Email the following address  colmerge@microsoft.com.  This goes to Tenant Merge Team at Microsoft Business Operations

You will receive an email back from Microsoft assigning you a “Transition Manager”.

Your transition manager will send the below high-level instructions.   NOTE: You will need to create an ID for Microsoft in your Office 365 or destination tenant with GLOBAL ADMIN rights. 

High Level End to End Process for Transition:

1. Customer adds Temporary Global Admin user in the destination tenant.
2. Customer sends login credentials to their transition manager.
3. Transition Manager creates D365 trial under destination tenant.
4. Transition Manager maps all users and runs validation. If errors are found, Transition Manager will work with customer to resolve.
5. Customer purchases new subscription within the destination tenant.
6. Transition Manager contacts customer and schedules a transition date.
7. Transition Manager performs the migration.
8. Transition Manager cancels and credits previous subscription.
9. Customer reconfigures any external plug-ins such as the Outlook Client, Scribe, etc. to utilize new login credentials.  
10. Customer removes Temporary Global Admin user.

Optional Post-Migration Steps

1. Customer renames users in source tenant to utilize default “.onmicrosoft.com” domain.*
2. Customer removes vanity domains from source tenant.**
3. Customer adds vanity domains to destination tenant.
4. Customer renames users in destination tenant to utilize vanity domains.
5. If users are synced to AD, then SMTP matching should be used to prevent duplicates.
6. CRM admin informs users of new credentials.
7. Customer reconfigures any external plug-ins such as CRM for Outlook, Email Router, Scribe, etc. to utilize new credentials.
8. Customer removes Temporary Global Admin user.

*The only users that need to be renamed are the users that are utilizing domains that you would like to move to the destination tenant.

**You only need to remove the domains that you want to move to the destination tenant.

Let’s get started!

Step 1:  Add Temporary Global Admin in Microsoft Online Portal:  https://portal.office.com/Admin/Default.aspx

1. Navigate to https://portal.office.com/Admin/Default.aspx
2. On the left side of the page, click Users and then click Active Users.
3. Click + Add a user.
4. Enter the following user details:
   1. First name: Transition
   2. Last name: Manager
   3. Display name: Transition Manager
   4. User name: TM, select [YourCompany].onmicrosoft.com from dropdown.
   5. Click Roles dropdown menu.
   6. Select Global administrator.
   7. Toggle off any pre-assigned licenses. (You may be required to assign a license. If this happens choose any available license and unassign after creating user.)
   8. Click Add.

Notate username and temporary password

BASICALLY, it is only a few steps

1. Email Microsoft
2. Create a temporary Global Admin account in the destination tenant to give to Microsoft
3. Purchase appropriate licenses in destination account
4. Create users in Active Directory and Dynamics 365
5. Give Microsoft the go-ahead to move the data
6. Be patient and wait for them to finish their process
7. Once the move is done, the old environment does not exist anymore

APPENDIX – Below is the disclosure they give to ensure there is no misunderstandings

1] The transition process is 1:1, for every instance of CRM Online that will be part of the process, a destination instance (or placeholder) needs to be in-place on the destination tenant. We’re unable to pick up an instance and place it elsewhere. The placeholder acts as a target.

*Depending on your source tenant billing, if Enterprise Agreement for example, we can coordinate an exchange of information you will need to: create a Billing Support Service Request from the source tenant where you’ll request a PCN Tenant Remap. This request is an official declaration that you are requesting a “mirror” (or copy) of your source tenant CRM resources into the destination tenant. So, if you have 4 instances, 250 licenses and +25GB of storage on the source tenant the Commerce Team will mirror those entities onto the destination tenant. The source tenant resources will go into a 90 day GracePeriod, everything will still be active but we have that 90 days to complete your merge request. Once all instances are transitioned we can let the 90 day Grace on the source expire normally because billing is active and running on the destination tenant. No further billing action will be required from there on.

If you’re on a Microsoft Partner Benefit Offer, you’re advised to log in to the MPN Portal and request a transfer of your licenses to the destination tenant.

If you’re on a Direct (credit card or invoice) billing set up, you’ll want to establish a CRM trial on the destination tenant. Activation of the trial will be required closer to the agreed upon transition date and time. This is also required if your licensed User count exceeds 25, storage is greater than 5GB and if you’re requesting a move of more than one instance of CRM. Essentially, you want the exact CRM resources on the destination tenant that you currently have on the source tenant.

 2] The URL of the source CRM will come with in the process, example:

Source = instance-a.crm.dynamics.com
Destination = instance-b.crm.dynamics.com
Post-transition Result = instance-a.crm.dynamics.com

 3] Tracking back to the 1:1 of the process, this includes storage, GB for GB, you’ll want the same if not more in the destination to accommodate the data coming over. Users are the same, for every User that will be mapped from the source an existing or placeholder account in the destination needs to exist, example:

Source = user1@sourceinstance.com
Destination = user1@destinationinstance.com
Post-Transition Result = user1@destinationinstance.com

*In this example, the destination ID should be observed as what the User will have for an ID post-transition. If SSO/ADFS are to implemented or in-effect on the destination, you’ll want to ensure during the staging process that the mapping file destination ID is your UPN.
**You’ll want to ensure that pre-transition, your Users are also licensed for CRM in the destination tenant.
***Users on the destination tenant need to have a license assigned, this eliminates any post-transition access issues as the entity of “a license assigned” on the source tenant does not transition over.
****Enabled Users on the source tenant should remain licensed for CRM Online at all times. To include going into the official transition(s).

 4] User Mapping, this is an XLS/CSV consisting of 2 columns: Column B contains the source ID’s, Column C are those same Users but their IDs on the destination. It’s a process of mapping B to C. For multiple instances of CRM being transitioned one mapping file per instance is required. Each mapping file should contain only the Users that access the respective instance, a mapping file for Instance #1 should only contain the source and destination IDs of the Users that presently access Instance #1 pre-transition and will continue to access that same instance post-transition. It’s key to note that a single ID can access multiple CRM instances in the same tenant, so it’s not uncommon for them to appear in multiple mapping files or be transitioned more than once. A parallel note to that is if one User is part of 2 instances and we transition one of those two instances that User’s activity/data/records for that specific instance are what is being moved. They’ll still remain in the source tenant after the first transition is completed because they access another instance in the source as well. Once we transition that second instance that same User’s activity in THAT instance are then moved.

*Users that are indicated as “omit” from the mapping file, Disabled Users for example, if they have data/records assigned to them they’ll be mapped over and settled into the destination as Disabled Users in order to retain any data/records assignments (to not orphan ownership).

**If the Disabled “not found” are desired to be moved over (anticipating a return of one or more individuals in the future) unique destination accounts should be created and exist in the destination tenant to map-to. Those ID’s should be put into the XLS for re-validation.

***When inputting data into the highlighted column, as requested by the Transition Manager, the destination ID’s should be unique. The transition cannot perform mapping if duplicates exists.
-We cannot map 1 source ID to 2 destination ID’s
-We cannot map 2 source ID’s to 1 destination ID.

****New Users created on the destination side/tenant will need to be informed of their temporary system-generated password (where applicable), this is common in transitions where a .onmicrosoft.com (or CloudID) is to be the destination ID for any source User.

*****A transition requires at least one user to map. This is by design. We cannot transition instances without that minimum single user. This User should also be a confirmed/licensed (existing) CRM user to avoid any further issues or potential transition failure.

5A] The transition process is a one-instance-at-a-time execution. We will not commit to running more than one at the same time. Citing that, we can certainly run multiple transitions in the same day. Once one completes we can kick off the next and continue in that cadence. With each transition, the instance being moved is taken offline. It’s ideal to inform Users that CRM will be unavailable during the still TBD date/time of each instance. Once completed it will be republished and back online. The average time start to finish is (lowest) 10 minutes to (highest) 60 minutes. Instances carrying a wealth of customizations or are “storage-heavy” will be on the high side due to the data/records resync process.

5B] Rollback process: In the event of a failure during the transition, the system will enter a rollback process. The rollback is the process of undoing everything, reverting the process, like nothing was ever touched.

The first task the system performs in a transition is a full backup of the instance/Users/DB at that time. Those backups are used to put the source and destination instances as they were pre-transition. Once the rollback is completed, both instances are brought back online. While it’s in the rollback, though, the Transition Manager will be (in real time) seeking out the root cause of the transition failure. This is to determine if the mitigation can be self-serviced (by the Transition Manager) for an immediate re-attempt once the rollback is complete, or if the Transition Manager needs to gather all findings to submit to the Engineering Team for their intervention.

Please, note that Engineering Team will not be able to provide any workarounds on-the-spot. This path requires investigation. That will be a few days at least. Communication from the Transition Manager during this time will be frequent, whether it’s the mitigating the root cause on the spot and making another attempt (that same day) or if Engineering needs to look at it further based on the error information provided by the Transition Manager. If (again) it goes the route of Engineering Team, the CRM Users will be able to utilize CRM Online as they are presently until the investigation is completed, a workaround is provided and we reschedule for the next attempt. If no failure takes place and the transition is completed successfully, all Users will be able to log in to CRM Online (example: the next day).

6] We schedule transitions per the Central US time zone. We do not have the needed Engineering support readily available (in case of an issue during transition) outside of our 8am-7pm M-F windows. Please observe that when scheduling transitions.

7] The most critical aspect to convey is that a transition, once started, is a move, not a copy. No remnants of the instance will exist in the (previous) source tenant. We are picking up an instance of CRM Online, its Users and database, targeting a placeholder instance of CRM Online in another tenant and overwriting that.

As more modules come out for D365 and allowing multiple partners, I can unfortunately see the multiple tenant issue getting worse before it gets better.    Microsoft is doing their best to keep everything in sync but it is a hard.  As the CDM (Common Data Model) gets more traction, the same tenant is going to be that much more crucial. 

One note, is to ask you CSP (Cloud Service Provider) to ensure that they are created in the same tenant before proceeding.