Google Migration Strategies: A Customer’s Perspective
After migrating my own institution from Google to Microsoft, I have been fortunate to take part in various customer transitions as a member of eGroup | Enabling Technologies’ Advisory practice. These experiences have granted me a bilateral perspective, where I am learning from multiple scenarios, while also having an institutional leader’s viewpoint.
Based on my experience, most organizations choose to either switch to Office 365 (Outlook, OneDrive, Teams, Excel, PowerPoint, etc.), or to Microsoft 365 (which includes additional security features as well as Operating System licenses). These migrations are partially due to the price tag associated with the subscription of Google Workspace, the need to streamline support, or to reduce costs, given the fact that many organizations already own some variation of Microsoft licenses.
The trend for organizations to migrate away from Google Workspace (rebranded from G Suite in October 2020) is ongoing and has contributed to several factors, including:
- Common use of the Microsoft Productivity Suite in Businesses
- Ease of Managing a Single Platform’s Ecosystem Across an Enterprise
- Streamlining Licenses
- Reducing the Total Cost of Ownership by Consolidating/Standardizing a Single Technology Stack for Mail, Calendars, File Shares, and Authentication
During my time assisting clients embark on these migrations, I have employed a plan and approach, comprised of best practices based on repeated pitfalls and lessons learned.
Initiating a Plan
Various approaches in building a migration plan exist, and it is imperative to avoid pursuing a method on either end of the spectrum. At one end, are those who go full throttle with the mechanical aspect of migration, and immediately start moving mailboxes, folders, files, calendars, and address issues. This embodies risks and leads to moving data files that could be obsolete. Furthermore, most users do not respond kindly to surprises or changes prior to being forewarned.
At the other end are those who meticulously account for every possible scenario and aspect of the migration, and spend a great deal of capital and time on a comprehensive planning process. By the time they are ready to initiate their plan, organizational fatigue and lack of enthusiasm engulfs the team, and the appetite for any change has totally subsided. A key to success is to develop a sensible plan with sequential stages, effective communication, and realistic timelines.
The highlights below detail a sequential plan you can utilize to organize and lead your next migration.
Phase I – Identify Your Existing Licenses and User Personas
A review of existing user classifications (i.e., frontline workers, administration, power users, etc.) and licenses will provide a holistic picture of the task ahead. In several cases, organizations had subscribed to licenses that were otherwise dormant.
Phase II – Develop an Inventory of All Devices and Identify Needed Upgrades
Building a comprehensive list, or inventory, of supported devices (including versions of OS and/or other applications), will present the opportunity to identify users who will require an upgrade to their devices, operating systems, Microsoft Office, BitLocker, or security patches. Upgrading devices is an integral part of the plan to streamline support and ensure a consistent user experience.
One of the major challenges is to plan for users who wish to move from using web-based Google apps to Microsoft Office local apps on their devices. This shift requires training and the adoption of organizational change management strategies to ensure a smooth transition. If Outlook is already a platform of choice for accessing Mail, Calendars, and Contacts, the user experience will be significantly easier, and the learning curve will be minimal/none.
Phase III – Form a Strong and Effective Communication Plan
Users are generally open to adopting a new tool, provided they feel it meets or will exceed their expectations. The key is to start an informative communication campaign outlining the rationale for this migration and to avoid surprises. It is imperative that the message addresses the Five “W’s:”
- What are we planning to do? Migrate from Google to Microsoft Office 365. Ask teams to start incrementally removing unwanted folders, files, and mail messages.
- Why are we doing this? Cost and additional functionalities; state the benefit to the user. The key to a successful migration is buy-in by all stakeholders and answering the, “What is in it for me?” (WIIFM) question positively.
- Who is doing this? Combination of IT and other resources with expertise and experience.
- When are we doing this? State that the timeline is under development and additional information is forthcoming.
- Where are we doing this? Articulate that this will impact the entire enterprise and that all of their files, folders, and mail messages will be protected during this migration.
Phase IV – Proof of Concept
Identifying a group of individuals to participate in a pilot project will provide the IT team with valuable experience regarding the process and potential pitfalls. It is imperative that the outcome be documented and reviewed. This will be an indispensable report that sets clear expectations for the entire migration lifecycle.
There are five important points to consider during this phase:
- The first point involves identifying a third-party migration tool. While Microsoft provides a migration tool for Office 365, most organizations opt to review and ultimately license other tools. Other tools are chosen due to the versatility of commercial products, which include: building a cloud depository of Google data, ensuring permissions and folder structures are migrated accurately, and minimizing the bandwidth throttling that happens as a result of large file transfers from Google. These migration tools are generally licensed annually, and upon termination of their subscription, will erase any files stored in their cloud storage.
- Secondly, it is important to identify users with both large and average file and email sizes for the pilot migration. This provides best-case and worst-case scenarios to build timelines. Generally, a single larger file takes longer to transfer than a series of small files.
- Thirdly, during this proof-of-concept period, ensure that Gmail is still the primary platform for receiving mail and documents and that there are no changes to DNS. This will ensure that users are not adversely impacted by split files and emails. Reconciliation of files and mail messages down the road due to a case of a spilled delivery is daunting.
- Fourth, if the decision has been made that Microsoft’s built-in migration tool is not sufficient and the need to purchase a commercial tool is warranted, it is recommended to invest in purchasing a few third-party licenses to test migration. While commercial products have costs associated with them, the lingering question of using one of the Open-source tools for migration has been raised on a regular basis. The answer to successfully using an open-source product depends on several factors, including:
- Access to in-house programming expertise to modify codes, if needed.
- Organizational appetite to use a product that might not finish all the steps (thus having a potential need for manual intervention such as reviewing permissions, etc.).
- Or, a lack of a vendor to provide support and updates.
One of the commercial products that have proven effective is BitTitan. It provides the ability to maintain multiple tenants and environments during the migration process and beyond.
- Finally, it is important that the proof-of-concept accounts for all products that are included in the migration strategy. There have been cases where only Gmail and Calendar have been migrated without including G-drives. This could lead to a test plan that is half-baked and lacks a realistic schedule or scale.
As part of the last step in the proof-of-concept process, it is highly recommended that a “spot check” of files and folder permissions be conducted to ensure permissions settings are migrated accurately.
Phase V – Spring, Summer, Fall, and Winter Cleaning
Perhaps this is one of the only times that users are inclined to remove unwanted files, folders, and emails. The more dated files are removed, the shorter the migration takes. While we emphasize that users remove their unneeded files for the sake of shrinking their footprint, we do not encourage or sanction mass deletion that we have seen transpire with certain users. This is counter-productive and could adversely impact organizational data. The idea is a sensible “spring cleaning” of old files to improve the overall migration schedule, and to reduce any reindexing time. This is a message that clearly needs to be communicated with a timeline to the user community on several occasions. One approach to keep users engaged and help to conform, is to state that the users with the largest files will be part of the last migration group. This method has repeatedly been proven effective in getting traction.
Phase VI – Third-Party Software Dependencies
One of the areas that generally leads to unexpected questions or concerns is the integration of third-party applications with Google Workspace. These are generally a one-way transfer of documents/files, using calendar events or distribution lists. To minimize any issues that may arise from converting these plug-ins, I recommend sending a survey to all users requesting their feedback on all applications they may have integrated with Google Workspace. In most organizations, these app integrations evolve organically, and a lack of documentation is prevalent. Once a list is compiled, it requires minor effort to identify a comparable solution or plug-in to support Office 365 (MS Exchange). Apart from a few custom applications that required minor code changes, we did not encounter any app that did not have comparable Exchange integration. The biggest takeaway is to identify these apps in advance so that a corrective measure could be deployed during the migration.
Phase VII – Building a Migration Model
Depending on the number and size of the user population, adopting a three-phase migration model driven from Everett Rogers’ Diffusion of Innovations, fits most organizations. This model facilitates building strong grassroots support, starting with Pioneers that also serve as product evangelists, thus pushing the next group of Majority Adopters forward. The third and last group of Laggards generally pose the biggest challenge, as they continue to rationalize their delay tactics in the migration activities. The best approach would be a consistent reminder, combined with a firm migration date sanctioned by the leadership.
While the native Microsoft migration tool is generally effective, depending on the size of mailboxes and personal drives, several organizations have opted to use a third-party migration tool. There are several public-domain products available in the market; however, based on my research, none are ready out of the box, and they pose various configuration issues and limitations. The commercial tools are generally priced per mailbox and add an additional cost to the project. To ensure there are no financial surprises, it is imperative to identify and include this tool as part of the overall project cost.
These tools also serve other purposes. In addition to expediting the migration process and moving file and folder permissions, a few of these tools are cloud-based. These tools provide the ability to establish a two-way sync, thus enabling files to move between Microsoft Office 365 and Google Workspace bidirectionally and seamlessly. This is a valuable benefit, particularly for organizations that are opting to migrate slowly, and have a need to maintain both environments for an extended period beyond a year. In addition, a couple of these migration tools provide archiving services to retain mailboxes and files during the migration process. Since most of these migration products are licensed annually, a review of the renewal date to decide whether to keep or dispose of archived files is crucial, as there are fiscal ramifications.
Phase VIII – Building a Sustainable Support Model
The technical aspect of the migration process is relatively mechanical, and users lose interest and patience relatively quickly due to its complexity; however, the availability of frontline technical resources to respond and address issues with the users on a timely basis has been proven to be the key ingredient to success. This mainly contributes to most issues stemming from users’ devices and their respective configurations with file and folder permissions. Furthermore, since reindexing files in the new environment could take time and several folders or files might not be available for immediate use, users generally assume their files are lost or have not been correctly migrated. Availability of technical support is vital to refocus the narratives and curb organization-wide unsubstantiated assumptions, as well as to reassure users that the process could take time to fully populate folders, files, and mailboxes. In addition, the frontline technical support team could easily conduct a triage to escalate any advanced issues of access configuration, licensing, or security settings, and relay to the appropriate team, such as cloud architects, security, or networking support for a quicker resolution.
During the first few months, individuals with strong customer service and client-centric mindsets are poised to do well with an effective support model. Any opportunity to build the initial frontline with these resources will save the organization time and preserve orderliness.
To provide a quick overview, the table below outlines key “Do’s and Don’ts” for our recommended migration strategy.
Best Practices for an Optimal Migration Strategy
| DO'S | DON'TS |
|---|---|
| Identify a core team to take ownership of the entire migration ecosystem. | Move all mailboxes and files unless they are deemed essential. |
| Communicate your plans on an on-going basis. (Some users tend to forget or ignore IT messages.) | Start migrating unless the proof of concept or a pilot project has been completed. |
| Identify all third-party applications that have direct or indirect ties to Google. | Assume all applications will work effortlessly. Some applications are specifically designed to solely work with Google, and a Microsoft version might not be available. |
| Archive large files that are historical in nature and are no longer accessed on a regular basis. | Underestimate the need for training users on the new platform. This is of particular importance with replacing Google Forms. |
| Establish a hotline to address user inquiries on a timely basis (This contributes to an initial positive experience). | Encourage bi-directional syncing of files. Establish a one-way migration from Google Drive to OneDrive to eliminate confusion and to reduce an extended migration period. |
| Create a flyer to educate your user community on the differences between Google and Microsoft applications including names, naming conventions, and default storage locations. | Allow the continuous use of Google apps such as Meets or other apps; this will prolong the migration process. |
| Maintain Google Workspace for 90 to 180 days post-migration to ensure there are no missing mailboxes, user files, forms, or other unaccounted data files. | Encourage users to use their local drives. Point their document folders to OneDrive. |
Mehran Basiratmand
CIO Strategic Advisors - eGroup | Enabling Technologies
Need Help Planning Your Next Migration?
Ready to elevate your IT solutions to Microsoft?
Contact our team today to start your road to Microsoft!
Last updated on November 14th, 2023 at 02:15 pm
