title: audreylam.com Google Workspace → Microsoft 365 (xlab.studio tenant) — migration runbook date: 2026-06-06 status: DRAFT · proof-of-concept domain ahead of audreyinc rollout author: Dan Sellars · runbook drafted with Opus 4.7

audreylam.com email migration — Workspace → M365 under xlab.studio

Why this is worth doing now

Current Workspace billing across the two audrey domains: ~$36/mo (Workspace Business Standard for audreyinc at ~$28, Starter for audreylam at ~$8). Two mailboxes consolidated onto Exchange Online Plan 1 under the existing xlab.studio tenant cost 2 × $4 = $8/mo. That’s $28/mo / ~$336/yr saved without losing email functionality — just web Outlook instead of Gmail.

The xlab.studio tenant is already paid for, multi-tenant-flipped, admin-consent granted, and proven on OneDrive (101 MiB/s parallel ingest ceiling hit 2026-06-05). Adding mailbox workloads to it is the highest-ROI use of work already done.

This runbook does audreylam first as the proof-of-concept domain because:

• It is the smaller billing line — failure mode is cheaper.
• It is the lower-traffic mailbox — coexistence and cutover windows are more forgiving.
• The audreylam Google Workspace tenant is the one we have a fresh OAuth session against from 2026-06-06 — context cost on identity provisioning is already paid down.

audreyinc follows the same playbook only after audreylam is delta-sync green for 7 days post-cutover. Do not pipeline.

The driver math, made concrete

This holds only if both domains are single-mailbox. Each additional active mailbox at $4/mo erodes the saving by ~$48/yr — still positive ROI unless mailbox count is >7 per domain, which would be a surprise worth surfacing before committing to the migration.

Counter-driver — what we LOSE by leaving Workspace:

• Native Gmail UX (search relevance, conversation threading is different in Outlook, label-based foldering becomes Outlook category/folder hybrid).
• Google Drive on those addresses (mitigated — both domains’ Drive content is in the OneDrive ingest pipeline anyway).
• Google Vault retention (relevant only if either domain has had compliance hold needs — see Risk R-7).
• Calendar conditional formatting / Workspace-specific room booking flows (only relevant if calendar resources exist — see Risk R-3).

If none of those bite, the saving is clean.

Pre-flight requirements

Before firing any step, confirm all of these:

• [ ] xlab.studio tenant admin access on the Microsoft 365 admin centre.
• [ ] audreylam.com registrar access (DNS for TXT + MX edits).
• [ ] Workspace super-admin access on the audreylam tenant (for IMAP app-password generation and Workspace user delete after cutover).
• [ ] Inventory: every active mailbox, alias, shared mailbox, distribution list, and calendar resource on audreylam.com. Run before quoting timeline. Workspace admin → Directory → Users + Groups + Resources.
• [ ] Calendar event volume — count “upcoming events past today” so cutover timing accounts for invite-chain rewriting.
• [ ] Mobile device inventory — list every iPhone/iPad/Android with active Workspace mail accounts so users know which devices need re-setup post-cutover.
• [ ] Quote a maintenance window — 60 min cutover for MX swap plus 24-hour tail for delta-sync confirmation.

If any of these is unknown at fire-time, stop and answer it first. Most migration disasters trace to a missing inventory step.

The runbook

Phase 1 — Domain verification on xlab.studio (Day -1, ~30 min)

1. M365 Admin Centre → Settings → Domains → Add domain → audreylam.com.
2. Choose TXT record verification (lighter touch than MX during this phase — MX still points to Google).
3. Copy the MS=msXXXXXX value.
4. At the audreylam.com registrar: add TXT record at apex with that value. TTL 3600.
5. Wait 5-15 min, click Verify on M365. Success = domain shows under xlab.studio’s Domains list as “Verified”.
6. Do NOT yet enable the M365 wizard’s prompt to add MX/SPF/Autodiscover records — that would cut Gmail off. The wizard offers a “I’ll manage my own DNS” path; take it.

✅ Exit criterion: audreylam.com appears as a verified domain in xlab.studio without affecting current Gmail flow.

Phase 2 — License + user provisioning (Day -1, ~20 min)

1. M365 Admin Centre → Billing → Purchase services → Exchange Online Plan 1 (web Outlook + 50 GB mailbox, $4/mo). Buy quantity = number of active audreylam mailboxes inventoried in pre-flight.
2. Admin Centre → Users → Active users → Add user: - Username: <existing-local-part> at audreylam.com - Display name: matches Workspace display name - Assign Exchange Online Plan 1 license - Skip password — they will set via OAuth or password reset later
3. Repeat for each active mailbox.
4. Note: the new M365 user UPN at <local> at audreylam.com lives alongside the Workspace mailbox at the same address. Both can hold messages simultaneously during coexistence. MX still points to Google, so all new inbound mail goes to Workspace until cutover.

✅ Exit criterion: every audreylam mailbox has a matching M365 user with a license, but no mail is flowing to M365 yet.

Phase 3 — IMAP migration setup for message body + attachments (Day -1, ~45 min)

1. On Workspace admin for audreylam.com: - For each user, generate a 16-char app password (Workspace Security → 2-Step Verification must be on first, then App Passwords). - Capture each in 1Password under Migration · audreylam IMAP source.
2. M365 → Exchange admin centre → Migration → Add migration batch.
3. Migration type: Migrate to Exchange Online → IMAP migration.
4. Source server: imap.gmail.com, port 993, SSL/TLS.
5. CSV template: provide one row per mailbox with columns EmailAddress, UserName (= source Gmail address), Password (= app password from step 1).
6. Target delivery domain: audreylam.com (the verified one).
7. Start the batch. Initial sync runs in background — large mailboxes (>10 GB) can take overnight.
8. Monitor: Exchange admin → Migration → batch detail. Watch for “Synced” counts climbing per mailbox. Errors at this stage are usually app-password or IMAP-enabled-for-user issues at the Workspace side.

✅ Exit criterion: batch reaches “Synced” state for every mailbox with zero errors. Delta-sync continues running every 24 hours in the background until the batch is completed.

Phase 4 — Calendar + Contacts migration (Day -1, ~60 min)

Critical: IMAP migration does NOT carry calendar events or contacts. Use GWMME (Google Workspace Migration for Microsoft Exchange) — free from Microsoft.

1. Download GWMME from aka.ms/gwmme to a Windows machine (the only OS it runs on — borrow a Windows VM or use a Parallels instance on the Mac).
2. Run GWMME wizard: - Authenticate against the audreylam Workspace tenant (super-admin OAuth). - Authenticate against xlab.studio M365 tenant (global admin OAuth). - Select migration scope: Calendar + Contacts (not Mail — IMAP already covered that). - Per-user mapping: each Workspace mailbox → corresponding M365 mailbox.
3. Run. Calendar + contacts are pushed via Exchange Web Services API.
4. Spot-check: open Outlook web for one M365 mailbox, confirm last 30 days of calendar events and contact list appear.

✅ Exit criterion: every audreylam mailbox has calendar events and contacts matching the Workspace source.

Phase 5 — Pre-cutover DNS prep (Day -1 evening, ~10 min)

1. At the audreylam.com registrar, lower TTL on the MX record from whatever it currently is (probably 3600) to 300 seconds.
2. Wait at least 4 hours before cutover to let resolvers respect the new TTL.
3. Do not change the MX value yet — only the TTL.

✅ Exit criterion: dig +short MX audreylam.com shows TTL <= 300.

Phase 6 — Cutover (Day 0, ~30 min active + 24h tail)

Pick a low-traffic window. Saturday early morning EDT is ideal — both Workspace and M365 are running, MX swap is the only risky step.

1. Run final IMAP delta-sync. In Exchange admin → Migration batch → right-click → Start. This pulls everything new since last sync. Wait for “Synced” before proceeding.

2. Run final GWMME calendar/contacts sync for the same delta window.

3. At the registrar, change the MX record: - Remove: all aspmx.l.google.com / alt*.aspmx.l.google.com entries. - Add (priority 0): audreylam-com.mail.protection.outlook.com (M365 gives you the exact value in the Domain setup wizard — copy from there). - Keep TTL at 300 for the next 24 hours.

4. Update SPF record at apex (TXT): - Replace v=spf1 include:_spf.google.com ~all with v=spf1 include:spf.protection.outlook.com -all.

5. Add DKIM (Exchange admin → Email authentication → DKIM → audreylam.com → Enable signing → follow CNAME instructions at registrar).

6. DMARC (TXT at _dmarc.audreylam.com): if one exists, keep it; if not, add v=DMARC1; p=quarantine; rua=mailto:dmarc-reports [at] audreylam.com (with the actual address obfuscated for safety — see Risk R-9).

7. Test inbound mail flow: - From a non-domain account (Gmail, Fastmail), send a test message to the audreylam primary address. - Confirm it lands in M365 (Outlook web), not Workspace, within 2 minutes of MX propagation. - Send from M365 back to the external address. Confirm delivery.

8. Mobile device re-setup: users on iOS/Android remove the old Workspace account and add the new M365 account (auto-discovery via Outlook app is the cleanest path).

✅ Exit criterion: all inbound mail arrives at M365, all outbound mail leaves from M365 with SPF/DKIM pass, every mobile device is re-set-up.

Phase 7 — Tail period (Day 0 → Day 7)

1. Leave Workspace billing active for 7 days minimum. Some delayed mail may still hit Google’s MX cache; Workspace forwarding stays as a safety net.
2. Set Workspace user to forward any received mail to the new M365 address, as a belt-and-suspenders.
3. Run delta-sync verification daily: spot-check 5 random recent conversations on M365 web Outlook against the Workspace web inbox. They should diverge only by “new mail arriving at M365”.
4. Day 7: confirm zero divergence in any user mailbox. Delete the Workspace users (not the tenant yet) and cancel the Workspace subscription. Tenant can be deleted Day 30 if no surprises.

✅ Exit criterion: $8/mo Workspace bill stops, M365 picks up.

Risk register

Risks ordered by (probability × impact) — work them top-down before firing Phase 1.

R-1 · Hidden mailboxes, aliases, shared mailboxes (HIGH probability, MEDIUM impact)

Most migration overruns come from underestimating mailbox count. A domain that looks like one user often has info@, accounts@, mail@ aliases or shared mailboxes someone configured years ago and forgot.

Mitigation: Workspace admin → Apps → Gmail → User settings → check each user for delegated access AND check Workspace Groups for any <name>@audreylam.com that resolves to a real inbox.

Reversal path: if discovered mid-migration, license additional Exchange Online Plan 1 seats at $4/mo each. Inexpensive but extends timeline.

R-2 · MFA / app password failures on IMAP source (HIGH probability, LOW impact)

Workspace IMAP migration requires app passwords, which require 2SV on the source. Some users may have 2SV disabled, or app passwords blocked by Workspace security policy.

Mitigation: verify 2SV is on for every audreylam user before Phase 3. Workspace admin → Security → 2-Step Verification → enforce.

Reversal path: for any user who blocks app passwords, fall back to OAuth IMAP migration in M365 (newer “modern auth” path — slower setup, no app password needed).

R-3 · Calendar resources / room bookings (MEDIUM probability, HIGH impact if present)

If audreylam.com has Workspace Calendar Resources (conference rooms, equipment), they migrate via GWMME but the Outlook room-mailbox UX is different. Booking workflows may break for any user with active recurring events tied to a resource.

Mitigation: inventory resources in pre-flight. If zero, ignore. If any exist, treat as a separate sub-runbook with its own cutover.

Reversal path: keep Workspace resources active for an extra 14 days, manually re-create bookings on M365.

R-4 · iCloud / Apple Mail clients configured with Workspace IMAP (MEDIUM probability, LOW impact)

Mail.app on Mac and iOS configured against Workspace IMAP won’t auto-flip to M365 — they’ll silently keep trying old IMAP and showing stale inbox.

Mitigation: Day -1, email every audreylam user: “On Saturday morning, remove your audreylam Workspace mail account from any device and re-add it via the Outlook app (auto-config will pick up M365).”

Reversal path: support 24/7 for 48 hours post-cutover; users typically fix themselves once email visibly stops.

R-5 · Microsoft 365 trial conflict on audreylam.com (LOW probability, HIGH impact if hit)

If anyone ever signed up for an M365 trial using an @audreylam.com email, Microsoft auto-creates an unmanaged tenant for that domain. When you try to add it to xlab.studio, you’ll see “This domain is already in use” with no clear remediation in the UI.

Mitigation: before Phase 1, run https://login.microsoftonline.com/common/userrealm/<any-address>@audreylam.com?api-version=2.1 and check the response — if NameSpaceType is Managed and the AuthURL points to a tenant ID other than xlab.studio’s (6af7ea0e-402d-4e12-b127-8111b743bbeb), there is a ghost tenant.

Reversal path: Microsoft support ticket to assume admin of the unmanaged tenant, then delete it. Adds 1-2 business days to timeline.

R-6 · MX propagation tail eating mail during cutover window (LOW probability, MEDIUM impact)

If MX TTL was not lowered well in advance, some resolvers cache the old Google MX for hours after cutover, sending mail to Workspace that M365 never sees.

Mitigation: lower TTL 24 hours before cutover (Phase 5).

Reversal path: keep Workspace forwarding to M365 for at least 7 days (Phase 7 step 2) to catch resolver-cache stragglers.

R-7 · Google Vault / legal hold content (LOW probability, HIGH impact if applicable)

If audreylam.com has ever been subject to Google Vault retention or legal hold, deleting the Workspace tenant loses that audit trail. M365’s equivalent (Compliance Centre → Litigation Hold) does not back-fill.

Mitigation: ask “has audreylam ever been subject to a legal hold?” explicitly. If yes, export Vault contents to PST before Day 7 deletion.

Reversal path: none — this is a “stop and resolve before cutover” risk.

R-8 · Data residency — xlab.studio tenant lives in Japan (LOW probability, MEDIUM impact)

xlab.studio is provisioned in Microsoft’s APAC region (empirically confirmed 2026-06-05 — see project_xlab_studio_tenant_lives_in_japan_2026-06-05). audreylam mail content will be physically stored in Japan after migration.

Mitigation: confirm this is acceptable for the data classification of audreylam mail. For personal Workspace content, almost certainly fine. For commercial / regulated content, may need a US-residency tenant or a Multi-Geo license addition (~$1/user/mo extra).

Reversal path: if data residency surfaces as a blocker, migrate audrey domains into a US-region M365 tenant instead. Higher setup cost; same runbook applies.

R-9 · SPF / DKIM / DMARC misconfiguration breaking outbound delivery (MEDIUM probability, MEDIUM impact)

Wrong SPF or unsigned DKIM causes external receivers (Gmail, Fastmail, corporate Exchange servers) to silently drop or junk audreylam outbound mail. Hard to detect until you ask a recipient “did you get my email?”

Mitigation: after cutover, send test messages to: - Personal Gmail (Google’s filter is the strictest) - A Fastmail address - A non-Microsoft corporate address if available

Use mail-tester.com for SPF/DKIM/DMARC score. Aim ≥9/10.

Reversal path: SPF/DKIM are TXT records — fix at the registrar within 60 seconds. DMARC enforcement is p=quarantine not p=reject for the first 30 days to allow learning.

R-10 · Outlook user education debt (MEDIUM probability, LOW impact)

Anyone moving from Gmail to Outlook web hits UX differences: no conversation threading by default, label-based foldering becomes hierarchical folders + categories, search is less forgiving.

Mitigation: one-pager handover doc for end users showing the 5 most common task equivalents (search a sender, label a thread, archive, snooze, delegate).

Reversal path: none needed — temporary muscle-memory friction, settles within 2 weeks.

Open questions to resolve before firing

These must be answered explicitly, not assumed:

1. How many active mailboxes on audreylam.com? Drives license cost and timeline. Single mailbox = 4 hours of work. Five = ~1 day.
2. Any shared mailboxes, distribution lists, or calendar resources? Drives Risk R-3 sub-runbook scope.
3. Is 2SV enabled for every audreylam Workspace user? Drives Phase 3 IMAP setup path.
4. Has audreylam ever had a legal hold or Vault retention applied? Drives Risk R-7 — non-negotiable to answer before Day 7 deletion.
5. Is APAC data residency acceptable for audreylam mail content? Drives Risk R-8 — could pivot whole strategy if no.
6. Confirm cutover window with users. Saturday early-morning EDT recommended; align with user schedules before booking.

Total estimated effort (single-mailbox case)

~3 hours active attention spread over ~1 week of elapsed time, with the risky 30-min window on Saturday morning. Multi-mailbox cases scale Phase 3 and Phase 4 roughly linearly.

What I’d do differently next time (anticipated)

After audreylam, the audreyinc runbook should:

1. Move TTL-lower into pre-flight — saves one waiting cycle.
2. Run GWMME against multiple mailboxes in parallel — the Windows tool handles concurrency; audreylam will tell us if any per-mailbox quirk surfaces.
3. Pre-stage the M365 user accounts as soon as the domain verifies — they can sit unlicensed until you’re ready to assign. Avoids a “Phase 2 happens late on cutover day” anti-pattern.

Cross-references

• Workspace export to OneDrive — the file-content pipeline that runs separately from this email pipeline (project_audreylam_workspace_dead_at_98gb_resume_runbook_2026-06-06)
• xlab.studio tenant baseline (Azure multi-tenant flip + JP residency confirmation, 2026-06-05/06)
• Multi-tenant first-time programmatic work compounds — single-tenant proof first (user_multi_tenant_first_time_compounds_2026-06-05)
• Headless OAuth runbook — applies if any phase requires re-minting tokens during migration (feedback_headless_rclone_onedrive_oauth_runbook_2026-06-06)