• Exchange And Office 365 Hybrid
• Exchange And Office 365 Hybrid
• Exchange And Office 365 Mail

Collaborate for free with online versions of Microsoft Word, PowerPoint, Excel, and OneNote. Save documents, spreadsheets, and presentations online, in OneDrive.

This full step-by-step guide is available as a PDF. Please click here to download!

Although every Microsoft Office 365 plan includes cloud email that is actually running on Microsoft Exchange server. The means either system actually uses the same email servers. A big difference here, is one is hosted by a hosting provider and the other is hosted by Microsoft. Jun 25, 2020 Office 365 is Microsoft’s paid subscription cloud platform. There are many other packages you can upgrade according to your requirements. With the exception of Exchange Server, Office 365 can be used in various plans such as Office 365 House, Office 365 Personnel, and Office 365 Education. Upside of Office 365.

If you are planning an Exchange to Office 365 migration, then it can be quite confusing to understand the steps you need to take and in which order.

In this article, we’ll walk through the steps and decisions you need to take when migrating to Exchange Online. In part one we’ll consider the two most important first steps – deciding upon a migration approach and performing the core steps for identity. In part two, we’ll perform the Exchange Hybrid configuration and perform the migration of Mailboxes.

And, although we’re going to cover a lot of information in a short amount of time, you’ll find detailed guidance linked throughout.

Preparing your Exchange to Office 365 Migration

Before you begin a migration, it’s important to make sure that the source environment you are migrating from is in a good state.

If the Exchange environment you are running today isn’t healthy, then often that can serve as the motivator to move. After all, what can be an easier solution to bad day-to-day Exchange performance than moving to Office 365?

Unfortunately if you are experiencing day-to-day issues with Exchange, such as user issues accessing Exchange remotely, error messages and slow access times to mailboxes – or worse, database corruption – then moving to Office 365 will most likely be another source of trouble; not just for people accessing the environment you are trying to migrate from, but also when migrating as it’s likely you’ll experience failures along the way.

Your first step before beginning a migration should be to ensure that the environment is reasonably error free and correct any underlying issues prior to migration.

Read More: Patching your Exchange Environment

Hybrid migration or tool-based migration?

If you are thinking about moving your Exchange environment to Office 365 then you’re probably aware there are many options available.

From Microsoft, you have options for a Staged Migration and a Cutover Migration as well as a Hybrid Migration, and from third-party vendors a large number of different tools on the market for email archive migrations.

In general, if you have a version of Exchange Server that’s supported by Microsoft (Exchange Server 2010 and above) and it is part of your Active Directory then your default option should be an Exchange Hybrid Migration.

An Exchange Hybrid is based on either minimal or full Exchange Hybrid and creates a relationship between your on-premises Exchange servers and Exchange Online. This allows native mailbox moves, similar to between on-premises Exchange servers, with Outlook clients natively switching over without even needing to re-download offline copies of email. With full Hybrid, this also extends to secure mail flow between the two environments and co-existence functionality like free/busy and calendar sharing.

Azure AD

Azure AD Connect complements Exchange Hybrid, and you should expect to use Hybrid if you plan to synchronize your identity to the cloud. Azure AD Connect synchronizes your local Active Directory domain to Office 365, creating a copy of local AD accounts in Azure Active Directory that link back to the master copies. Azure AD Connect is also the part of the puzzle that maintains a consistent Global Address List between on-premises and the cloud.

Because AD and Azure AD Connect understand when there’s an existing Exchange organization in place, existing mailboxes on-premises won’t have mailboxes created in Office 365. You’ll be expected to use Exchange Hybrid to move mailboxes.

With a tool-based migration, the same rules do not apply. A fully Microsoft-supported Exchange Hybrid migration provides an excellent experience. However, especially in multi-forest environments it can be complex to set up correctly, hosted environments often do not allow for Azure AD Connect or Exchange Hybrid to be configured; and if you have legacy versions of Exchange it can involve installing additional servers running Exchange 2010 or higher which include the Hybrid components. Therefore, there are valid uses for a bespoke tool to migrate email to Office 365 – but in this article, we’ll assume you’ve made the decision to use Exchange Hybrid.

Read More: Methods for migrating to Office 365

Understanding pre-requisites and dependencies

Once you’ve decided that migrating to Office 365 using Exchange Hybrid is suitable for your organization, and you have a healthy environment to migrate, then you need to ensure you’ve completed necessary planning activities.

Many organizations who begin this journey will at this point ensure they have a design in place to support the changes that will take place. However, as you aren’t designing Office 365 or Exchange Online and instead designing the bridge to Office 365 then the design is often not as detailed as a full Exchange migration.

Instead, you are focusing on the changes necessary to your existing environment to make sure it is ready for the changes. In this article, we won’t cover this, but it’s worth remembering that most organizations, large and small, don’t just head into the unknown without making plans first.

The key pre-requisite for migrating to Exchange is ensuring the correct identity model is in place, first. There is a variety of options available when choosing an identity, but the most common scenario will be to utilize Azure AD Connect with synchronized identities and password hash sync.

Exchange And Office 365 Hybrid

Prior to this, we’ll perform a number of key tasks.

First, we’ll ensure that we’ve added all of our custom domains to our Office 365 tenant. These will need to match the email domains we use on-premises:

<Portal Domain

To add a new domain, choose <Path> and Add Domain. You’ll need to follow the steps, and verify each domain using a TXT record, similar to the one shown below:

Use your DNS provider’s control panel to add the corresponding TXT record to each domain, then continue the verification process.

Once you reach the point to add additional DNS records, it’s important you choose to Skip adding records such as Autodiscover or MX record changes.

This is crucial because at this point in the process your email is still looked after by on-premises systems, and you do not want to redirect clients to Office 365. The Hybrid relationship we create will manage this for us, later on.

We’ll sign-in to Office 365 using a login ID in the same format as an email address. In an Exchange Hybrid relationship, we expect this to match the Active Directory UserPrincipalName for each user. However, in many organizations, the login IDs are not in a format that will be suitable

On-Premises Login ID	On-Premises UserPrincipalName	Primary SMTP address	Resulting Office 365 Login ID
CONTOSOusername	username@contoso.local	username@contoso.com	username@contoso.onmicrosoft.com

In the above example, the issue is with the UserPrincipalName (UPN) suffix – the contoso.local part that typically matches the full AD Forest Name. To resolve this, we’ll add a UPN suffix to match our email domains registered with Office 365 in Active Directory Domains and Trusts:

We’ll then update the UserPrincipalName value for each user using Active Directory users and computers (or, ideally, PowerShell) to match the email address:

In most cases, this will not cause any user issues with sign-in, as nearly all organizations still expect users to login with the Pre-Windows 2000 / CONTOSOusername format. However, you should always validate this before making changes. After making these changes, the formats for login IDs will be similar to below:

On-Premises Login ID	On-Premises UserPrincipalName	Primary SMTP address	Resulting Office 365 Login ID
CONTOSOusername	username@contoso.com	username@contoso.com	username@contoso.com

We’ll also run the Microsoft IDFix tool against the domain. This step will highlight other issues within your Active Directory relevant to the domain sync. IDFix identifies errors, such as invalid email addresses (known as Proxy Addresses), invalid characters in usernames and other data and common issues, like using an invalid UPN suffix.

Use the list of issues identified by ID to make the corrections recommended, then install Azure AD Connect. In the example below, we’ve chosen Use Express Settings:

We’ll then follow the wizard steps to connect both as a global administrator to our Azure AD/Office 365 tenant, and to our local Active Directory. You’ll remember above though we added an additional UPN suffix to our local AD due to it not being a valid domain to use with Office 365. This will be highlighted during the installation wizard, however, because we’ve dealt with this it will be safe to continue:

Because we chose the Express Settings the wizard has pre-selected that we’ll use Password hash synchronisation. Our final choice is to ensure that an Exchange Hybrid Deployment is selected before beginning the install. This will ensure Azure AD Connect writes-back Exchange-related attributes to our local AD:

Once initial synchronization completes, you should be able to access the Microsoft 365 Admin Center and navigate to Users>Active Users and see synchronized accounts. You’ll see your AD users with a Sync Type of Synced with Active Directory:

Further Reading:

Other areas you’ll need to consider

In addition, before you migrate mailboxes to Office 365, you need to consider other pre-requisites. Key areas you need to consider include:

Legacy Archiving

If you currently use a solution like Veritas Enterprise Vault for archiving or journaling email then this configuration will not work as-is with Office 365. Instead, the most common approach is to move archives to Exchange Online after migrating mailboxes.

In this scenario, stubs (or shortcuts, to use the EV term) will be re-hydrated with the original archive messages; or moved to archive mailboxes in Exchange Online. Quadrotech’s Archive Shuttle can handle this task and works well with an Exchange Hybrid migration.

Outlook clients

You’ll need to run a supported version of Outlook when connecting to Office 365. The following versions of Outlook are supported:

• Office 365 ProPlus
• Outlook 2019
• Outlook 2016
• Outlook 2013

Ideally, use the newest version (Office 365 ProPlus) that you have available. Outlook 2013, 2016 and 2019 will work with Office 365. If you are running Outlook 2010 today, then this can work with Exchange Online but for security reasons you will most likely want to block the protocols it uses.

Mobile devices

If you use Microsoft ActiveSync today to connect to Exchange on-premises, then you can allow mobile devices to continue to use this protocol when connecting to Exchange Online. Expect though in all but the most unusual circumstances to need to reconfigure ActiveSync devices to work with Exchange Online.

Instead, consider deploying the new Outlook mobile client to devices. If you choose to move to Microsoft Intune, then you can also use Intune to deploy and configure the new Outlook client. This supports additionally functionality to ActiveSync including the ability to schedule Teams meetings directly from the client, and new functionality like Focused Inbox. From a security perspective it can ensure that you have control over data, such as attachment downloads.

Internet Publishing

The way you publish Exchange Server to the internet is important for a Hybrid deployment. This used to be crucial for all implementations, however, the new Hybrid Agent means that we can avoid many of the more complex areas for Exchange firewall and SSL certificate configuration for simple deployments.

There are a number of areas you must consider though:

• Autodiscover – In a Hybrid environment the Autodiscover service on-premises will be used by both on-premises mailboxes and Exchange Online mailboxes in Office 365. If you are moving to a model where users can access their mailboxes anywhere, then you will need to publish Autodiscover externally.
• Mail Flow – The Hybrid Agent removes the need to publish Exchange over HTTPS for mailbox moves and free/busy access. However, we’ll still need to allow mail flow between on-premises and Exchange Online. This requires TCP/25 connectivity both to and from Exchange Online Protection.
• Outbound access from Exchange servers to Exchange Online. Although the Hybrid Agent will allow access from Exchange Online to on-premises servers, your servers will still need to connect outbound for both the Hybrid Agent itself, and for requests such as free/busy.
• Client Access to Office 365. You’ll also need to ensure that all Office 365 clients like Outlook can access the service. Ideally this will be direct connection (instead of via a proxy server) accessing Office 365 by the fewest number of hops to the closest Microsoft Point of Presence. Use the Office 365 Network Onboarding Tool as a standing point.

In our example Exchange Organization, we’ve got a valid, third-party SSL certificate configured for Exchange Server for both our SMTP namespace (smtp.exchangelabs.co.uk) and HTTPS (autodiscover.exchangelabs.co.uk and outlook.exchangelabs.co.uk). We’ve allowed direct connectivity outbound on HTTPS to the required Office 365 and Exchange Online IP address ranges and SMTP connectivity to and from Exchange Online Protection.

Summary

In part one, we’ve selected the migration method to use for migration to Exchange Online, focusing on a Hybrid migration. We’ve then performed the core pre-requisite step for Exchange Hybrid – synchronizing Active Directory using Azure AD Connect. Finally, we’ve examined other areas, such as archiving, clients and connectivity.

In part two, we’ll implement Exchange Hybrid and perform mailbox moves.

Alternatively, you can download the full step-by-step guide here.

The full two-part guide is available to download here.

In the first part of this guide, we decided upon the migration approach from Exchange to Office 365, then performed the core steps to ensure identity – the core component for Office 365 sign-in – was set up correctly.

In the second part of this series, we’ll dive into the implementation of Exchange Hybrid and migrate mailboxes.

Implementing Exchange Hybrid

With identity in place, we are now ready to implement Exchange Hybrid. Because we are running Exchange 2010 or higher, we don’t need to add additional Exchange servers. We’ll choose to implement Full Hybrid rather than minimum (you can read more about both here).

To begin, we’ll access the Exchange Admin Center on-premises and navigate to the Hybrid tab. Then we’ll choose Configure:

Choosing Configure will download and start the Office 365 Hybrid Wizard. We’ll allow the wizard to choose an optimum server and then for most organizations choose My Office 365 organization is hosted by Office 365 Worldwide, then choose Next:

We’ll then enter appropriate administrative credentials. In this example, we’ll use the administrator credentials for Exchange on-premises, and our Global Administrator credentials for Office 365:

We’re going to plan for some longer-term co-existence and full mail routing, therefore we’ll choose a Full Hybrid Configuration on the Hybrid Features page.

We’ll also choose the Organization Configuration Transfer feature. This will make life easier when migrating to Exchange Online by copying on-premises configuration (detailed here) as part of the initial Hybrid configuration process:

Crucially during the setup process, we’ll choose to use the new Preview feature for Exchange Modern Hybrid, as mentioned above. This will install a Hybrid Agent that simplifies publishing our Exchange Server to Office 365:

Finally, we’ll select an On-Premises Account for Migration. This will be the account used to migrate mailboxes and must possess the Organization Management and Recipient Management role as detailed under “Mailbox move and migration permissions” on Microsoft Docs. The credentials specified here will be used to create a Migration Endpoint automatically that leverages the Hybrid Agent, making it simple for us to migrate mailboxes:

As a pre-requisite to the Hybrid Configuration itself, the Hybrid Agent will be installed and configured. As part of this process, you’ll need to provide your Office 365 credentials again, then after agreeing to licensing terms, the Hybrid Agent will be installed and configured:

Next, as part of the Hybrid Configuration, we will need to configure mail flow. For most organizations, we’ll choose to Configure my Client Access and Mailbox Servers for Secure Mail Transport rather than use Edge Servers. For Exchange 2010, this will be Hub Transport Roles. We’ll also choose to leave Centralized Mail Transport unticked. Only use this option if you want all outbound email from Office 365 to flow via Exchange Server on-premises.

On the next two pages of the wizard, we’ll define the servers used for inbound and outbound mail flow between Office 365 and on-premises Exchange Server. On the first page, we’ll choose the Receive Connector configuration. This will be the servers used to receive mail from Office 365, which includes messages from Office 365 mailbox back to mailboxes that are still hosted on-premises.

These servers will be those with valid SSL certificates installed and published to be available for inbound SMTP connectivity from Exchange Online Protection.

On the Send Connector configuration page, we’ll select the servers that will be used as the last hop before sending onward to Office 365. Until we cut over our MX records entirely to Office 365, all mail to Office 365 recipients will flow out through these connectors, and these servers will need to be able to communicate via SMTP to Exchange Online Protection, and use valid SSL certificates:

Next, we’ll need to select the SSL certificate to use for communications. The connectors created will expect to utilize this certificate both when negotiating a TLS-secured SMTP conversation with Office 365 and when Office 365 connectors validate the identity of our on-premises organization:

Finally, we’ll enter the Organization FQDN. This name will be the name you’ll configure when publishing SMTP externally. Office 365 will create a connector to send email to on-premises using this DNS name, which will then be used to initiate a connection over SMTP.

With our configuration defined, we’ll proceed to configure the Hybrid relationship. This may take some time, as it relies upon the Hybrid Configuration Wizard making changes to both Exchange Online and Exchange On-Premises. For larger organizations, expect to wait a substantial amount of time when tasks such as updating Email Address Policies take place.

After the Hybrid Configuration wizard completes, we’ll expect the following key tasks to be complete:

• The Hybrid Agent installed and configured, with an endpoint defined for Exchange Online to access our on-premises organization over HTTPS
• The Mailbox Replication Service (MRS) Proxy enabled on all Exchange Web Services virtual directories, allowing Mailbox Moves to take place.
• Federated Sharing enabled for Free/Busy between on-premises and Office 365 and to allow read-only Calendar sharing
• Remote Domain configuration to define the email relationship between on-premises and Office 365 – in particular defining our mail.onmicrosoft.com domain as our Office 365 routing domain.
• Email Address Policies updated, adding alias@tenant.mail.onmicrosoft.com as a secondary address to all Mailboxes and Mail Users who have policies applied – this will be used for mail routing from on-premises to Exchange Online when we migrate mailboxes.
• A Send Connector configured from Exchange On-Premises to Exchange Online for our mail.onmicrosoft.com for secure mail routing outbound
• Receive Connectors configured to accept mail securely from Exchange Online
• Respective Inbound and Outbound Connectors in Exchange Online for secure SMTP between on-premises Send and Receive Connectors.
• When Organization Config Transfer is selected, selected policies copied to Exchange Online.

Exchange And Office 365 Hybrid

Additional configuration after performing Exchange Hybrid configuration

For a basic migration to Exchange Online for smaller organizations, additional configuration may not be necessary.

However, you may need to add additional configuration if you need to enable:

• Public Folder coexistence and migration
• Read/Write access to Calendars cross-premises using existing permissions
• On-Premises integration with Office 365, such as Teams integration using OAuth
• Unified Messaging configuration

One area many organizations do need to make additional configuration changes is to Mailboxes. Any Mailboxes that have the Email Address Policy checkbox disabled will not get the additional Office 365 routing address (typically in the format alias@tenant.mail.onmicrosoft.com) added automatically. Without this, pre-requisite checks for migrations will fail, as it needs this address to stamp as the routing address after mailbox migration.

You can use the Exchange Management Shell on an Exchange Server to check for users with the Email Address Policy disabled using the following cmdlet:

Get-Mailbox -ResultSize Unlimited | Where {$_.EmailAddressPolicyEnabled -eq $False}

This should provide a list of Mailboxes that require remediation.

You can either use PowerShell to update mailboxes en-mass, or use the Exchange Admin Center (or Exchange Management Console on Exchange 2010) to add an additional email address:

As shown in the example below, this should match the existing format for the alias and then use the tenant name (for example contoso or in this case goodmanenterprises) followed by .mail.onmicrosoft.com, for example TestMailbox125@goodmanenterprises.mail.onmicrosoft.com:

If you aren’t sure what to add, examine another account that has automatically been updated to validate the address you will add. Once complete, this should show as a secondary address (with a lower-case smtp type):

Migrating Mailboxes

With our Hybrid Configuration in place, we will begin by testing migrations to Office 365 before actually migrating real users. The process we’ll use will be the same one we’ll use when we migrate the rest of our mailboxes.

The purpose of performing test migrations is to ensure that everything works well, once we move mailboxes. Even with good connectivity in place, the correct firewall rules configured and Office clients installed, things can still go wrong. Therefore to ensure any surprises are avoided, we’ll create test mailboxes to use to validate the migration experience and test everything works from a user perspective, too.

Migration works in Exchange Hybrid by Exchange Online making an outbound connection to our on-premises Exchange Servers over HTTPS and moving mailboxes using the Exchange-native Mailbox Replication Service. Normally this is an internal Exchange mailbox move mechanism, but for Office 365, the Hybrid Wizard enables the MRS Proxy within the Exchange Web Services virtual directory. This allows Remote Moves. To be able to create batches of mailboxes to migrate, we need to define the URL for the MRS Proxy within Exchange Online. Thankfully the Hybrid Agent enables the MRS Proxy Component, and creates a Migration Endpoint in Office 365.

We’ll begin by accessing the Exchange admin center, via the Office 365 Portal and navigating to Recipients>Migration.

From the Migration Tab, we’ll select the plus (+) menu and choose Migrate to Exchange Online.

The New Migration Batch wizard should appear. On the first page of the wizard, we’ll choose to create a Remote Move Migration, then choose Next:

On the next page of the wizard, we’ll select the users to add to the batch. We can either import a CSV file, or select on-premises mailboxes from the Global Address List. For our test migrations, we’ll select the Test Mailboxes from the GAL:

On the next page of the wizard, we should see the Migration Endpoint pre-populated. This will have a GUID string, followed by .resource.mailboxmigration.his.msappproxy.net. This corresponds to the endpoint managed by the Hybrid Agent.

Next, we’ll choose a migration batch name. This should be descriptive as you’ll need to unique identify batches as you continue the migration. You’ll also need to choose a Target Delivery Domain. The target delivery domain is the Office 365 tenant domain, as set in our Email Address Policies and used for routing email from on-premises to migrated mailboxes. From a user perspective, this will not change their Primary SMTP address, though. If the domain in the format tenantname.mail.onmicrosoft.com is not selected by default, choose it from the drop-down list:

On the final page of the wizard, we’ll select notification and completion settings. It’s good practice to pre-synchronize mailboxes first, then when you are ready to actually move mailboxes, perform a final synchronization and switchover. Therefore, we’ll choose the Manually Complete the batch option which will allow us to control the switchover timing:

The new migration batch should be created, and show in the Migration tab of the Exchange Admin Center. As it begins, the status should change to Syncing. You can monitor the progress of all mailboxes within the batch by choosing the View details link:

By choosing View details we will see the status for individual mailboxes as they synchronize. For our test mailboxes in the batch below, we can select a mailbox and view progress, and if needed download a report detailing any errors or issues during the sync:

After all mailboxes in the batch have performed an initial sync, the status will change to Synced. Approximately every 24 hours, an additional sync will be performed to ensure content is up to date. At this stage, users will not see any changes as the sync has happened in the background.

Exchange And Office 365 Mail

When we are ready to switch over users within the migration batch, select the Complete this migration batch link:

Within approximately 30 minutes (for most batches) the final synchronization and switch should occur.

Testing functionality

It’s crucial to test functionality both from a service perspective and from a client perspective after moving test mailboxes.

To test key service functionality provided by Exchange Hybrid, we’ll conduct two core tests:

• Mail Flow
• Address List lookup and checking availability

These two tests will ensure that in addition to moving mailboxes, we’ve got the ability to email between migrated and on-premises recipients, and aspects like booking meeting rooms or checking the availability of colleagues work. Under the hood, this tests the connectivity for SMTP and it tests the ability for both Exchange Server to connect to Office 365 HTTPS endpoints, and for Exchange Online to connect over HTTPS to our on-premises infrastructure via the Hybrid Agent.

You can perform basis email flow tests using Outlook on the web. Send emails from on-premises and the migrated mailboxes to test basic mail flow:

To ensure secure mail flow is in place, set Out of Office replies for Internal recipients for the test mailboxes both on-premises and in Office 365. By validating that an Internet OOF reply is sent rather than an external one we check that the correct secured connectors are being used to send and receive mail between the two environments.

Next, ensure that the test mailboxes have existing meetings scheduled. Then, attempt to schedule a meeting from an Office 365 user checking the availability using the Scheduling Assistant of an on-premises user that has existing appointments. If this succeeds, connectivity via the Hybrid Agent is working as expected:

Perform the same test from on-premises, this time checking the availability of the migrated Office 365 account. This test will ensure that the Exchange Server can connect outbound over the internet to Exchange Online using HTTPS:

In addition to the service tests, ensure you test clients that represent your environment. Recommended client tests include:

• Pre/Post migration experience with Outlook users, using each version of Office deployed
• New client setup experience with Outlook users, again using each version deployed
• Repeat the above tests with domain-joined/network connected users and remote users
• Mobile Device Management reconfiguration experience for Mobile Users
• New mobile client setup using the Outlook Mobile App
• Re-perform mail flow and availability tests at each stage

Ensure you document the results of tests and take screenshots. These will be useful should you need to troubleshoot later, and provide material to use for any training guides you wish to provide to users.

As you complete your testing it will be common at this stage to progress to a technical pilot. This is usually where a contained group within the IT team migrate to Exchange Online. While you create your migration plan, collect feedback from this group to help remediate any technical issues or improve any user documentation you create.

With the technical preparation complete for your migration, including pre-requisites, Hybrid setup and configuration and comprehensive testing, you need to plan your actual migration.

Plan your migration batches

When migrating mailboxes, plan to move people who share together, together. Although Shared Mailbox access will work across Hybrid, and it is possible to ensure Read/Write Calendar Access works, your users will have a better experience if you move their mailbox along with other colleagues and shared mailboxes at the same time. This ensures you don’t need to perform workarounds for areas like Outlook Delegate functionality.

You can use Microsoft FastTrack’s Find MailboxDelegates script to produce a file for use in Excel and Migration Batches to organize your batches and Microsoft’s Batch Analysis spreadsheet to understand relationships within the exports.

What you may find though is a big web of sharing within your organization, with many people within departments sharing, and some limited sharing between departments resulting in effectively one batch if you used sharing as the only guide.

Therefore, expect to use the output from Microsoft’s script as a starting point and look for areas such as departments where the majority of sharing takes place and use these to create batches. Then where there is overlap between those batches (for example, if two people in finance share with two people in HR) either plan to move the batches together or on consecutive migration windows.

Begin with a pilot and then ramp up quickly

Using the batches you create, select one or more batches to use as your pilot group. Ideally, your pilot group will be representative of the business so that you will gain the confidence to move ahead quickly with your migration. An ideal (though sometimes ambitious) target for a pilot is around 10% of users.

When deciding how to schedule, sync, monitor and migrate mailboxes you have several options.

• If you qualify for FastTrack migration services (500 or more licences) you can provide your migration batches to Microsoft, and based on their conditions, choose when they will import the migration batches into your tenant, monitor their progress and complete them.
• You can use third-party tools to automate the migration process, which is useful if you are also moving other data, i.e. migrating email archives or migrating PST files to Office 365
• Use the Migration Batch wizard we used earlier in this article and import your migration batches as CSV files.
  For most migrations of less than a few thousand mailboxes, this is the easiest option.

If you migrate using migration batches, then you might find that you need to migrate one or two VIP users in each batch separately as you may want to schedule white-glove support at a predictable time. To allow you to pick selected users out of batches, you can use the approach detailed in my Moving Mailboxes between Migration Batches for simpler Exchange to Office 365 Moves article on Practical365.

With a successful pilot behind you, plan to ramp up migration velocity quickly.

To enable you to ramp up quickly, plan to pre-sync batches as early as practically possible, though only one to two weeks before planned migration switchover dates. This will allow you to ramp up by completing multiple batches within the same migration window.

As an example, smaller organizations (less than 500 users) have completed all their migrations over one or two evenings. Even some larger organizations (less than 5000) have completed the entire migration over one or two batches. You will find that large organizations (10,000+ seats) will ramp up to over 1000 per night – for some very large companies this is the only practical way.

However, you must go at a pace that your organization can support. A successful pilot should mean that less than 1% of users require any sort of support.

Summary

In this two-part series, we’ve walked through the steps to set up pre-requisites, implement Exchange Hybrid and migrated mailboxes to Office 365. Wondering what you should do next? You can find out more about what you can decommission after a Hybrid mailbox migration is complete over on Practical365.

This guide has outlined the process for Exchange to Office 365 migrations, providing step-by-step advice to help your journey to the cloud. However, if you’re looking for an experienced partner to manage your move to Office 365, Quadrotech offer a range of fast, reliable migration services for both archive data and live mailboxes.

For more information, please complete our contact form and one of our experienced migration team will be in touch to discuss your project and offer a quote.