Whitepaper:
Plan for Successful Google To Microsoft 365 Tenant Migration
- Tenant Migration: Executive summary
- Tenant Migration: Introduction
- The Cloudiway tenant migration platform
- Tenant Migration: Security
- Tenant Migration : Performance
- Mail Migration scope
- Mail Migration approaches
- Understanding the file migration sharing problem
- Steps to migration success
- Business benefits of using Cloudiway’s migration platform
- Conclusion
- Free trial today
- Appendix 1: Migration planning checklist
1. Tenant Migration: Executive summary
Tenant migration is a major part of moving from one business app suite to another. Many businesses today are unsure where to start with such a large task. Starting a tenant migration without an informed approach and a clear path can get expensive and time-consuming, not to mention stressful.
However, with the right tools and support, tenant migration is a painless process for IT staff, managers and end-users.
This whitepaper will identify the most common pitfalls during data migration and address the ways in which they can be avoided. The planning checklists included will help any business save time and money through each stage of migration.
2. Tenant Migration: Introduction
Migrating business users from their usual email system and business tools to a new system can be a daunting task for all involved. How can migration occur without business interruption? What premigration planning is required? How can you be sure that all data has been migrated? And even if the migration is a success, how do you get your users on board with embracing the new products?
This white paper covering tenant migration aims to provide a technical overview of considerations such as migration time, approaches, speed, and security, as well as an overview of what can and cannot be migrated.
This white paper, whose main theme is tenant migration, can apply to all types of tenant migration:
- Google Workspace to Microsoft 365 migration
- Microsoft 365 to Google Workspace migration
- Microsoft 365 to Microsoft 365 migration
- Google Workspace to Google Workspace migration
However, at the time that it was written, it was specifically covering the Google Workspace to Microsoft 365 tenant migration.
3. The Cloudiway tenant migration platform
Cloudiway is a cloud-based migration platform that contains a broad suite of tools and solutions to aid tenant migrations.
The platform provides a flexible approach to tenant migration, making it suitable for migrations of all sizes and complexities. Components are modular, allowing you to purchase only the tools you need to ensure that your tenant migration remain cost-effective.
As well as data migration, logging, and a migration dashboard, Cloudiway’s solutions include the following, which will also be discussed in this whitepaper:
| Mail migration |
|
| File migration | Choice of destinations for files including OneDrive, SharePoint, Microsoft Teams, Google Drive or a mix of both. Cloudiway will automatically convert popular file formats. Other options include metadata migration and preserving all existing files at the target (by renaming any source files with matching file names when they are migrated to the target). |
| Site migration | Pre-migration utility to create a comprehensive list of sites to be migrated, plus a tool to audit site content to help identify any content that cannot be migrated. |
| Group & Teams migration | Pre-migration utility to create a comprehensive list of groups to be migrated, and automatic creation at the Office 365 target of groups or shared mailboxes as well as their members and permissions. |
| Enterprise coexistence | For businesses who expect tenant migration to take longer than a weekend, co-existence offers a means for users on different remote systems to share calendar free/busy time, synchronize global address lists. Components are independent. |
4. Tenant Migration: Security
We take your privacy and security seriously at Cloudiway, and we have invested significant effort into making our platform and your data secure. Cloudiway provides a cloud-based application hosted in Windows Azure. It means that the software and data are centrally hosted and accessed by clients using a web browser and internet connection. In addition, Cloudiway’s SaaS benefits from Windows Azure’s certifications, ensuring security of the infrastructure, network and physical security layers of the Cloudiway cloud.
For total assurance, Cloudiway provides auditing tools, secure, authenticated data connections and a logging system. More specifically:
- Cloudiway doesn’t store your mail, files or site data
- the migration takes place in memory only: the migration engine connects to the source, pulls data and pushes it in real-time;
- connections to the source and the target are done using HTTPS so no data is transferred unencrypted over the internet; and,
- nothing is stored internally: no data persists in the platform.*
*For the delta pass mechanism, an object’s unique ID is used (eg, messageID or file ID). This ensures that no data is duplicated, and for efficiency, only the changes are propagated.
In addition, because the Cloudiway platform needs credentials to connect to the source and the target, you define connectors to connect to them and enter credentials that will be used for the connection. These credentials are stored encrypted using AES 256.
For complete peace of mind, we recommend that you create a temporary migration account for each remote system during your migration which you can delete at the completion of your project.
We automatically delete inactive projects and/or accounts after 90 days, or upon request.
5. Tenant Migration : Performance
The Cloudiway platform uses all available resources to provide the fastest migration possible and can support both small and large tenant migrations. The tenant migration engine allocates the capacity that you need to migrate the volume of data of your choice in the time slot you have allocated.
However, there are limitations. Many mail systems can heavily throttle users. When you perform too many API calls, the remote server will begin throttling and decrease the number of calls that can be performed each minute, thus reducing the migration throughput. Cloudiway continuously attempts to migrate email at the maximum capacity allowed to achieve the highest throughput. It’s also possible to mitigate the effects of throttling, when using the Cloudiway platform to migrate.
Microsoft 365 limitations
Microsoft 365 uses throttling policies to limit the resources consumed by a single account. To maximize throughput and limit throttling, Cloudiway follows Microsoft best practice and uses impersonation.
An account that has impersonation privileges can impersonate 100 users concurrently. The platform uses EWS (Exchange Web services) protocol; Microsoft theoretically allows throughput of around 300 MB per user per hour. The Cloudiway platform typically sees throughput between 200 Mb and 300 MB per user per hour. This gives an average throughput of around 500 GB per day with a constant migration of 100 concurrent mailboxes.
To further improve throughput, you can create additional connectors. For example, if you create two target Microsoft 365 connectors, you can migrate 200 users concurrently and reach a throughput of around 1 TB per day. You can also create connectors for each type of migration you’re performing, allowing you to migrate mail, files, sites, groups, and vaults in parallel.
During mail migration, mailbox item count is also a factor. Office 365 throttling policies limit migration to 1500 to 1800 mails per user per hour. Therefore, a mailbox with 1,000,000 small emails will be slower to migrate than a mailbox with 1,000 large mails containing attachments.
Google Limitations
Google has the same kind of limitations. In addition to standard throttling, Google service accounts have daily budgets and rate limits.
6. Mail Migration scope
6.1. Mail – what’s migrated
The following components can be migrated during your tenant to tenant migration.
- Emails
- Contacts
- Calendars
- Secondary Calendars
- Labels (primary label converted to folder; other labels discarded)
- Delegations
- Rooms and resources
- Tasks
- Inbox rules
In addition, Cloudiway provides some additional tools to enhance and simplify your mail migration such as Mail forwarding.
Vault archive migration to inbox, archive or mix of both
Google Vault archives can be migrated directly into a Microsoft 365 mailbox, or to the In-Place Archive folder, if required. You have full flexibility over Vault migrations. Mail items and their attachments can be migrated.
Email address conversion
This option rewrites email addresses found in the header of mail being migrated and replaces source email addresses with their corresponding target email addresses. For example, if Bob sends an email to his colleague, Chloe, from his source address bob@source.com to chloe@source.com and a week later, after migration, chloe@target.com replies to Bob, the Cloudiway platform has already updated SMTP header in Bob’s original email in her inbox, so her reply will be sent to bob@target.com.
Inbox migration to inbox, archive or mix of both
Cloudiway can create a partial archive from an inbox, which can preserve bandwidth immediately after migration and avoid it to be downloaded after the migration. The data would remain online and accessible from each user’s inbox as an In-Place Archive folder. After migration, only the most recent emails would be downloaded when each user first logs in, reducing overall bandwidth usage due to smaller mailbox sizes. You have full flexibility over how a partial archive is created.
6.2. Mail – what isn’t migrated
G Suite uses labels rather than folders to organize received emails, which means users can apply more than one label to a single email. Office 365 mail doesn’t offer labels, so storage for each email is limited to one folder. The Cloudiway mail migration platform uses the first label applied to an email and creates a folder with the same name, where the email will be stored. Any additional labels are ignored during migration.
Currently, inbound rules (including out of office rules) are not migrated from G Suite to Office 365.
6.3. Files – what’s migrated
The following components/features of a Google Drive can be migrated to Office 365 (OneDrive or SharePoint targets, or a combination of both).
- Documents (converted to .docx)
- Spreadsheets (converted to .xlsx)
- Slideshows (converted to .pptx)
- Google Drawings (converted to .png)
- Folders
- Permissions
- Uploaded files (eg: .pdf, .jpg)
- Metadata (Created By, Created DateTime, Modified By, Modified DateTime)
(note: migrating metadata slows down migration and can be toggled on or off)
In addition to converting the file format of migrated files, Cloudiway provides some additional tools to enhance and simplify your file migration.
Mix your targets
Shared files and folders are treated differently in Office 365, which means your shared project folder in Google Drive ends up scattered between your own OneDrive folders (for any files you’ve contributed) and the ‘Shared With Me’ folder (for any others other team members have contributed). To avoid this, heavily-shared Google Drive folders are best published to a SharePoint library — a better destination for collaboration.
On the Cloudiway platform, you can mix files and folders between OneDrive or SharePoint. Migration is fully flexible, allowing you to pinpoint a single file or to mass-migrate an entire Google Drive. A file can only be migrated once, so this requires careful planning (as is discussed elsewhere in this whitepaper).
Audit tool
Cloudiway’s audit tool builds a list of all Google Drive IDs and their respective owners, as well as the file location. It also detects Google Drive folders that are heavily shared and that are de facto good candidates for being migrated to SharePoint Online.
Before your tenant migration, you can use the audit results to decide whether you wish to migrate any files or folders to SharePoint Online. and if so, you can specify the site collection and document library for each folder to be migrated. Within document libraries, folder structures are entirely recreated.
These folders with specific destinations on SharePoint Online would need to be migrated prior to the general migration because Cloudiway only migrates a file once. Therefore, any folders with alternative targets will take priority.
Perform pre-processing
Before the tenant migration, the preprocessing task verifies that the mapping table matches the accounts declared in Google. It also checks the G Suite credentials to ensure migration can begin. When OneDrive is a target, the preprocessing tasks will check target credentials as well as provision any OneDrives that don’t already exist and assign permission to write to the OneDrive targets.
Opt to retain duplicates at the target
If your target already contains files and one has the same name as a file in the source, you have the option to overwrite it or preserve it. If you have opted to preserve all target files, the file from the source will be migrated with ‘_OLD’ appended to the file name (eg: ‘Timesheet_OLD.xls’)
6.4. Sites – what’s migrated
The following components/features of a Google Sites can be migrated to SharePoint.
- Horizontal navigation bar
- Permissions
- Site content
- Welcome page
- URLs
- Web pages (become site pages)
- Announcement pages (become discussion lists)
- File cabinet (become document library)
- Google list pages (become list libraries)
- Google Gadgets (if they have web part equivalents)
- Attachments
- Metadata (Created By, Created DateTime, Modified By, Modified DateTime)
Cloudiway provides some additional tools to enhance and simplify your file migration.
Get Sites tool
The Get Sites tool returns a list of all sites from any domains you’ve identified. This is a useful tool which provides a complete picture of sites that Cloudiway has access to migrate and avoids typos or spelling mistakes in long URLs.
Audit tool
The auditing tool helps you identify potential errors prior to tenant migration, such as unfound sites or broken items. It also discovers Google Gadgets and helps to identify if the platform can migrate them to an equivalent web part or not).
We recommend that you run this audit as many times as required prior to migrating to ensure your migration list is fully prepared and ready.
6.5. Sites – what isn’t migrated
Google Sites and SharePoint site collections are set up differently, which makes it difficult for some elements to be migrated successfully.
Google Site pages are organized in a tree hierarchy where pages can contain sub-pages (such as http://www.mysite.com/mainpage/subpage. SharePoint stores each site’s pages in a flat library; to avoid page naming conflicts, Cloudiway migration platform renames Google Sites pages as ‘mainpage_subpage’.
Google Site menu depth is unlimited, whereas by default, SharePoint is limited to two nodes. By default, Google Site menus with a depth of more than two nodes cannot be migrated. Only the first two levels will be migrated.
The Google menu control can contain text. SharePoint menus cannot, so text content in the Google Site menu control is lost.
The site logo is not currently migrated, but a solution is being developed so that it can be in future. Please get in touch if you would like this functionality.
Google gadgets that do not have web part equivalents are not migrated.
Announcements are migrated to SharePoint discussion boards. However, discussion boards do not support attachments. To work around this, announcement attachments are migrated in a SharePoint library with the post title.
Automatically generated menus (created with the ‘Automatically organize my navigation’ option within the ‘Configure navigation’ pop-up of any menu) are not migrated. However, if these are constructed manually, they can be migrated.
Google Drive files can be embedded in Google sites, but file owner information is not stored within the links, making it impossible to assign an owner and give permissions during migration. It’s also impossible for the Cloudiway site migration platform to determine where files are stored. To resolve these problems, consider using Cloudiway’s file migration tool, which can locate files and assign correct user access permissions. If you choose not to use the tool, none of the Google Drive files can be migrated (even if they’re public).
We strongly recommend you use Cloudiway’s file migration tool to in conjunction with the site migration tool to achieve the best migration results possible.
6.6. Groups – what’s migrated
The following components/features of a Google Groups can be migrated to Office 365 (groups or shared mailboxes).
- Conversation content, including:
- Answers
- Attachments
- Metadata (author, date of creation)
- Group memberships
- Membership roles
Cloudiway provides some additional tools to enhance and simplify your file migration.
Get Groups tool
The Get Groups tool returns a list of all groups from any domains you’ve identified. This is a useful tool which provides a complete picture of sites that Cloudiway has access to migrate and avoids typos or spelling mistakes in long URLs.
6.7. Groups – what isn’t migrated
Some content from Google Groups cannot be migrated between tenants.
- Embedded Google files and folders in posts
- The Manager role (no equivalent in Office 365)
- Tags/categories (no equivalent)
- Ratings and resolution status (no equivalent)
- Welcome page (no equivalent)
- Pinned topics are migrated, but not pinned (no equivalent)
- Announcements and Discussions are migrated as simple conversations (no equivalent)
It’s important to distinguish between attachments and embedded files. When a file is attached to Google Groups content, it is migrated. However, embedded files and folders are not migrated during Google Groups migration. As a result, their links will continue to work after the migration is complete. If you are also performing a Google Drive migration, bear in mind that any embedded files in a migrated group will continue to be accessed from the source rather than the target.
The Cloudiway platform doesn’t use any Google APIs to access Google Groups. To perform the migration, you will need to create a new Google user to use during migration and manually give it manager permission to each source Google group that you wish to migrate.
If any of your users have created a group, they will also need to add the new Google user to the group with manager permission. It’s therefore important that you notify your users that any groups they have created cannot be migrated unless this new user is added.
Delta passes can be used with group migration to ensure all batch migrations are completed. The Cloudiway platform uses the URL of the source group as the unique ID during migration. This ensures a group is only migrated once. However, this also means that a new reply on a group that has already been migrated will never be migrated.
6.8. Enterprise coexistence – what it does
Enterprise coexistence is a suite of communication tools that run independently of tenant migrations. Particularly useful during company mergers of different systems, coexistence may also be useful during longer-term migrations. It consists of three independent modules:
- calendar free/busy;
- global address list synchronization (GALSync).
Calendar free/busy
Calendar free/busy manages cross-platform communication with no impact on the end user. It provides a seamless connection between G Suite and Office 365 users who wish to look up free/busy time of users on either or both remote systems.
GALSync
GALSync automatically checks and updates user details, contact lists and group information stored in your global address lists on G Suite and Office 365. GALSync can be configured to check for address list changes as often as required, so each global address book remains up to date without any manual input.
7. Mail Migration approaches
Cloudiway’s migration platform helps businesses perform elaborate technical tenant migrations through a simple SaaS interface. As a result, migrations require no additional software installation or overhead, and migrations can be performed securely and quickly.
The Cloudiway platform is flexible enough to support all types of migration paths. Your migration strategy will depend on your business setup, type and size. Whichever migration path you choose, Cloudiway provides all the essential features outlined elsewhere in this whitepaper.
Two of the most common migration strategies are cutover and staged migrations. Cutover strategies involve migrating all data over a weekend, ready for your users on Monday morning. Staged strategies provide more flexible migration options, as discussed below.
7.1. Cutover migration
You migrate everybody over a weekend and perform a single migration pass. This strategy is the simplest to implement. After you have switched your MX records to point to the new system, you start migration.
Cutover migration is therefore a strategy where the entire company is switched at the same time.
7.1.1. Cutover migration benefits
- Fastest, simplest form of migration.
- Your users can start using all components of Office 365 immediately.
- New mails are received in the target messaging system.
- Old mails are migrated in a single pass.
7.1.2. Cutover migration considerations
You can combine your cutover migration with pre-staging, if required. In this case, during the days or weeks leading up to your cutover, you would migrate all mails, files, sites and groups older than, say, a week or a month, along with calendars and contacts, then on the day or weekend of your cutover, you would run a quick delta pass to migrate the remaining items.
7.2. Staged migration
A staged migration allows you to migrate batches of data over the course of a few weeks or months. This strategy is useful for migrations with large volumes of data (very full mailboxes or many Google Drives) and you estimate that you won’t be able to do your migration over a single weekend.
Cloudiway offers you additional flexibility in your approach to a staged migration. For example, for your email migration, you could migrate the last six months of emails over a weekend and leave older emails and email archives to be migrated after cutover, explaining to users that their older emails will appear soon.
Prestaging is also an option on the Cloudiway platform. For example, you could perform a multi-pass migration where you migrate most items before performing the final cutover. During the days or weeks leading up to your cut-over, you would migrate all items older than a week or month from mailboxes, Google Drives, groups, sites and vaults, then on the day or weekend of your cutover, you would run a delta pass to migrate the remaining items.
Cloudiway provides a number of options to help you find the best strategy for a staged data migration. We provide coexistence services, and batch migration of users, which you can define in any way you like. Basically, you can choose who, when and what gets migrated during each pass. Create batches by department, position, alphabetically, by certain types of data (mail, files, groups etc.), or any other way to suit your business needs.
7.2.1. Staged migration benefits
- Many flexible migration strategies when using the Cloudiway platform.
- Allows more time before final cutover, avoiding tight deadlines.
- Complex migrations can be completed without disrupting end users.
- Can be performed in batches according to your needs.
7.2.2. Staged migration considerations
Staged migrations tend to be more complicated than single cutover migrations. Therefore, it’s important that you have planned your approach thoroughly prior to starting any migration. This is particularly importing if you’re performing file and site migrations to a mixture of targets.
8.1. Plan, plan, plan
Without fully planning a mail migration from start to end, steps can be missed out or misunderstood and performed incorrectly. At worst, the wrong migration path can lead to an unsatisfactory migration that may need to be restarted from scratch, costing time and money.
Make sure you take time to analyze your migration goals and the details of what, how and when all data should be migrated. Take note of the source and target system details, the size and type of data to be migrated, and the timeframe for migration. Decisions of what to include in a migration are needed for:
- mailboxes: contacts, calendars, tasks, email, trash, source archives, target partial archives;
- files: metadata (significantly slows down migration if migrated), keep existing files at target;
- sites: run free Get Sites and audit tools to establish a list of sites and their content;
- groups: run free Get Groups tool to establish a list of groups to be migrated;
- enterprise coexistence: decided whether any of the components needed during migration; and,
- global: an agreed order for any batches of migrations.
8.2. Use workarounds to throttling
As discussed earlier, data migration can slow down due to throttling at both the source system and the target system. Throttling is often unavoidable on both G Suite and Office 365, but being prepared for it and mitigating it through a planned approach can often avoid a lengthy migration disaster.
To improve throughput, create additional connectors. For example, if you create two target Office 365 connectors, you can migrate 200 users concurrently and reach a throughput of around 1 TB per day. You can also create connectors for each type of migration you’re performing, allowing you to migrate mail, files, sites, groups and vaults in parallel.
To benefit from using multiple connectors, every connector must have a unique migration account that isn’t used for any other connectors. You will need to create additional migration accounts in your remote system first, then use each one in a single connector.
8.3. Keep end users happy
The most important aspect of a mail migration is a happy end user. Nobody likes change – particularly the uninformed, untrained user. They’ll be even unhappier if they start their computer on Monday morning and it grinds to a halt because of a poorly performed migration.
An informed user is a happy user! Although the actual data migration process should be as transparent as possible to the end user, keeping them informed prior to migration is beneficial. Consult with staff so they are aware of the full migration process and when it’s due to take place. Provide users with details of what will be migrated so that they too can plan for a successful migration. For example, if you’re not migrating the trash folder from inboxes, let your users know: it might seem like a small detail, but informing will avoid any post-migration complaints about the trash not being migrated. Ask end users to get in touch if they have any concerns about the migration process so that they can be addressed prior to migration.
As the Office 365 interface is different from G Suite, provide training and consider a short tip sheet for users to help them remember the basics. If end-user PCs need to have their settings tweaked after migration (for example, Outlook mail server access), ensure they have support available to either perform the tweaks or to help them through the process. If you’ve decided to archive older emails to avoid any network slow-down after migration, make sure their training or tip sheet has detailed how they can access their archives.
8.4. Check the source system setup
A data migration will fail if it doesn’t have the right information from the source system. One common problem is using email aliases instead of SMTP addresses, making the originating mailboxes impossible for the mail migration tool to identify. Another is that the admin password expires during the course of migration. Some mail migration tools will use a single account with impersonation rights to all user accounts, and these rights must also be granted at the source (or self-service tools offered to end-users to start their own migrations).
Taking time to audit the source system is a requirement for a successful migration. Follow this checklist to minimize any hiccups:
- check the user list contains no aliases (use primary SMTP addresses);
- create one or more migration accounts to use solely for migration, and then delete after;
- set migration account passwords to never expire;
- inform users of any tasks they should perform before migration (eg, consolidating/pruning files and identifying files that can’t be migrated); and,
- tidy up any sites and groups due to be migrated (in conjunction with Cloudiway’s free auditing tools).
8.5. Check the target system setup
It’s easy to overlook what’s required on a target system prior to migration, particularly if it’s new to the business. Mailboxes can only be migrated to a Office 365 if it’s ready to receive the data. Office 365 must have enough licenses purchased to accommodate all users prior to migration. In addition, all users must be provisioned, otherwise the migrated items have no inboxes or OneDrives to be copied to.
A general checklist for the target system includes:
- create one or more migration accounts to use solely for migration, and then delete after;
- set migration account passwords to never expire;
- purchase licenses for all resources at the target; and,
- provision all resources (users, rooms, equipment).
8.6. Leave time for post-migration tasks
After mailbox migration, your target system might need an updated global address book, or user terminals might need tweaks if mail is accessed through a client. A migration might also involve a domain name move, and these processes will need to be addressed before, during and after migration. These are just some of the tasks that must be addressed to ensure a successful migration process.
Post-migration tasks will differ, depending on the target system. The checklist below is provided as a general overview to the most common tasks:
- update global address books;
- make any changes required on end users’ local email clients to access the new mailboxes;
- if a domain name was moved, disable it at the source.
9. Business benefits of using Cloudiway’s migration platform
Not every migration tool provides a full, flexible suite of migration tools. Cloudiway are the only migration solution to offer a coexistence solution between G Suite and Office 365 for free/busy calendar queries and automatic global address list updates.
In addition, Cloudiway’s SaaS-based migration platform is installation-free, saving you time, effort and end-user interruption. It’s also a cost effective solution for all business types and sizes, with two free support tickets at any time during the migration process, plus consulting services are available, if required.
Cloudiway’s mail migration tool also works alongside its other migration tools, including file migration, mail archive migration, site migration, group migration and, of course, enterprise coexistence.
In addition, Cloudiway embraces the security and speed of the Azure framework, with delta pass technology a standard feature of any migration. Your data is always in your control.
- Use with free/busy calendar and automatic GAL updates
- Nothing to install
- Cost effective
- Two free support tickets
- Consulting services
- Scalable for big migrations
- Accurate migrations with delta pass technology
- Secure and fast solution due to Azure backbone
- Your data copied only to your target system
10. Conclusion
Cloudiway’s migration platform is both reliable and secure, with free support to help you during migration, plus fully scalable and flexible migration tools to meet all your migration scenarios. In addition, a variety of licensing options makes Cloudiway’s migration solution the most cost effective migration tool available. And for clients who need more help, our migration experts can provide consulting services to ensure your migration goes according to plan.
A general data migration checklist is included at the back of this document to help you plan for a successful migration from G Suite to Office 365.
11. Free trial today
If you’d like to test Cloudiway’s data migration platform, you can set up a free trial account today.
Visit https://portal.cloudiway.com to create a no-obligation migration account today.
For more information, get in touch with sales@cloudiway.com and we will happily answer any questions you may have.
12. Appendix 1: Migration planning checklist
Below is a general checklist to help you plan for migration. Every migration is different, so you might want to add further items to the bottom if you have other considerations.
Project planning
Migration goals made (eg, to get merged businesses on same mail/business app platform)
List of items to be migrated made (eg, mail, trash, contacts, calendars, delegations, tasks, metadata, source files with the same name as any existing files at the target)
Any existing Vault archives identified and destination chosen (eg, inbox or separate archive)
Migration strategy chosen (eg, cutover or staged)
If staged migration strategy, migration order/batches defined
Decision made about archiving older mail, and destination defined
Number of mailboxes to be migrated established
Expected total size of migration established
Migration timeframe established (eg, start date, end date)
End users notified of planned migration (and training performed/tip sheets provided)
Technical planning
Source server preparation complete (user list ready, special migration account(s) set up etc.)
Target server preparation complete (licenses purchased, resources provisioned etc.)
Post-migration planning
Post-migration tasks identified and included in migration plan
Any tweaks to end user local email clients identified and included in plan
Any MX record updates identified and included in plan
Any global address list updates to be made identified and included in plan
Outlook profiles recreated at destination, if required
Identify and find manual workarounds for any items unable to be migrated (eg, custom site gadgets, native Google file formats)
Special mail migration accounts deleted
