Uncle Rob’s Office 365 Migration Primer – Part 1

I had a meeting last week with a non-profit and during our discussions I heard many of the same things that I have heard in the past which indicate a total lack of understanding on the part of the end-user organization as to how their Outlook and Exchange actually work.  And it isn’t just end-users that seem to be confused, I have seen IT pro’s that also are completely in the dark, sadly more often than you would think.  And then I realized that there is little point in discussing Office 365 migration strategies if there is no understanding of the basic mechanics of Outlook and Exchange.  So, I’m going to do my best to lay out the basics in this post so that you have the knowledge you need to help you evaluate your migration options.

Exchange

Stating the obvious, Exchange is the backend server that supports all of the functions of Outlook.  Whether you are on-premise or in the Cloud (O365 or some other hosting provider), if you  want Outlook to be fully lit up you need to be talking to Exchange.  Exchange does many things; it is the email server, it is the backing store for all of your Outlook data, it hosts your Calendars and contacts, it is the “engine” that drives it all.  And it does this by various channels as it supports Outlook, it provides online access via OWA (webmail), it supports connections from phones and tablets.  It holds your “history” – all of your received and sent email, contacts and calendar info – as well as a bit of your future in the sense that your calendar holds future appointments, tasks and reminders.  And it is centralized so that all of the tools that access it – Outlook, OWA, the channels to drive phones and tablets – look at the same data.  If you make a change  in Outlook you can see the same change in OWA and on your devices.

 

Active Directory

Exchange doesn’t live in a vacuum, it always lives within an Active Directory which is the Microsoft backend for managing user information, security and authentication.  Whether you realize it or not, if you have an Exchange account you also have an Active Directory account.  Your AD account may be on-premise, it may be in the Cloud (as in Office 365 and/or Azure) or it may even be in both through a synchronization mechanism such as DirSync, AADsync or AADconnect which shares an synchronizes AD data between on-premise and Office 365/Azure.  You must have an AD account in order to have an Exchange account.  There are many,many pieces of information that Active Directory can hold for a particular user and some organizations populate many more of those information fields than do others.  Exchange makes use of some very specific fields that have to be populated in order for everything to work.  You don’t need to know about the fields for this discussion, just that they are there and they are referenced on a regular basis.

Outlook

Outlook is the Microsoft application that surfaces all of the Exchange data that is held for you on your PC.  I describe it this way as it is not the only tool to get to the data as OWA, your phone and your tablet also do the same thing.  There was a time, however, when Outlook was the only game in town.  Outlook has always been built to run in one of two modes when talking to Exchange:  Cached mode and non-cached.  Non-cached mode makes Outlook operate simply as a presentation interface into Exchange.  Any information that is being displayed is being directly relayed from Exchange itself, there is nothing “local” to the PC.  Outlook in non-cached mode is rather like using OWA without using a browser.  Cached mode creates a local copy of your Exchange data which Outlook then references first before requesting updated information form Exchange.  The idea is that network traffic is reduced and your information is available to you even if you have no network connection.  In the majority of cases, users run Outlook in cached mode as it is the default configuration.

OST & PST

If you are talking to Exchange in cached mode then you will have a local OST or PST file (depends on your version of Outlook) which is the local cache file for your Exchange data. These files are tied to a specific Outlook profile on your machine.  Each specific Outlook profile will have its own set of associated files. PST files are the older file type while OST files came into play with Outlook 2007 and newer.  OST files can be much larger than PST files which have an upper size limit of 2GB.  PST files, on the other hand, are truly standalone copies of your data and they can be used for more functions than just caching your Exchange data.  The archiving function in Outlook uses PST files to hold your archive data locally on the PC (it is not held inside Exchange).  A PST file is the only file type for holding a local copy of your data if you have created a link inside Outlook to a non-Exchange mail server such as Gmail or a POP3 mail server.  And if you use the export function in Outlook one of the file types that you can create is a PST.  PST files can be used to transfer data from one user to another or one machine to another.

 

Office 365 Account

Every user that is being migrated to Office 365 will require two things:  an Office 365 account (identity) and an Office 365 subscription (license).

Simple Migration

OK, now that you have the basics we need to discuss how all of this ties together at migration time.  But first we need to discuss the why’s of migration.

If you have a brand-new organization and brand-new Office 365 account’s there probably is no need for migration as there is nothing to migrate.  On the other hand, if you have had email running for years, Exchange or otherwise, you probably want to see the history and the forward data (think Calendars) imported (migrated) into Office 365.  And that’s where understanding the in’s and outs of Outlook and Exchange really comes into play.

The size and scope of your organization’s email “footprint” has a lot to do with how you migrate into Office 365; migrating 5 users is considerably easier and less complex than migrating 500 or 5000.  But the end goal is always the same and that is to ensure the data that is in the old system, whatever it might be, is replicated without error and with full “fidelity” into Office 365.  After all, what is the point of having a system that allows you access from pretty much anywhere and from almost any device if your precious data isn’t there?

Migrating only a few users can be accomplished fairly easily by just doing a PST export on the old system (old Outlook profile) and then import that data into Office 365 via the import function in Outlook.  Pretty simple overall but it quickly becomes tedious if you have more than a few users involved.  Also, a PST migration does not address issues around migration of shared data from Exchange (address books, public folders, distribution groups, etc.) or from other centralized email systems.  PST migrations can impose a significant load on your Internet connection if you have a number of users all trying to import their data at the same time so the best thing to do is to “stage” it a few users at a time.

I have worked with a few customers to do this type of migration and have seen it work successfully for up to about 20 users.

My next post will discuss Complex Migrations and the methods that can be followed to ensure success.