Google Workspace → Microsoft 365: Migration không chỉ là chuyển dữ liệu

Một vài điều mình ghi lại khi tham gia review phương án migration: Identity, Pilot, Coexistence, Cutover và giai đoạn đối chiếu sau Go-live.

Khi nói đến migration từ Google Workspace sang Microsoft 365, phản xạ đầu tiên thường là nghĩ đến email và file: Gmail chuyển sang Exchange Online, Google Drive chuyển sang OneDrive, Shared Drive chuyển sang SharePoint.

Nhưng khi nhìn toàn bộ project, phần khó hơn lại nằm ở những thứ không thể đo chỉ bằng số mailbox hay số file đã copy.

Identity có khớp không? Quyền truy cập đi theo dữ liệu thế nào? Trong thời gian pilot, mail flow giữa hai nền tảng sẽ chạy ra sao? Một Shared Drive nên trở thành SharePoint Site, OneDrive của owner hay một destination khác? Và sau cutover, đến lúc nào mới có thể nói migration đã xong?

Điểm bắt đầu không phải là công cụ migration

Tài liệu triển khai có sử dụng các công cụ migration để chuyển email, calendar và dữ liệu giữa hai hệ sinh thái. Nhưng nếu bắt đầu cuộc thảo luận từ công cụ, rất dễ bỏ qua câu hỏi quan trọng hơn: identity nào sẽ sở hữu dữ liệu sau khi sang Microsoft 365?

Trong mô hình đích, Active Directory on-premises được kết nối với Microsoft Entra ID thông qua Entra ID Connect và Password Hash Sync để account nội bộ và cloud đi theo một identity path rõ ràng hơn.

Trước khi data move, account đích phải tồn tại đúng, mapping phải rõ, và những trường hợp không khớp cần được nhận diện sớm thay vì để tới maintenance window mới xử lý.

Survey và chuẩn hóa Identity nên đi trước rollout

Một điểm mình thấy hợp lý trong cách project được tổ chức là thứ tự triển khai. Thay vì migrate đại trà ngay từ đầu, luồng công việc đi từ khảo sát hệ thống hiện hữu và chuẩn hóa identity sang pilot, coexistence, batch migration, Shared Drive mapping rồi mới đến cutover và hậu kiểm.

Mỗi bước giúp lộ ra một nhóm vấn đề khác nhau. Survey giúp thấy dependency; identity normalization giảm lỗi mapping; pilot kiểm tra các giả định ban đầu; coexistence giới hạn phạm vi ảnh hưởng; batch migration giúp dễ theo dõi hơn; còn reconciliation tạo thêm thời gian để tìm và xử lý exception sau Go-live.

Pilot vì vậy không phải một bản demo nhỏ. Nó là nơi để tìm những giả định sai trước khi chúng xuất hiện trên diện rộng.

Pilot có giá trị khi nó tìm ra những thứ mình không dự đoán được

Trong pilot và migration thực tế, exception xuất hiện ở nhiều lớp khác nhau: một số email có MIME/header không hợp lệ, calendar event có thể bị duplicate sau nhiều lần migrate, file tạm hoặc định dạng không phù hợp bị skip, một số file Drive cần kiểm tra lại, Outlook có behavior khác sau khi đổi platform, và Defender có thể tạo tải cao trên endpoint có workload đặc thù.

Mỗi loại issue lại cần một cách xử lý khác nhau: có trường hợp phải re-migrate, có trường hợp cần rename hoặc exclude có kiểm soát, có trường hợp thuộc về Outlook/profile hay endpoint policy chứ không phải dữ liệu migration.

Không phải issue nào cũng là lý do để dừng project. Điều đáng chú ý hơn là nhiều exception chỉ xuất hiện khi dữ liệu, permission và cách user làm việc thật bắt đầu đi qua platform mới.

Google Workspace và Microsoft 365 không tổ chức dữ liệu, quyền và application behavior giống hệt nhau. Vì vậy có những thứ cần bảo toàn, có thứ cần mapping lại, và có thứ phải chấp nhận remediation sau migration.

Coexistence giảm phạm vi ảnh hưởng, nhưng tạo thêm trạng thái phải theo dõi

Trong giai đoạn pilot, MX vẫn còn ở Google và Google tiếp tục là luồng nhận mail chính, trong khi nhóm pilot đã bắt đầu làm việc trên Exchange Online. Mail cho pilot được đưa sang Microsoft 365 để kiểm thử, còn nhóm chưa pilot vẫn tiếp tục workflow trên Gmail.

Cách này tránh một cutover “big bang” quá sớm, nhưng đồng thời tạo ra nhiều trạng thái cần kiểm soát: mail đang đi qua platform nào, user thuộc nhóm nào, routing nào là mong đợi và khi nào source of truth được chuyển hẳn sang Microsoft 365.

Nói đơn giản, coexistence làm thay đổi bớt nguy hiểm hơn nhưng troubleshoot có thể khó hơn. Nếu routing, identity và support rule không rõ, cả hai platform có thể đều “đang chạy” nhưng team lại không chắc behavior nào mới là đúng.

Những dependency nhỏ thường chỉ lộ ra khi platform bắt đầu chạy thật

Một SaaS migration nhìn trên sơ đồ thường xoay quanh identity, mailbox và data. Nhưng khi đi vào production, phạm vi thực tế rộng hơn. Scanner hoặc ứng dụng cũ có thể gửi mail theo cách tạo ra MIME không chuẩn; meeting room phải được recreate và kiểm thử booking; Outlook profile cần nhận đúng thay đổi sau cutover; endpoint security cũng phải được theo dõi vì workload của người dùng không giống nhau.

Những dependency này không nhất thiết làm migration thất bại, nhưng chúng quyết định trải nghiệm sau Go-live. Một mailbox đã migrate thành công vẫn chưa đủ nếu ứng dụng nghiệp vụ không gửi được mail, user gặp profile warning hoặc endpoint bị ảnh hưởng bởi policy mới.

Đó là lý do mình không nhìn project này chỉ như Gmail → Exchange Online hay Drive → OneDrive. Thay collaboration platform cũng kéo theo những integration và thói quen vận hành đang phụ thuộc platform cũ.

Shared Drive không nên được xem như một folder lớn

Một trong những phần mình thấy đáng chú ý là Shared Drive.

Google Shared Drive không tự nhiên tương đương với một destination duy nhất bên Microsoft. Inventory cần nhìn owner, dung lượng, permission và mục đích sử dụng trước khi quyết định destination.

Với dữ liệu team collaboration, SharePoint Site thường hợp lý; nhưng trong project vẫn có những trường hợp phù hợp hơn với OneDrive của owner hoặc một shared account theo mapping đã thống nhất. Vì vậy destination không nên được quyết định chỉ từ tên folder hay dung lượng.

Câu hỏi thực tế hơn là: Ai sở hữu dữ liệu? Ai cần quyền sau migration? Đây là personal storage hay team collaboration space? Permission hiện tại có còn phù hợp khi sang Microsoft 365 không?

Ở góc độ review phương án, đây là chỗ mình thấy copy file đầy đủ vẫn chưa đủ nếu ownership và permission sau đó không đúng.

Không phải mọi thứ của Google đều có một bản sao 1:1 bên Microsoft

Một phần rất thực tế của migration là chấp nhận platform differences. File và email nghiệp vụ thông thường có thể được bảo toàn ở mức đáp ứng vận hành, nhưng một số thành phần như Google-specific metadata/labels, shortcut, share link, permission phức tạp hoặc version history có thể cần hậu kiểm hoặc không giữ nguyên behavior.

Cũng có những workload không thuộc luồng migrate tự động 1:1, chẳng hạn Forms, Apps Script, custom workflow hoặc một số nội dung Google Sites. Nếu business còn nhu cầu, chúng phải được xem như một bài toán rebuild, export hoặc redesign riêng thay vì gắn nhãn chung là “migration failed”.

Việc phân loại trước dữ liệu nào bắt buộc phải giữ, limitation nào có thể chấp nhận và phần nào cần xử lý sau migration giúp cutover dựa trên risk thực tế hơn.

Cutover không phải là lúc mọi exception biến mất

Cutover chuyển Microsoft 365 thành nền tảng vận hành chính, nhưng sau đó vẫn còn các trường hợp cần hậu kiểm: permission, group, mailbox, Drive/Shared Drive, Outlook và endpoint chưa hoàn tất trạng thái mong muốn.

Hai mốc này không nhất thiết xảy ra cùng một thời điểm.

Cách nhìn này thực tế hơn việc ép migration phải “100% sạch” ngay tại phút cutover. Quan trọng là exception nào còn lại đã được biết, có owner và có cách xử lý.

30 ngày đối chiếu: để người dùng xác nhận dữ liệu bằng công việc thật

Vì số lượng người dùng trong đợt migration khá lớn, communication với business được chuẩn bị từ sớm. Trước Go-live, kế hoạch cutover, cách đăng nhập, cách sử dụng Microsoft 365 và kênh hỗ trợ được thông báo để người dùng biết thời điểm thay đổi.

Sau Go-live, người dùng chuyển sang Microsoft 365 làm nền tảng làm việc chính và được dành 30 ngày để tự kiểm tra, đối chiếu mail, calendar, file và quyền truy cập.

Nếu trong thời gian đó có người dùng báo thiếu file hoặc sai permission, team vẫn còn khả năng quay lại Google Workspace để truy vết theo tên file, đường dẫn, owner hoặc context mà người dùng cung cấp, rồi recovery/reconcile theo từng case cụ thể.

Sau cửa sổ đối chiếu, không ghi nhận trường hợp mất dữ liệu nghiêm trọng còn tồn đọng; những sai lệch phát sinh chủ yếu thuộc nhóm tìm kiếm, mapping lại quyền hoặc xử lý thủ công theo từng trường hợp.

Post-migration Reconciliation nên được tính từ đầu

Sau cutover, hệ thống Google vẫn được duy trì trong một khoảng thời gian để phục vụ đối chiếu và hỗ trợ truy hồi khi cần. Các trường hợp sai lệch được xử lý theo hướng kiểm tra tên file, đường dẫn, owner và permission rồi recovery/reconcile theo từng tình huống.

Với SaaS migration, không phải lúc nào “rollback toàn bộ” cũng là phương án thực tế. Nhiều khi điều cần hơn là vẫn truy hồi được source cũ đủ lâu để xử lý những case còn sót.

Migration không kết thúc khi dữ liệu copy xong. Nó gần kết thúc hơn khi team biết phần nào đã chuyển, phần nào còn exception và user đã làm việc ổn định trên platform mới.

Điều mình giữ lại từ project này

Nhìn từ vai trò Consultant, phần đáng nhớ nhất của project không phải một command hay một màn hình cấu hình cụ thể.

Mình nhớ cách team chia migration thành các bước nhỏ để kiểm tra dần: survey trước, identity trước data move, pilot trước rollout, coexistence trước cutover, batch thay cho big bang, communication trước Go-live và reconciliation sau đó.

Google Workspace và Microsoft 365 đều là những platform trưởng thành. Nhưng chuyển từ platform này sang platform kia vẫn làm thay đổi identity, permission, collaboration, endpoint behavior, application dependency và cách support người dùng — không chỉ email và file.

Công cụ giúp chuyển dữ liệu. Cách chuẩn bị và kiểm tra mới quyết định người dùng có làm việc bình thường sau khi chuyển hay không.