Data migration into Google Workspace

Birchline's Exchange servers hold about 14 terabytes of mail, calendars and contacts for 1,100 mailboxes, and the file servers hold another 9 terabytes of department shares, not counting the product photo library that moved to Cloud Storage earlier in the year. At the eleventh session, Sofia puts the numbers on the whiteboard and asks Owen the question every migration starts with: "What do people actually need on day one, and what can follow?" This lesson covers the strategies and Google tools for moving data into Workspace, and how to match them to a situation.

Migration is a project, not a button

A Workspace migration moves three kinds of thing: identities (accounts and groups, covered in lessons 3 to 7), data (mail, calendars, contacts and files) and people's habits (how they work, which needs training and support). The data part has its own decisions: what to move, in what order, with which tool, how long it will take, and how to keep both old and new systems working while the move happens.

Sofia's rule is that the plan is written before any tool is chosen. The plan answers who moves when (the waves), what moves for each wave (all mail or only recent years, which shared folders), how mail is delivered during the transition (coexistence), when the switch happens (cutover) and what happens if something goes wrong (rollback).

Migration strategies

There are three broad strategies, and most real migrations combine them.

A big bang migration moves everyone at once over a weekend. It avoids a long period with two systems, but everything must work at once and the support load on Monday morning is enormous. It suits small organizations, such as Trailhead Rentals with 48 people.

A phased (staged) migration moves people in waves over weeks or months, usually by department or location. Each wave learns from the last, and the help desk can cope, but the organization lives with two email systems for a while, so mail delivery and calendar free/busy information must work across them. It suits Birchline's 1,100 staff.

A pre-stage and cutover approach copies most historical data in the background before the switch, then copies only the recent changes (a delta) at cutover, so that users arrive in Gmail with their history already there. It can be combined with either of the others.

Google's migration tools

Google provides several migration tools, each aimed at a different source and scale, and the exam expects you to match the tool to the situation. Product names and capabilities change, so check Google's current comparison before choosing.

For Birchline, the choice follows from the scale and the sources. Mail, calendars and contacts for 1,100 Exchange mailboxes, plus 9 terabytes of department shares, point to Google Workspace Migrate, which handles both mail and files at enterprise scale. Sofia plans to run it on two virtual machines in the bl-shared-net project, which has network connectivity to the data room. Trailhead Rentals, with 48 mailboxes on a hosted IMAP service and a shared Dropbox, is a better fit for the data migration service in the console for mail, and a simple file transfer into a shared drive for the Dropbox content.

Planning waves and estimating time

Migrations take time because data must be read from the old system and written to Google within the limits both sides set. The old servers' capacity and Google's rate limits for writing mail and files decide the realistic speed, which is why tools let administrators tune the number of parallel workers. Owen does not try to predict exact speeds; he estimates with a planning rate measured in Birchline's own test migration, and then plans waves that fit into weekends.

# Plan migration waves from a planning rate measured in a test run.
# Mailbox sizes are totals per department in gigabytes (illustrative).
departments = [("IT pilot", 14, 120), ("Finance", 40, 610), ("Marketing", 35, 520),
               ("E-commerce", 30, 380), ("People and culture", 20, 240), ("Buying", 45, 900),
               ("Other head office", 60, 700), ("Warehouse office", 30, 300),
               ("Store managers", 40, 520), ("Store and warehouse floor", 786, 2400)]
GB_PER_HOUR = 55          # measured in Birchline's test migration with the planned workers
WEEKEND_HOURS = 40        # Friday 18:00 to Sunday 10:00
waves, current, hours = [], [], 0.0
for name, people, gb in departments[1:]:      # the pilot moves on its own first
    need = gb / GB_PER_HOUR
    if current and hours + need > WEEKEND_HOURS:
        waves.append((current, hours)); current, hours = [], 0.0
    current.append(name); hours += need
waves.append((current, hours))
print("Pilot:", round(120 / GB_PER_HOUR, 1), "hours")
for number, (names, h) in enumerate(waves, start=1):
    print(f"Wave {number}: {round(h, 1):5} hours  " + ", ".join(names))

Pilot: 2.2 hours
Wave 1:  31.8 hours  Finance, Marketing, E-commerce, People and culture
Wave 2:  34.5 hours  Buying, Other head office, Warehouse office
Wave 3:   9.5 hours  Store managers
Wave 4:  43.6 hours  Store and warehouse floor

The plan produces several weekend waves for the main migration. The floor staff wave stands out: about 2.4 terabytes for 786 people, needing more than one weekend on its own. Sofia's response is to pre-stage it: copy mail older than 90 days during the weeks before the wave, so that the cutover weekend only needs to copy recent mail. Frontline staff also have small mailboxes and little history that matters, so Birchline will move only the last two years of mail for them, with older mail kept in Exchange archives until the legal retention period ends. That is a business decision documented with legal and HR.

Coexistence: two systems at once

During a phased migration, some people are in Gmail and some still in Exchange, and they must be able to email each other, see each other's free/busy time and book meetings. Making this work is called coexistence, and it is the most technical part of a migration plan.

Mail routing must deliver each message to wherever its recipient currently lives. A common pattern is split delivery: the MX records stay pointed at the old system during the migration, and the old system forwards mail for migrated users to Google, using a routing address at a test subdomain or the Google-provided domain. When most users have moved, the MX records are switched to Google and the pattern reverses, with Google forwarding mail for remaining users to Exchange. GCP-211 covers mail routing settings.

Calendar interoperability lets Google Calendar and Exchange share free/busy information, so that a migrated user can see when a colleague still on Exchange is busy, and vice versa. Google provides Calendar Interop settings for Exchange and Microsoft 365. Directory consistency matters too: both systems should show everyone in the address book, which synchronization (lesson 7) provides on the Google side.

Cutover and the first day

Cutover is the moment a wave stops using the old system. For each Birchline wave, the cutover checklist runs from Friday evening: final delta migration, mail routing changed so the wave's mail goes to Gmail, Outlook profiles retired or reconfigured, devices signed in to the Google apps, and help desk staff and floor walkers ready on Monday morning. Before the wave, users receive guides on what changes and a short training session; after, there is a feedback survey and a list of problems for the next wave.

Every plan also says how to roll back: if a wave's cutover fails badly, mail routing can be returned to Exchange, where the mailboxes still exist, because Exchange is not decommissioned until every wave has moved and stabilized.

Files: shared drives and ownership

Moving files is not just copying. Department shares on a file server belong to departments, not people, so they should land in shared drives, where files belong to the shared drive and stay when people leave (GCP-211). Personal home folders map to each user's My Drive. Before migrating, Birchline's data owners review their shares: duplicate copies, old installers and archived project folders are left behind, and permissions are redesigned around the acl- groups from lesson 5 rather than copied from the file server's tangled permission lists.

Communication is part of every wave. Two weeks before cutover, each person in the wave receives a short message explaining what will change, when, and where to get help; one week before, a fifteen-minute training session shows Gmail, Calendar and Drive with Birchline examples; and on cutover morning, floor walkers in each office and a dedicated help desk queue handle questions. The feedback survey after each wave feeds directly into the next wave's messages and training.