Don't drown in that Office 365 migration you've been putting off: There's help at hand – in the form of automation magic

Sponsored Since its launch, Office 365 has been growing in adoption. During that time the businesses using Office 365 have changed, through acquisition and restructuring. With this change comes some complex and unique problems, particularly when it comes to moving Office 365 and its related applications.

Before Office 365, the task of moving Microsoft’s collaborationware basics like Office, Exchange and SharePoint were simple – annoying, but relatively predictable. Exchange servers and contents could be migrated, and associated docs and applications moved. If Microsoft didn’t provide the necessary migration tools or wizards plenty of third-parties did.

Moving from one instance of Office 365 to another (tenant-to-tenant), however, is a much more complex problem. Microsoft does not provide the same level of support tools, while third parties are hampered by a relative lack of APIs they can write to, to build migration tools. There’s plenty of complexity involved in moving, too. This comes from an array of data types, a large number of connections within Office 365 to other Microsoft applications such as Teams, SharePoint, and OneDrive and the presence of a long list of online configurations, logs and connected applications that need to be updated and transferred. Other things to consider include the presence of such things as accepted domains, anti-spam/malware settings, transport rules, connectors, compliance logs and so on.

There are also potential legal issues around tenant-to-tenant migration across multiple regions. For example, if you have data that is held somewhere in the EU and are using a US migration tool that migrates the data via the US, then this could potentially raise serious issues around data sovereignty and the General Data Protection Regulation. Finally, there are speed limitations of a transfer – depending on the size of the estate or the project in question, the move may not happen overnight, a weekend, or even over a long Christmas break if you are a major organisation with lots of users and data to migrate. Tenant-to-tenant migrations are slowed down because, effectively, there’s no bulk domain-to-domain copy and each user’s data needs to be copied over individually. While you can move many accounts at once, the transfer rate is still measured in gigabytes per hour, not per second.

Not your parents’ collaborationware migration

Fortunately, not everything is doom and gloom. For all the underlying complexity, the good news is that unlike those days of old when moving Exchange and SharePoint servers you don’t have to navigate hardware or deal with software licenses – although licensing is a separate discussion as you typically have a 90-day window in which to move. Additionally, while the process is more complex than a move in the past, the steps involved in the process are steps that most businesses are used to and have experienced – particularly if they’ve moved applications to the cloud. Fundamentally, a tenant-to-tenant move is a five-step process: Analyse, pilot/test, communicate, execute, decommission.

Let’s take the analysis first. At this stage, it helps to establish what it is the business wants to achieve from a migration. Also what is – and isn’t – in scope. Working out, for example, whether individuals or groups are on OneDrive for Business and who is using SPO for example will help you build up a picture of your estate and, therefore, scope the project.

An audit of your estate can really support a successful tenant-to-tenant migration. This can help you:

• Get a handle on who the users are and, importantly, what are they using – for example: external users coming into the tenant.
• Find out what data you have – and where the data is stored.
• Understand the usage and utilisation of the data – for example, if someone created 20 documents five years ago and has never accessed them since, then is there a need to transfer them, or can they be archived or just deleted?
• Identify dormant accounts and applications and identify any non-compliant repositories, which can then be integrated into the migration plan. No amount of reporting will resolve the project element of combining the tenants and the configuration challenges, though, so this is still something you need to decide in your move strategy

Tools such as Quadrotech’s Nova – a single platform for total Office 365 management – automates some of this Office 365 audit work for you, capturing the user usage and utilisation data. With Nova, you can drill down to get detailed information on your Office 365 users and how often they use Office 365 applications. It also lets you see how much data your current users are using, allowing you to create realistic time-scales for migration.

If you’re a multinational, then you should also look at any legal ramifications of the move. If your data is held in different geographical locations then it’s probably there for a good reason. Moving the data to another location may be easier in terms of administration and efficiency, but it may not meet your legal requirements. Auditing lets you identify where that data lives.

Another essential of migration is communication with the account users. You need to prepare them for the project timescales – they are unlikely to leave on a Friday and come back to a new system on Monday morning. You will need to manage their expectations of the transfer and have your friendly help-desk staff primed and ready to field questions when users can’t find that important new email or the regular Monday morning meeting goes missing from their calendar. Access to systems via mobile devices is one of the number-one help-desk issues when it comes to a tenant-to-tenant migration as there are no simple ways to get the devices reconfigured which can be a large burden. Quadrotech have a number of good Communications Templates here to help with the communication process and any snags that are liable to happen.

It's therefore a good idea to run migrations on test accounts and document the findings that you can detail in a communication plan/playbook for readers. To make the process as close to reality as possible make sure the test accounts are created in Active Directory (AD) and are synced to Azure AD, and include plenty of dummy data including email, calendar, and contact items and preferably access to other Office 365 services. This will help you get speed data and experience issues before production.

Once you’re through analysis and test and have established communications, you can move onto the heavy lifting phase. There are two routes you can take – the one you choose will depend on your timescales. The first, is to pre-synchronise the majority of the emails, calendars, contacts, tasks, and then complete the synchronisation from the old to the new tenant over the migration window, which depending on the number of users and the amount of data, could be over a weekend or over a long break.

The second option is rarely used, because it controversially assumes that any data older than seven to 14 days isn’t important, but it can be useful for situations where you need everyone on the same tenant at once. With this option, all calendars, contacts and tasks are copied as a priority, along with emails from the last week to two weeks; then the strategy backfills the new tenant with older emails. While this gets all the users on the new tenant quickly, it can be frustrating to users, particularly if they need access to an old email during the backfill process, which could be days to a week. Choosing which option depends on your size, data volumes and several other factors.

No matter which route you choose, you will always have some co-existence and having multiple tenant systems running together can potentially cause problems particularly with ID migration. Once again, this is where a third-party tool can help. With an Office 365 tenant to tenant migration tool like Quadrotech’s Cloud Commander, you can maintain the accounts so that federation continues to work during migration following an initial synchronisation. ID management comes in multiple flavours depending on your project while many start new. The HRIS system can generate the IDs, one-time Active-Directory syncs or an on-going synchronisation process.

The underlying factor that’s easy to overlook in all of this is the time it takes to conduct a tenant-to-tenant transfer. Moving data between Office 365 tenants is slow, and while you can copy multiple accounts simultaneously, it is still a long process that can take weeks or longer. Tools such as Quadrotech’s Advanced Ingestion Protocol (AIP) technology in Cloud Commander can speed up the tenant-to-tenant data migration from typically 4GB-20GB an hour to more than 100GB an hour depending on your configuration and can help reduce project timescales significantly, no matter which migration strategy you use.

The last stage in a migration is checking to make sure your new estate has achieved what the business expects – making sure users can now access calendars and share data with everyone in the organisation. From the IT perspective, your new tenant should also be leaner and easier to manage, as you will hopefully have used this as an opportunity to tidy-up mailboxes, archive old calendar appointments, and delete duplicates.

Firm foundations

Office 365 is coming to shape working life and is past the point of early adoption. The challenge organisations face is not simply to take their early Office 365 installations forward but to lay the foundations of a scalable collaboration estate. While migrating Office 365 tenants is more difficult than collaborationware moves of old, getting the move right will mean you have created a platform that is capable of adapting faster and more easily to the changes that will inevitably occur in the future on the business side of your organisation and that impact collaboration.

Sponsored by Quadrotech.