Migrated calendar events - Expected behaviours

When migrating calendar events, CloudM Migrate performs the following tasks:

• Changes the event owner to be the destination user.
• Changes any guests on the migrating domain to use their post-migration address.
• Ignores any guests from external domains.

Generally migrated events in the destination that have any subsequent changes made would also notify attendees if this is requested by the calendar platform. However, there are some platform specific caveats and expected behaviours that should be noted when migrating events. These specifically deal with what happens when a migrated event is edited and how it affects attendees.

Migrated Event from Google Calendar

Tests using Google Calendar as migration source have the following behaviour:

• Migrating to another Google Calendar shows that both internal and external attendees are notified (or have the event auto-updated depending on their platform) of any changes made to a migrated event. The migrated account has full ownership of the event as they did in the source, except for Google Meet links which are explained further below.
• Migrating to a Microsoft 365 Calendar works as per Google above for attendees on the same domain (ie other users who have been part of the migration). For any external users, however, their calendar interprets any changes as coming from a different event to the original, which causes a duplicate event entry, the original event from the source and the modified post-migration event. This only happens when a migrated event is changed in some way that requires attendees to be notified.

Migrated Event from Microsoft 365 Calendar

Tests using Microsoft 365 as the source have the following behaviour:

• Migrating to another Microsoft 365 platform results in all attendees receiving notifications to a post-migration event change. The destination event is treated the same as the original aside from Teams Meeting links which are explained further below.
• Migrating to Google Calendar results in the destination account not ‘owning’ the event (this is still the source account) and so making any changes to an event post-migration is essentially a local change purely for that destination account. No attendees are notified of any change as a result. This behaviour is due to API restrictions. Changes to the event post-migration would need to be performed as the user who originally owned it in the source platform for all other parties to be notified.

Migrated Event from Lotus Notes

Tests using Lotus Notes show that when migrating a resource calendar that the events do not link up with its corresponding event in the user’s calendars, resulting in the event being duplicated in the destination. This is one entry each for the original user calendar and one for the original resource calendar.

Migrating Event Meeting Links

When migrating a calendar event that contains a pre-existing meeting either via Google Meet or Microsoft Teams, there are some known issues that exist due to the API limitations of either platform.

While the calendar event itself is migrated and all subsequent ownership/guest lists are migrated as outlined above, the video call link is migrated ’as-is’ since it is not something that we are able to modify during a migration. The result is that all previous ownerships and guest lists from the source environment are still applicable even at the destination event, rather than being changed as per mapping to the destination domain.

The reason for this is that the Meet/Teams spaces are created on Google/Microsoft’s servers and CloudM Migrate simply migrates the meeting link provided. We are not able to modify the meeting that it refers to.

Think of it as copying over a reference to a read-only document: All that we can do is copy over the document’s previously provided link. Currently there are no satisfactory methods to work around this via software in terms of performance or stability.

What To Expect When Migrating Meeting Links

If a Google Meet or Microsoft Teams event exists for a user in the source domain, for example user1@domain1.com, and it is migrated to user1@domain2.com then in the destination calendar the event itself will be owned by user1@domain2.com. But, by clicking the meeting link, you will be treated as a guest on this account and prompted to wait until the owner starts the call.

In this case, the owner is still the user1@domain1.com account. A workaround to still use these meeting calls is logging into the call using the original source account credentials (if still available) and, as the owner, you can start the call and allow other guests entry. In this case, signing into the call as user1@domain1.com will always begin the call successfully.

The other workaround is to manually remove and recreate the event with a newly created link for the Teams/Meet call which would then be owned by user1@domain2.com and allow starting the event while logged in from that account.