By Kelsey Epps, Senior Technical Partner Strategist, BitTitan

There’s no question that businesses have adopted the cloud, big-time. In fact, Reuters reports that Microsoft has been shifting its reliance from the Windows operating system toward selling cloud-based services. Revenues have topped $1 trillion as the software giant predicts even more cloud growth.

Now that businesses have moved so many of their key workloads out of on-premises servers and shifted them into the cloud, the great wave of on-prem-to-cloud migrations is past its peak. With the cloud so well-entrenched, IT departments and service providers are being asked more and more to migrate workloads from one cloud instance to another. There are a variety of business reasons for making such a move, whether it’s employee preferences for a given software stack, realigning contracts, or utilizing APIs that are a better business fit.

It would seem that once a set of workloads is in the cloud, moving them to another cloud instance should be a straightforward process. However, ensuring business continuity through a cloud-to-cloud migration is every bit as tricky as an on-prem-to-cloud move.

In fact, now that workers are enjoying the work-from-anywhere access that the cloud provides, they may even be less tolerant or forgiving of any interruption in their user experience. When workers expect uninterrupted data access and seamless collaboration through the transition, the “Big Bang” approach of migrating everything in a single sequence, user-by-user or workload-by-workload until the job is done is rarely an option. Organizations are increasingly turning to a batched approach with their migrations, which targets specific groups or departments to migrate at the most opportune times.

This approach offers many benefits, but also its own challenges, because when a batched approach is taken, end users will exist on both the Source and Destination. This is where tenant-to-tenant coexistence comes into play to help facilitate the move.

Tenant-to-tenant migrations defined

A tenant-to-tenant (T2T) migration is a form of cloud-to-cloud migration where the Source and Destination applications are the same; the move is from one instance of the applications to another instance of the same applications. In the case of Office 365, the scope of applications and supporting data typically includes mailboxes, personal archives or personal storage tables (PST files), OneDrive or SharePoint files, and of course, the data files associated with the various Office 365 applications.

Migrating a business (or a subset of one) is a challenge because of the heavy reliance on email communications and calendars. Users have no way of knowing who among their coworkers have migrated to the Destination and who have yet to do so.

What is the impact of this? Emails bounce back to the sender or pile up in a mailbox that’s no longer accessible. Meeting invites are missed, or users are erroneously double-booked because the free/busy information associated with their calendars is no longer available to all users, as some are still working from the Source and others from the Destination. These obstacles work against the primary goal that the IT team brings to any migration: to make the whole process seamless and essentially invisible to the users.

Continuous collaboration through coexistence

Coexistence is a migration technique that gets around the synchronization problems and keeps users happily working and collaborating with each other even though they’re being migrated at different times. When a migration is the result of a merger, acquisition or divestiture, an entire organization, department or division is moving from SourceCompany.com to DestinationCompany.com. It’s the ideal scenario for taking advantage of coexistence. All one has to do is follow these easy steps:

• First, enable organizational sharing of the Office 365 tenants. For all users to be migrated, create mail-enabled contacts on the Destination that resolve to each individual’s mailbox on the Source.
• As you migrate each user, remove the mail-enabled contact from the Destination. Create an Office 365-licensed user account to establish the new mailbox, with a forward that points back to the Source mailbox. This allows the user to keep working in the Source mailbox. Migrate the mailbox items from the Source to the Destination.
• Finally, after you migrate each user, remove the forward on the Destination mailbox. On the Source, you can remove the mailbox and replace it with a mail-enabled contact that points to the Destination mailbox. Or, keep the mailbox in place and forward to the new Destination.

Plan ahead for swift execution

Coexistence is an effective technique, especially if you combine it with selective migration of older files or emails that are less likely to be needed and move them either before or after the active migration. This enables you to make the whole process quick and seamless. Put coexistence in your toolkit and use it the next time you’re faced with a tenant-to-tenant migration between domains. Of course, careful preplanning is the key — as it is with any migration.

Bio
Kelsey Epps is a senior technical partner strategist with BitTitan. A 20-year IT industry veteran, Kelsey works with MSPs and IT specialists on the technical preplanning aspects of the most complex migrations projects.