Microsoft 365 FI (Formerly Kiosk) Users

To migrate to kiosk users, the migration project will need to be configured to use an admin account with impersonation rights. This allows us to bypass the limitations of kiosk users, who cannot connect directly via EWS.

To ensure that your migration project is correctly configured to migrate to kiosk users, perform the following steps:

• Specify admin credentials
  1. Sign in to your MigrationWiz account.
  2. Click the Go To My Projects button.
  3. Select the project that needs to be modified.
  4. Click the Edit Project button.
  5. Click Edit Project from the drop-down menu.
  6. Select Destination Settings.
  7. Checkmark Use Admin Credentials and enter these.
  8. Click the Save Project button.
• Enable Impersonation
  1. ​Click the Edit Project button.
  2. Click Advanced Options from the drop-down menu.
  3. Under the section title Destination: Microsoft Office 365, checkmark Use impersonation to authenticate.
  4. Click the Save button.

The admin account specified does not require a license and does not need to have other admin rights configured.

Impersonation

Impersonation in Microsoft 365

MigrationWiz uses delegation by default to log in to individual user mailboxes using administrative credentials specified on the connector. However, MigrationWiz also supports impersonation in specific environments.

Using impersonation:

• Eliminates most "Connection did not succeed" errors.
• Allows migration of more mailboxes concurrently.
• Reduces the impact of throttling and connection limits.
• Uses an administrator account without assigning a license to it.

To migrate using impersonation, follow the next steps:

1. Use admin credentials at the Destination.
2. Sign in to the MigrationWiz account.​
3. Edit the Project and click Advanced Options.
4. If migrating from Microsoft 365, under Source, check Use impersonation to authenticate.
5. If migrating to Microsoft 365, under Destination, check Use impersonation to authenticate.
6. Click Save Options.

MigrationWiz will automatically run a remote PowerShell command to allow the admin account to log in to (impersonate) user mailboxes.

Here is the remote PowerShell command we execute when a mailbox has been submitted for migration:

Enable-OrganizationCustomization
New-ManagementRoleAssignment -Role ApplicationImpersonation -User <admin_user_name>


You may also run these commands manually. This is useful if there are delays from Microsoft and the Powershell command does not run immediately.

Exchange 2010+

MigrationWiz uses delegation by default to log in to individual user mailboxes using administrative credentials specified on the connector. However, MigrationWiz also supports impersonation in specific environments.

Benefits

Using impersonation, sharing the throttling quota and connection limits associated with a single administrative account stops. Instead, the throttling quota of each user is used for each user's mailbox.

Using impersonation:

• Eliminates most "Connection did not succeed" errors.
• Allows migration of more mailboxes concurrently.
• Reduces the impact of throttling and connection limits.

To enable impersonation, please follow the steps below:

1. Use admin credentials at the Destination.
2. Sign in to the MigrationWiz account.
3. Edit the Project and click Advanced Options.
4. Under Destination, check Use impersonation to authenticate.
5. If migrating from Exchange 2010+, under Source, check Use impersonation to authenticate.
6. If migrating to Exchange 2010+, under Destination, check Use impersonation to authenticate.
7. Click Save Options.

For Exchange migrations, to enable the admin account to impersonate users, run this PowerShell command:

New-ManagementRoleAssignment -Role ApplicationImpersonation -User <admin_user_name>

More information about this PowerShell command can be found here.

Office 365 plans named "Business Essential" and "Business Premium" do support impersonation. Follow the steps above, under the Microsoft 365 section, to enable support for the use of impersonation when migrating from or to "Business Essential" or "Business Premium".

If the above Advanced Options are set to use impersonation on a project, these settings will only become effective for those migrations that are started after saving the settings. Migrations that are already running will be unaffected by any such changes.

Synchronizing Microsoft Entra ID 

The recommended approach is as follows:

Use this article from Microsoft for the most up-to-date information: Set up Directory Synchronization

1. Download and install ME-ID Sync or ME-ID Connect (if you need support for federation).
2. Set msExchMailbxoGuid to Null.
3. Configure filtering to define which objects are synced. Read the Microsoft Entra Connect Sync: Configure filtering article from Microsoft for more information.
4. Use Microsoft AAD Sync or AAD Connect to create and synchronize the accounts from the On-premises environment to Microsoft 365.
5. Assign Microsoft 365 licenses to accounts on Microsoft 365.
6. Remove the null attribute from the msExchMailboxGuid, using the Synchronization Rules Editor.
7. Perform another synchronization, using AAD Connect (or AAD Sync).
8. Migrate, using MigrationWiz. This step can also be initiated after Step 4, once the licenses have been assigned.

If the local Active Directory (AD) schema has not been extended to support Exchange, then the steps above to set msExchGuid attribute to null are not needed. Synchronization can be run in the normal manner.

If you have previously used DirSync from an environment where the local AD supports Exchange, you cannot set the msExchangeMailboxGUID to null, because DirSync does not support this. Therefore, we recommend that you instead use AAD Sync or AAD Connect to rectify this problem, by following the steps outlined above.

If you do not set the msExchMailboxGuid to null, before running a synchronization from an environment where the local AD supports Exchange, all of the On-Premises Exchange attributes for each user will be synchronized, including the MailboxGuid attribute. If users are created in this state on Microsoft 365, an Exchange Online license cannot be activated unless Mailbox Replication Services (MRS) is used to perform the mailbox move or the steps above are followed to rectify this problem.

Once the users have been created on Microsoft 365, and the licenses have been activated, then you can start using DirSync, AAD Sync, or AAD Connect in the normal manner. The problem is limited to the user creation and license enablement (when the local AD supports Exchange).

If the mailboxes are on an Exchange Server in the local AD, Microsoft 365 accounts can be created using one of the following methodologies. 

• ME-ID Sync or ME-ID Connect. Follow the instructions detailed in the recommended approach above.

• Manually, one at a time.

• By bulk import, via CSV file.

Licenses will also need to be assigned to the users, once they have been created.

Mail Routing

When Migrating Users in Batches

When migrating to Microsoft 365 using MigrationWiz, mailboxes need to be provisioned on Microsoft 365 to be able to write the content, mail, contacts, calendar, etc. (the user must exist on Microsoft 365 with an O365 license assigned to it, including a mailbox).

When a migration is performed in stages or batches, care must be taken to ensure that full mail flow continues for those migrated users.

This can be further explained by way of an example:

• John and Tom need to be migrated to Microsoft 365. They are in different user batches. Batch 1 will be migrated first. Batch 2 will be migrated second.
• John is in the first batch, gets migrated, and is using his Microsoft 365 mailbox.
• Tom is in the second batch. This batch of users will be migrated at a later date.
• When it comes to migrating users in Batch 2, these users will need to be activated on Microsoft 365 before migration since, as explained above, the mailbox needs to be active for MigrationWiz to migrate data into it.

What will happen if mail is sent to this newly activated Microsoft 365 mailbox while the migration is occurring?

If John sends an email to Tom, Microsoft 365 will internally route it to the new mailbox instead of the on-premises mailbox that Tom still uses. The email will not get lost since the email is stored in a mailbox that eventually Tom will get, but Tom will not have access to the email until the migration is completed.

How do we fix this?
The default mail routing can be manipulated by a mechanism called Criteria-Based Routing (CBR). Instead of dropping the mail in the mailbox on Microsoft 365, we can intercept the message and transfer it to the on-premises mail system, to be handled there. The interception is based on criteria similar to the membership of a specific Distribution List.

This is best explained by using the same example scenario:

• John was migrated to Microsoft 365 in the first batch.
• Tom is part of a Distribution List (DL) called NotMigrated.
• We have set up a CBR mechanism that defines the following:
  • If you are a part of the DL NotMigrated, your mail will be intercepted and will be sent to the on-premises environment.
• This way, when John sends an email to Tom, it will not go into the Microsoft 365 mailbox, but instead, be transferred to the On-Premises Exchange 2010+ environment.

Step-by-step setup:
For the setup, use PowerShell, because it is faster and easier to set up than working through the Microsoft 365 admin portal. If you need information about how to do this through the Microsoft 365 admin portal, contact Microsoft Support.

1. Connect to Exchange Online PowerShell.
2. Create the Distribution List (DL):
   New-DistributionGroup -Name "BtNotMigratedUsers"
3. Add All Users to this DL.
4. Create the Connector:
   $result = New-OutboundConnector -Name "CBRConnector" -ConnectorType OnPremises -SmartHosts "<fill smart host to source environment>" -UseMXRecord $false -IsTransportRuleScoped $true
   • -SmartHosts entry needs to be set to the URL or IP Address of the Source environment server.
   • On Exchange 2003, 2007, and 2010, this will be the address of the Transport server.
   • On Exchange 2013 and 2016, this will be the address of the Mailbox server, not the Transport server.
   • If the Source environment is Hosted, you would need to obtain this address from the Hosted Provider.
   • If the Source environment is G Suite, you would need to change the -SmartHosts entry to be the following: 
     -SmartHosts “aspmx.l.google.com”
5. Create Rule:
   $result = New-TransportRule -Name "PilotInABoxRule" -SentToMemberOf "BtNotMigratedUsers" -RouteMessageOutboundConnector "CBRConnector"

When a user is fully migrated, remove the user from the DL, and they will receive their email in their own Microsoft 365 mailbox.

There must be a mail-enabled contact on-premises for each user that has been migrated.

Coexistence 

Setting up Coexistence in Tenant to Tenant Projects

Microsoft 365 Tenant to Tenant Coexistence provides coexistence functionality for Microsoft 365 to Microsoft 365 migrations. When performing a Microsoft 365 migration and cutover is planned for a later date, migrations are done in batches. These migration types generally require coexistence so that the users on the source and destination can seamlessly communicate. This feature enables migrated users to be able to see the non-migrated users' free/busy status and their contact details.  

Migration can be completed in batches, but all the users need to be in the same project. Once a project is set up, users can only be added or removed from the source environment, then use the Rediscover Items button in MigrationWiz to sync those changes. Users cannot be manually added or removed from the migration project.

Setting up the Microsoft 365 Tenant to Tenant Coexistence

1. Launch MigrationWiz and create a Mailbox project. For help creating a new Mailbox Migration project, see MigrationWiz Projects.
2. Set up the Source and Destination endpoints as Microsoft 365. 
3. Enable Tenant to Tenant Coexistence by selecting the checkbox during the initial project creation.
4. Configure the Tenant to Tenant options.
   • Configure Domain Addresses: Enter the primary Source and Destination vanity domain names. The Source domain is optional and can be left blank. This will enable coexistence for all domains on the Source.
   • Setting Global Administrator Credentials: A Global Administrator account is required on both the Source and Destination endpoints. 
     

     Important

     The destination tenant Administrator account needs to be able to access MSOnline, so the account must use the .onmicrosoft.com domain to ensure the correct access levels.
   • Choose Microsoft 365 License: Select the Microsoft 365 License type to be used on the Destination.  When the mail-enabled contact is converted to a user account with a mailbox, this is the license that will be applied.
   • Migrate Distribution List and Groups: Select the groups that are to be included as part of this migration.  Changes to the Distribution Lists and Groups can be synced during the project. 
5. Click Save and Go to Summary.

Distribution List Changes

It is possible to sync changes to the Distribution Lists before a migration by using these steps:

1. Make your changes to the Distribution lists or groups in the Source Environment.
2. Click Tenant to Tenant Management.
3. Select Sync Distribution List.

Tenant to Tenant Migrations with Coexistence 

User Migration Bundle licenses are required for this migration. Only specific Microsoft 365 licenses are supported for this migration. The supported types are listed in the Migration Setup drop-down menu. Only one Microsoft 365 license type can be used per project and the Microsoft 365 license types cannot be changed once the project has been set up.

The migration can be completed in batches; however, all the users need to be in the same project.

Once a project is set up, you can use the Rediscover Items option in the Manage Tenant to Tenant menu to add/remove users from the project. The users must be removed or added to the Source environment before the Rediscover is used. Cloud accounts are created on the destination. User passwords will be created as part of the DeploymentPro Profile Configuration.

Microsoft Entra Connect cannot be used to do anything with the destination user accounts until after the migration project is fully completed.

Once the Tenant to Tenant Coexistence option is selected and the migration is saved, the coexistence option cannot be removed. It is recommended to make sure that the scope and time frame of the migration is known ahead of time.

All users on the source will be discovered to create mail-enabled contacts for those items on the destination. This migration type, therefore, is unsuitable for part divestitures from the source tenant. The mail-enabled contacts will be converted into cloud-only user mailboxes. Synchronization with on-premises objects with AADC cannot be performed until after the migration.

Only a single-target domain is supported.

A Tenant to Tenant Migration with a Coexistence project is unique in MigrationWiz.  While the overall process is no different from any other migrations, this specific type of migration does the extra setup to establish the coexistence link between the Source and Destination tenants.

After following the steps in the Microsoft 365 Tenant to Tenant Coexistence Project Setup Guide above, MigrationWiz will perform several actions in the background on both the source and destination to prepare the users for coexistence. This process is done automatically, there is no need for any actions to be done manually.

1. Once the project is saved, MigrationWiz automatically opens both endpoints, connects to Microsoft Entra, and starts to configure the Microsoft 365 tenants for the project. This process can take up to one hour per 1000 users.
2. Organizational Sharing and Individual Sharing are set up and enabled on the source and destination tenants; Free/Busy between the tenants.
   
3. Users are discovered in the source tenant and mail contacts are created with an external email address of the primary domain on the destination tenant for the users. This will allow for reverse free/busy look-up from the destination to the source as well as enable mail routing from the destination to the source.
   
4. Once the automatic process is finished, the users are imported into the MigrationWiz project. The users are now ready to have User Migration Bundle licenses applied.  See MigrationWiz Licenses for steps on applying for licenses. 
   

Litigation Holds

We do support Litigation Hold migrations but with some important known limitations.

​Be aware of these limitations since, for obvious reasons, Litigation Hold tends to have a 100% fidelity requirement. ​

All emails in the primary mailbox will indeed be migrated. MigrationWiz also supports migrating of the Recoverable Items folder for the Archive mailbox for Exchange Online to Exchange Online only. Steps for this can be found outlined in the following migration guide: Recoverable Items (Microsoft 365 or Exchange) Migration Guide

Folders created in Litigation Hold are considered to be "email folders" but this is not necessarily the case. Therefore, all the special Litigation Hold items (whose type is not email) fail to migrate due to a known limitation in EWS (which is what MigrationWiz uses for migrations when migrating from Exchange 2007+ as the source).

Although they are not, several of these are considered email folders by EWS. Due to a bug in EWS, if you try to create a non-email item within those folders, it reports an error stating: "The item type does not match the folder type".

For example, if a contact is deleted, it will be stored in the /Purges folder. When we try to migrate this contact to the destination mailbox's /Purges folder, it reports an error.

Here are some known folders in the recoverable items mailbox:

• Versions: If Litigation Hold (or for that matter, In-Place or single item recovery) is enabled, this subfolder contains the original and modified copies of the deleted items. Note: This folder is not visible to end users.
• Purges: If either Litigation Hold (or single item recovery) is enabled, this subfolder contains all items that are hard-deleted. Note: This folder is not visible to end users.
• Discovery Holds: If In-Place Hold is enabled, this subfolder contains all items that meet the hold query parameters and are hard-deleted.
• Audits: If mailbox audit logging is enabled for a mailbox, this subfolder contains the audit log entries. This folder is not migrated with MigrationWiz.
• Calendar Logging: This subfolder contains calendar changes that occur within a mailbox. This folder is not available to users.
• Deletions: This subfolder contains all items deleted from the Deleted Items folder. (In Outlook, a user can soft-delete an item by pressing Shift+Delete.) This subfolder is exposed to users through the Recover Deleted Items feature in Outlook and Outlook on the web.

By default, the folders indicated above will be migrated into a folder at the Destination, named "Deletions". Any mail items within these folders will be migrated. The non-email items will return an error in the MigrationWiz portal, but will not prevent the migration from completing. Typically there are only a few extra errors caused when performing Litigation Hold migrations (since most items in these folders are, in fact, email items) so the error count threshold will not need to be adjusted.

The migration process includes a folder discovery, plus it attempts to retrieve items from within each folder. If the attempts fail, this folder will be excluded during the migration, so that the migration can continue.

If you prefer to have the folders in the recoverable items mailbox migrated into their own corresponding folders at the Destination, and not migrated into a folder named "Deletions", you must add the Advanced Option (under the support section): OverrideRecoverableItemsFolderMapping="^SourceFolder->DestinationFolder" to your project before performing your migration.

Here are the recommended step-by-step directions for performing a migration that includes mailboxes set for Litigation Hold:

1. Create a regular mailbox migration project, set the advanced options, and submit mailboxes for migration. Follow the directions under the migration guide for the appropriate scenario. All migration guides can be found in the MigrationWiz category of the BitTitan Help Center.
2. Once the mailbox migrations have been completed, create a new mailbox migration project specifically for Litigation Hold.
3. Set the project advanced options for this Litigation Hold project, so that the Source: Migrate from: parameter is set to Recoverable Items. This will automatically set the Destination: Migrate to: parameter to be set to Recoverable Items.
4. Return to the regular mailbox migration project dashboard, select completed migrated items, and move these items to the Litigation Hold project.
5. Now, from the Litigation Hold project, submit items for migration. These will then migrate all items under the recoverable items folder at the source into the recoverable items folder at the destination.
6. Once complete, move items back to the regular mailbox migration project.
7. All emails will be migrated.
8. Users will not be able to see anything that they should not be able to see.
9. Mailbox migrations allow up to 10 passes per mailbox. Therefore, migrating mailboxes under the Litigation Hold project will not consume any additional licenses, provided that the items were moved between projects.
10. Do not add new mailboxes under the Litigation Hold project. Instead, move items into this project. This way all project statistics and license history will be retained.​
11. When migrating to recoverable options, it is recommended to increase the retention period for the deleted items folder. The default retention period is 14 days. This should be increased to the maximum, which is 30 days. Steps for this are included in this TechNet article: https://technet.microsoft.com/en-us/library/dn163584(v=exchg.150).asp

Migrating Litigation Hold Data for Inactive Users

Inactive mailboxes are not supported with MigrationWiz. To migrate these users, activate them and migrate as part of a regular migration. Use the steps in this Microsoft document to restore the mailboxes to an active state before migrating: Restore an inactive mailbox

Litigation Hold vs. In-Place Hold

Litigation Hold migration involves putting a user's entire mailbox on hold to retain it for legal review.

In-place hold migration involves putting a subset of a user's entire mailbox on hold to retain only certain types of email.

The only difference between these two types of migration is a query. Litigation Hold can be enabled to hold all deleted or modified items. In-Place Hold is set up like Litigation Hold but adds a filter query to retain only specific kinds of email.

Litigation Hold works like this:

In the normal deleted item workflow, a mailbox item is moved to the Deletions subfolder in the Recoverable Items folder when a user permanently deletes it or deletes it from the Deleted Items folder. A deletion policy (which is a retention tag configured with a Delete retention action) also moves items to the Deletions subfolder when the retention period expires. When a user purges an item in the Recoverable Items folder, or when the deleted item retention period expires for an item, it is moved to the Purges subfolder in the Recoverable Items folder and marked for permanent deletion. It will be purged from Exchange the next time the mailbox is processed by the Managed Folder Assistant (MFA).

When a mailbox is placed on a Litigation Hold, items in the Purges subfolder are preserved for the hold duration specified by the Litigation Hold. The hold duration is calculated from the original date an item was received or created and defines how long items in the Purges subfolder are held. When the hold duration expires for an item in the Purges subfolder, the item is marked for permanent deletion and will be purged from Exchange the next time the MFA processes the mailbox.  If an indefinite hold is placed on a mailbox, items will never be purged from the Purges subfolder.

Troubleshooting

Migrating Large Items

The steps in this article require that you connect to Microsoft 365 with Windows PowerShell. Refer to the Connect to Office 365 PowerShell article from Microsoft for detailed steps on how to connect to Microsoft 365 using Windows PowerShell.

To migrate items to Microsoft 365 that are larger than the EWS defaults, you will need to run the following PowerShell scripts.

First, you should run this script against your Microsoft 365 environment to determine what your current settings are:

Get-Mailbox testuser01 | fl mailboxplan,maxsendsize,maxreceivesize

The user can be any standard user on Microsoft 365 that has a Microsoft 365 license assigned that contains a mailbox license. It should be a user whose settings have not been previously modified.

Example results:

MailboxPlan: ExchangeOnlineEnterprise-4b910ff9-8b91-4f2e-960c-302a90c95668
 
MaxSendSize: 35 MB (36,700,160 bytes)
 
MaxReceiveSize: 36 MB (37,748,736 bytes)

Next, run this script against your Microsoft 365 environment to set the Mailbox Plan, the Max Send Size, and the Max Receive Size:

Get-MailboxPlan | Set-MailboxPlan -MaxSendSize 150MB -MaxReceiveSize 150MB

New users created after you change the mailbox plan will have 150MB as the max send and receive size. However, the current user will still have 35MB. To increase the limit for all users you can run:

Get-Mailbox | Set-Mailbox -MaxReceiveSize 150MB -MaxSendSize 150MB

The example below shows how you can validate that the new limits are applied:

PS C:\Windows\system32> Get-Mailbox testuser01 | fl mailboxplan,maxsendsize,maxreceivesize
 
MailboxPlan: ExchangeOnlineEnterprise-4e910ff9-8b91-4f2e-960c-302a90c65668
 
MaxSendSize: 150 MB (157,286,400 bytes)
 
MaxReceiveSize: 150 MB (157,286,400 bytes)

​Migrating Mailboxes Larger than 100GB

Follow these steps to migrate a mailbox larger than 100GB to Microsoft 365:

1. Open MigrationWiz and create a mailbox migration project.
2. Configure the Source and Destination Endpoints.
3. Add the users to the project.
4. Within the Advanced Options section, configure the destination settings to migrate to the Archive mailbox for the users. For additional information read the  MigrationWiz - Advanced Options & General Options article.
5. Set a date range filter within the project to migrate items older than a specific date. For example, migrate all items a year old or older to the Archive mailbox. For additional information, read the Set a date range filter in MigrationWiz.
6. Submit a Full migration pass that migrates only mail items. Monitor the migration until it is successful.
7. Once the migrations to the archive mailboxes are complete, change the setting in the Advanced Options to migrate to the primary mailbox instead of the archive mailbox.
8. Remove the date range filter.
9. Perform either a Pre-Stage or a Full migration pass to the primary mailbox.

Turn Off Calendar Assistant

Calendar Assistant in Microsoft 365 can break meetings and recurring meetings in Outlook and OWA. We recommend you turn off the Calendar Assistant at the beginning of any migration. This feature can be turned on after the migration has been completed. There is no negative impact when Calendar Assistant is turned off.

Use PowerShell to create a remote session to Microsoft 365 to execute the following commands:

$LiveCred = Get-Credential

Install-Module -Name ExchangeOnlineManagement
Import-Module -Name ExchangeOnlineManagement
Connect-ExchangeOnline -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred

Get-o365Mailbox -ResultSize unlimited | Set-o365Mailbox -CalendarRepairDisabled $true

The Calendar Assistant is now disabled for all mailboxes in the Microsoft 365 tenant. It can be enabled again by using this PowerShell command:

Get-o365Mailbox -ResultSize unlimited | Set-o365Mailbox -CalendarRepairDisabled $false

Create an Admin Account

The easiest approach to follow is to use the global admin account. This was set up at the time of tenant creation.

However, if you do not wish to use this global admin account during migration, then a new user account can be created instead. This will then need to be granted full access rights to each mailbox user.

Steps:

1. Create a user in Microsoft 365: Create user mailbox in Exchange Online.
2. Connect to Exchange Online by using remote PowerShell. For more information about how to do this, go to the following Microsoft website: Connect to Exchange Online Using Remote PowerShell
3. Type the following command, and then press Enter:
   Get-Mailbox -ResultSize unlimited -Filter {(RecipientTypeDetails -eq 'UserMailbox') -and (Alias -ne 'Admin')} | Add-MailboxPermission -User AdministratorAccount@mydomain.com -AccessRights fullaccess -InheritanceType all

After you perform these steps, the specified user will be able to access all user mailboxes in Microsoft 365. The user will be able to view the contents of the mailboxes from either Outlook or Outlook Web App.

Migrating to Microsoft 365 in China

The first thing that needs to be done is to determine exactly which version of Microsoft 365 in China that you want to migrate to.

The key factor here is where Microsoft 365 resides, for example, whether or not Microsoft 365 is outside or inside the Chinese firewall.

The Chinese government runs and maintains the Great Firewall in China. There is an "international side" (outside the firewall) and a "mainland" side (inside the firewall). 

In MSPComplete, the "Microsoft 365 China" endpoint refers to "Microsoft 365 China International." You can use this endpoint if you are migrating users to this international version of Microsoft 365 in China, the version that is outside the firewall.

However, if you are migrating to Microsoft 365 in China (inside the firewall), you should work with 21 Vianet. BitTitan has partnered with 21 Vianet to enable Partners to migrate to Microsoft 365 in China, inside the firewall. For more information on this partnership, read the blog here.

To initiate the process, contact 21 Vianet's sales department by sending an email to bluecloudsolutions@oe.21vianet.com.