fbpx

Blog

Back

Moving Exchange Online to Exchange on-premises

8 Nov 2018 by Mike Weaver

It’s very easy to get wrapped up in the idea that everyone is ‘cloud first’, particularly if (like us), that’s how your organization operates. However, there are still plenty of organizations out there who remain on-premises and have avoided moving any workloads into Office 365, or other cloud-based systems.

There are plenty of reasons why this might be the case. Whether it’s a desire for control and visibility, compliance with governance or regulation requirements, – but for some organizations, there are still valid arguments for being able to ‘see’ and ‘touch’ the locations where your data is stored.

So, you’ve got the ‘Cloud’ people and the ‘On-premises’ people, both content in the IT choices they have made for their organization. But what happens when the former acquires the latter? Or the latter merges with the former?

Mergers, Acquisitions, and Divestitures, (MAD) are a regular, sometimes inevitable, and often turbulent, part of business operations. Many organizations that have not adopted Exchange Online, still find themselves needing to interact with it due to MAD activity. A major challenge that arises from this is the need to migrate acquired and merging companies from Office 365 and into their on-premises infrastructure.

This guide will briefly explore some key considerations for migrating Exchange Online into Exchange on-premises. We are going to focus on Microsoft Exchange Workloads here, as it is currently the most common.

Four key considerations for Office 365 to On-premises migrations

Size

Yes, it sounds basic, but you need to think about mailbox size. Users in Exchange Online have typically been restricted by few if any, size limits on their mailbox (50gb or more, in the most popular Office 365 plans). They have been able to send 150MB attachments and have probably never been prompted to do any cleanup. Not scared yet? If they are using archive features, they will also have online archives, and they could also be pretty big!

When you created your Exchange Environment you likely did an extensive sizing exercise, but you may not have taken these mailboxes into account at that point. If so, you may have to redesign certain aspects of the environment to support these additional storage requirements.

Archives

A common obstacle that can trip people up is that while many on-premises systems do not have Online Archives, Exchange Online users commonly do. If organizations are using an on-premises exchange archiving, our cloud to on-premises migration solution Cloud Commander allows you to move the archives into the primary mailbox. This makes sense if the archives are not very large, and you do not want to enable this feature as users move over. However, depending on your requirements, this may not be what you’re looking to do.

Another alternative for this issue is to leverage Exchange Online Archiving for these users. This can be particularly helpful if you intend to go into Exchange Online in the near future, but you’re just not ready yet. Many organizations have this included with their Enterprise Exchange CAL.

Max Attachment Size

This issue seems to always pop up in our Cloud Commander projects. For on-premises systems, this is especially prevalent. You need to ensure that both organizations have adopted the Exchange Online limit of 150MB attachments. If one environment has, and the other hasn’t then you will encounter issues. To ensure you avoid this problem, you need to change the organization-wide settings, apply the higher limit to the user’s migration, or the users will have items that do not migrate.  After the migration, you can change the users back to your standard policy, but keep in mind users may find this difficult if they try to forward large items.

Tip from the field:  In some cases, you may need to manually change config files on your CAS server as well.

Log Space

If you are running an older version of Exchange, and have been on it for a while, you may not have sufficient transaction log space. You may have to slow your migration to address this or consider circular logging for a short period of time to get through the migration. You should consider enhancing alerting on the databases you are moving to. If for example on Friday night you start hitting an upper limit, you may not notice it until you create a production outage over the weekend.  We cannot stress the importance of monitoring this!

These projects are harder than they look

There’s no getting around it, cloud to on-premises, or cloud to cloud migrations can be very complex, especially when they arise under the already challenging context of a merger, acquisition, or divestiture. There are ways to run these projects yourself (we will explore these in future posts) and key considerations you should bear in mind, but if it’s too much if you have too many users, scattered locations or particularly complex requirements there are capable solutions out there. Quadrotech’s solution Cloud Commander is one of the best and the most cost efficient.

Using a third-party tool:

There are a handful of third-party tools that can be used for a migration like this. These solutions will offer more flexibility, automation, and speed than any of the manual methods. If you have limited resources to dedicate, or a tight deadline (something that very often happens during MAD projects) then this might prove the best option for your project.

Our solution for cloud to on-premises migrations, Cloud Commander, reaches migration speeds of 50gb per hour, and 1.2tb per day. If you have a need for speed (as well as a need for a Cloud to on-prem migration solution, of course) – why not check it out.

Got questions about a project like this? Contact us here to find out more about how we can help.

whois: Andy White Freelance WordPress Developer London