Introduction
It's possible to migrate Workspace 365 environments from one partner to another as long as the new partner is on our hosted platform. In this article, we explain how this process works and what is required.
Migration process
The first step is to submit the request for the migration via a support ticket. This ticket has to be submitted by either the old or the new partner. The following information has to be included in the ticket:
The name of the environment that has to be migrated
Written approval for the migration from all parties involved:
The customer
The new partner
The old partner
Written approval for the costs of the migration (see the pricing page on the Partner Portal)
These costs are invoiced to the partner submitting the migration request
Once the migration request is submitted, it will be evaluated by a support agent. If both the old partner and the new partner are on our hosted platform, we will make the administrative change as soon as possible unless requested otherwise. This administrative change does not incur any downtime. If the old partner is self-hosted please include their contact details so we can schedule the environment export and import process. This process will incur downtime.
Attention During Migration!
No Automatic Permission Assignment: We will not assign or issue permissions to the new administrator of the environment. As the new administrator, ensure that you receive the necessary permissions directly from the customer.
Removal of Admin Rights: It is recommended to remove the admin rights of the departing party after the migration. This must be carried out by the partner or customer.
Workspace 365 does not delete users within environments.
If you have any questions about this procedure, please contact the responsible administrator or your designated contact person at Workspace 365.
Technical changes
If a Workspace 365 environment that needs to be migrated does not have a custom environment URL, the URL will change for end users and some changes are required both before and after the URL change. When migrating multiple environments, these changes must be performed for each environment involved in the migration.
If a Workspace 365 environment that needs to be migrated does have a custom environment URL, the only technical change that needs to be made is to update the CNAME DNS record from the old partner DNS record to the new partner DNS record. This change prevents issues in the future and does not incur any downtime.
No custom environment URL
If the environment does not have a custom environment URL, follow these steps:
Before the URL change:
Go to the SSO app registration in Azure and click Authentication
Add an additional Redirect URI according to the format:
https://newpartner.url/environment/OAuth2/HandleAuthorityResponse
Replace "newpartner.url" with the instance URL of the new partner
Replace "environment" with the name of the workspace environment
Do not delete the existing Redirect URI, as users will still use this to log in until the URL change
Save the changes to your app registration
Now the end users are able to log in to the environment using the new URL.
As soon as the end users start using the new URL:
Go to the SSO app registration in Azure and click Authentication
Delete the old Redirect URI (the one containing the instance URL of the old partner)
Change the Front-channel logout URL according to the format:
https://newpartner.url/environment/SignOut
Replace "newpartner.url" with the instance URL of the new partner
Replace "environment" with the name of the workspace environment
Update the URL as displayed in the welcome email, see this article for steps how to do this