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

Từ Identity, Pilot và Coexistence đến Cutover và Post-migration Reconciliation — một góc nhìn Consultant về Enterprise SaaS Migration.

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 vào toàn bộ project, mình thấy 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.

Định danh người dùng có khớp không? Quyền truy cập có đi theo dữ liệu không? Trong thời gian pilot, mail flow giữa hai nền tảng sẽ vận hành thế nào? Một Shared Drive nên trở thành SharePoint Site, OneDrive của owner hay một mô hình khác? Và sau cutover, điều gì được xem là migration hoàn tất?

Đ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, sử dụng Password Hash Sync để hình thành một identity path thống nhất hơn giữa môi trường nội bộ và cloud.

Điều này làm cho migration không còn chỉ là bài toán “copy dữ liệu từ A sang B”. Trước khi dữ liệu đi, 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 như exception thay vì xử lý ngẫu hứng trong maintenance window.

Migration tốt thường bắt đầu bằng Survey và Identity Normalization

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.

Điều đáng giá ở sequence này không nằm ở việc có nhiều stage, mà ở chỗ mỗi stage tạo ra evidence cho stage tiếp theo. Survey giúp lộ dependency; identity normalization giảm lỗi mapping; pilot kiểm chứng những giả định ban đầu; coexistence giúp giới hạn blast radius; batch migration làm thay đổi dễ kiểm soát hơn; còn reconciliation tạo một safety net sau Go-live.

Pilot vì vậy không phải một bản demo nhỏ cho đẹp. Nó là nơi để tìm ra những giả định sai trước khi chúng trở thành lỗi 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ù.

Điều đáng chú ý là 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 mình rút ra là: migration tool có thể thực thi mapping rất tốt, nhưng những exception chỉ xuất hiện khi dữ liệu, permission và user behavior thật bắt đầu đi qua platform mới.

Google Workspace và Microsoft 365 có cách tổ chức dữ liệu, quyền và application behavior khác nhau. Vì vậy mục tiêu thực tế không nên là ép hai hệ sinh thái trở thành bản sao tuyệt đối của nhau, mà là xác định phần nào cần bảo toàn, phần nào cần mapping lại và phần nào phải chấp nhận remediation sau migration.

Coexistence giúp giảm rủi ro, nhưng làm dependency phức tạp hơn

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.

Đây là một pattern mình thấy xuất hiện ở nhiều migration: coexistence giảm blast radius của thay đổi, nhưng tăng số trạng thái mà hệ thống có thể tồn tại. 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ó xác định 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.

Đó cũng là lý do mình không nhìn project này như một bài toán Gmail → Exchange Online hay Drive → OneDrive. Thay platform collaboration đồng nghĩa thay đổi cả những integration và behavior đang dựa vào platform cũ.

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

Một trong những phần thú vị nhất của migration data 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 thực tế phải nhìn đồng thời 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 là một destination tự nhiên; 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 quan trọng 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 hợp lý khi chuyển sang mô hình Microsoft 365 không?

Ở góc độ Consultant, mình thấy đây là nơi architecture và governance gặp nhau. File có thể được copy đầy đủ nhưng migration vẫn chưa tốt nếu ownership, permission hoặc collaboration model sau đó không phù hợp.

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 business-critical data, acceptable platform limitation và post-migration remediation giúp cutover decision dựa trên risk thực tế thay vì kỳ vọng rằng hai ecosystem phải giống nhau tuyệt đối.

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 project không vì thế mà trở thành một hệ thống “không còn issue”. Sau chuyển đổi 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.

Mình thấy cách nhìn này thực tế hơn rất nhiều so với việc ép migration phải đạt “100% hoàn hảo” ngay tại phút cutover. Quan trọng là các exception đã được biết, phân loại và có owner xử lý; không phải dashboard phải sạch tuyệt đối mới được xem là thành công.

30 ngày đối chiếu: để người dùng có thời gian xác nhận dữ liệu thật sự của mình

Vì số lượng người dùng trong đợt migration khá lớn, phầ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 chính xác thời điểm thay đổi sẽ xảy ra.

Sau khi 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. Đây không phải một khoảng chờ thụ động; nó là một reconciliation window được chủ động thiết kế vào project.

Nếu trong 30 ngày đó 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ể.

Kết quả của giai đoạn này cũng quan trọng như bản thân cutover: 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 là một phần của thiết kế

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.

Điều này làm mình liên tưởng đến rollback trong infrastructure migration. Với SaaS migration, không phải lúc nào “rollback toàn bộ” cũng là phương án phù hợp. Thay vào đó, khả năng truy hồi source cũ trong một khoảng thời gian có kiểm soát chính là một safety net rất quan trọng.

Migration không kết thúc khi dữ liệu đã copy xong. Nó kết thúc khi tổ chức biết dữ liệu nào đã chuyển, dữ liệu nào cần đối chiếu, ai sở hữu exception và người dùng có thể 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 là một command hay một màn hình cấu hình cụ thể.

Đó là cách một migration lớn được chia thành những decision nhỏ có thể kiểm chứng: survey trước khi thiết kế, identity trước khi data move, pilot trước rollout, coexistence trước cutover, batch thay cho big bang, communication trước Go-live và reconciliation thay cho giả định rằng mọi thứ sẽ tự khớp sau khi copy.

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

Migration tool giúp chuyển dữ liệu. Migration design mới quyết định tổ chức có tiếp tục làm việc bình thường sau khi dữ liệu đã chuyển hay không.