مهاجرت از Google Workspace به Microsoft 365 فقط انتقال فایل‌ها و ایمیل‌ها نیست، بلکه تغییر در نحوه کار سازمان است. در این فرایند Gmail به Outlook و Exchange Online، فایل‌های شخصی Google Drive به OneDrive و درایوهای مشترک به SharePoint یا Teams منتقل می‌شوند و حساب‌های کاربران نیز به Microsoft Entra ID تبدیل می‌شوند. برای جلوگیری از مشکل، باید ابتدا سیستم فعلی بررسی و حساب‌ها آماده شوند، سپس مهاجرت آزمایشی انجام شود و بعد از انتقال کامل، DNS و عملکرد سرویس‌ها بررسی و از کاربران پشتیبانی شود. هدف اصلی این است که پس از مهاجرت، کاربران بدون مشکل به ایمیل، فایل‌ها، تقویم‌ها و لینک‌های خود دسترسی داشته باشند.
چرا سازمان‌ها مهاجرت می‌کنند و چه زمانی نباید مهاجرت کرد؟
سازمان‌ها معمولاً به این دلیل از Google Workspace به Microsoft ۳۶۵ مهاجرت می‌کنند که Microsoft ۳۶۵ با زیرساخت فعلی آن‌ها هماهنگی بیشتری دارد. اگر سازمان از ابزارهایی مثل Windows، Office، Teams، SharePoint و Microsoft Entra ID استفاده کند، مدیریت کاربران، دستگاه‌ها، امنیت و همکاری بین کارکنان یکپارچه‌تر می‌شود. ادغام شرکت‌ها، افزایش امنیت، کاهش ابزارهای اضافی و نیاز به امکانات پیشرفته‌تر Office نیز از دلایل دیگر مهاجرت هستند.
چه زمانی نباید مهاجرت کرد؟
اگر سازمان با Google Workspace مشکلی ندارد، وابستگی زیادی به ابزارهای اختصاصی Google دارد و تجربه کافی با محصولات Microsoft ندارد، مهاجرت ممکن است سود زیادی نداشته باشد. همچنین نباید مهاجرت را فقط برای کاهش هزینه اشتراک انجام داد، چون هزینه‌های انتقال، آموزش، پشتیبانی، اجرای همزمان دو سیستم و رفع مشکلات نیز باید محاسبه شوند.
اگر وضعیت فعلی سیستم به‌طور کامل مشخص نیست، برنامه‌های مهم به Gmail یا Drive وابسته هستند، مالکیت حساب‌ها مشخص نیست یا مدیران ارشد از پروژه حمایت نمی‌کنند، بهتر است مهاجرت به تعویق بیفتد. وجود اطلاعات قانونی یا حساس، Shared Driveهای پیچیده و سیستم‌های حیاتی ایمیل نیز می‌تواند نیاز به مهاجرت مرحله‌ای یا اجرای همزمان دو سیستم داشته باشد. در بعضی شرایط حتی ممکن است بهترین تصمیم، فعلاً مهاجرت نکردن باشد.
نقشه سرویس‌های Google و مقصد آن‌ها در Microsoft ۳۶۵
در مهاجرت نباید سرویس‌های Google را صرفاً به‌صورت یک‌به‌یک با سرویس‌های Microsoft جایگزین کرد، چون ساختار و نحوه استفاده از آن‌ها متفاوت است. معمولاً Gmail به Exchange Online و Outlook، Google Calendar به Outlook Calendar، My Drive به OneDrive، Shared Drives به SharePoint یا Teams، فایل‌های Docs و Sheets و Slides به Word و Excel و PowerPoint و حساب‌ها و گروه‌ها به Microsoft Entra ID منتقل می‌شوند. تصمیم نهایی باید بر اساس مالکیت اطلاعات، سطح دسترسی و نحوه کار تیم‌ها گرفته شود.
مرحله اول: بررسی و ایجاد توجیه کسب‌وکار
در اولین مرحله باید اطلاعات کاملی از سیستم فعلی جمع‌آوری شود. این اطلاعات شامل کاربران، گروه‌ها، آدرس‌های ایمیل، حساب‌های غیرفعال، دسترسی‌های اشتراکی، اتاق‌های جلسه، قوانین ایمیل، دامنه‌ها، دستگاه‌های موبایل، برنامه‌های متصل به Google و نقش‌های مدیریتی است. درباره فایل‌ها نیز باید مالک، حجم، نوع فایل، اشتراک‌گذاری خارجی، فایل‌های بزرگ و فایل‌های بدون مالک مشخص شوند. الزامات Google Vault و نگهداری قانونی اطلاعات نیز باید بررسی شود.
جمع‌آوری اطلاعات (Discovery)
هدف این مرحله این است که سازمان دقیقاً بداند چه سیستم‌ها، حساب‌ها، فایل‌ها و سرویس‌هایی دارد و چه چیزهایی باید منتقل شوند. بدون شناخت کامل از وضعیت فعلی، احتمال بروز مشکل در زمان مهاجرت زیاد است.
شناسایی وابستگی‌ها
باید مشخص شود چه برنامه‌ها و تجهیزات به Google وابسته هستند؛ برای مثال چه سیستم‌هایی از Gmail برای ارسال ایمیل استفاده می‌کنند، چه دستگاه‌هایی به SMTP وابسته‌اند و چه فرایندهایی از Apps Script، Google Forms، Sheets یا لینک‌های ثابت Drive استفاده می‌کنند. همچنین باید مشخص شود کدام تیم‌ها با افراد خارج از سازمان فایل به اشتراک می‌گذارند.
برای ساده‌تر شدن ارزیابی می‌توان ریسک‌ها را به سه سطح تقسیم کرد: موارد عادی در سطح سبز، موارد دارای ریسک در سطح زرد و سیستم‌های حیاتی یا پشتیبانی‌نشده در سطح قرمز قرار می‌گیرند.
ایجاد توجیه کسب‌وکار (Business Case)
اطلاعات جمع‌آوری‌شده باید برای مشخص‌کردن دلیل و هدف مهاجرت استفاده شود؛ مثلاً یکپارچه‌سازی حساب‌ها، افزایش امنیت دستگاه‌ها، استفاده بهتر از برنامه‌های Microsoft یا کاهش ابزارهای همکاری اضافی. علاوه بر هزینه اشتراک‌ها، هزینه انتقال، آموزش، پشتیبانی، امنیت، ذخیره‌سازی و اجرای همزمان دو سیستم نیز باید در نظر گرفته شود.
تعیین مسئولیت‌ها و اهداف
برای بخش‌های مختلف مانند حساب‌های کاربران، ایمیل، فایل‌ها، امنیت، DNS، انطباق قانونی، برنامه‌ها و ارتباطات باید مسئول مشخص شود. همچنین از ابتدا باید معیارهای مشخصی تعیین شود که بر اساس آن‌ها تصمیم گرفته شود پروژه ادامه پیدا کند یا متوقف شود. این کار از تصمیم‌های عجولانه در مراحل پایانی پروژه جلوگیری می‌کند.
بازسازی مواردی که قابل انتقال نیستند
هر چیزی را که نمی‌توان به‌درستی منتقل کرد، از ابتدا ایجاد کنید؛ از جمله:
- صندوق‌های ایمیل اتاق جلسات و تجهیزات در Exchange
- سیاست‌های رزرو
- تقویم‌های مشترک
- ثبت افرادی که دسترسی نیابتی (Delegated Access) دارند
از کاربران بخواهید بعد از انتقال، جلسات تکرارشونده (Recurring Meetings) را بررسی کنند.
همچنین توجه کنید که برچسب‌های Gmail دقیقاً معادل پوشه‌ها یا دسته‌بندی‌های Outlook نیستند؛ یک ایمیل در Gmail می‌تواند چند Label داشته باشد. بنابراین نحوه نمایش این پیام‌ها را بررسی و تفاوت‌ها را برای کاربران توضیح دهید تا تصور نکنند اطلاعاتی گم شده است.
مانیتور و تأیید انتقال
در زمان مهاجرت Exchange، طبق روش فعلی Microsoft مراحل انتقال را پیگیری کنید و موارد زیر را بررسی کنید:
- تعداد آیتم‌های منتقل‌شده
- آیتم‌های ردشده یا Skip شده
- دلایل خطا
- زمان آخرین همگام‌سازی
اگر سیاست‌های Retention یا Archive مقصد باعث حذف/جابجایی اطلاعات می‌شوند، آن‌ها را موقتاً تنظیم یا غیرفعال کنید تا در مرحله بررسی، اطلاعات به اشتباه «مفقود» به نظر نرسند.
نکته مهم: بلافاصله بعد از نمایش پیام موفقیت در داشبورد، Gmail را پاک نکنید. اطلاعات منبع را تا پایان بررسی نهایی و مدت نگهداری توافق‌شده حفظ کنید.
مرحله ۵: انتقال Google Drive و Shared Drives
برنامه‌ریزی انتقال فایل‌ها
انتقال فایل فقط کپی کردن اطلاعات نیست؛ در واقع فرصتی برای سازمان‌دهی مجدد اطلاعات است.
معمولاً:
- فایل‌های شخصی کاری از My Drive → OneDrive منتقل می‌شوند.
- فایل‌های تیمی از Shared Drives → SharePoint Sites منتقل می‌شوند و معمولاً از طریق Teams در دسترس قرار می‌گیرند.
قبل از شروع، مشخص کنید:
- ساختار و محدوده سایت‌ها
- مالکین و اعضا
- قوانین اشتراک‌گذاری خارجی
- سطح حساسیت اطلاعات
- سیاست‌های نگهداری (Retention)
- استاندارد نام‌گذاری
اگر یک Shared Drive بیش‌ازحد بزرگ است یا اطلاعات چند واحد، سطح محرمانگی یا چرخه عمر متفاوت دارد، بهتر است آن را به چند مقصد جدا تقسیم کنید.
استفاده از Microsoft Migration Manager
ابزار Microsoft Migration Manager for Google Workspace روند مشخصی دارد:
- اتصال به Google Workspace
- اسکن و ارزیابی فایل‌ها
- افزودن منابع آماده به لیست مهاجرت
- بررسی مسیر مقصد
- تطبیق حساب‌های کاربران
- اجرای مهاجرت و نظارت بر آن
برای مهاجرت‌های پیچیده، کل این فرایند را اجرا کنید. حتی اگر برای کسب‌وکارهای کوچک ابزار ساده‌تری وجود داشته باشد، باز هم باید از قبل مشخص باشد که هر فایل و محتوا دقیقاً به کجا منتقل می‌شود.
اسکن و بررسی گزارش‌ها
ابتدا اسکن کنید و سپس گزارش‌ها را بررسی کنید. به‌خصوص دنبال این موارد باشید:
- فایل‌های پشتیبانی‌نشده
- فایل‌های محدودشده
- مسیرهای فایل بیش‌ازحد طولانی
- نام‌های نامعتبر
- مشکلات مالکیت
- حجم یا تعداد زیاد فایل‌ها که ممکن است زمان مهاجرت را افزایش دهد
همچنین Mapping مقصد را به‌صورت دستی بررسی کنید و صرفاً به تطبیق خودکار اعتماد نکنید. قبل از انتظار برای انتقال صحیح Permissionها و Metadata، کاربران و گروه‌ها را Mapping کنید.
در نهایت، یک مهاجرت آزمایشی (Pilot) با انواع مختلف محتوا انجام دهید، از جمله:
- فایل‌های Native Google
- پوشه‌های Share شده با افراد خارج از سازمان
- Permissionهای به‌ارث‌رسیده
- ساختارهای بزرگ و چندلایه پوشه‌ها
- فایل‌های متعلق به کارکنان سابق
درک تبدیل فایل‌ها
تبدیل فایل فقط جابه‌جایی محل فایل نیست؛ محتوای فایل نیز ممکن است تغییر کند.
طبق راهنمای Microsoft:
- Google Docs → DOCX
- Google Sheets → XLSX
- Google Slides → PPTX
- Google Drawings → PNG
- فایل‌های اصلی Google همچنان در Google باقی می‌مانند.
- Google Sites و Google Maps منتقل نمی‌شوند.
- Shortcuts منتقل نمی‌شوند.
- فایل‌های بدون سازمان‌دهی یا بدون مالک ممکن است اصلاً اسکن یا گزارش نشوند.
تبدیل ممکن است روی فرمول‌ها، Scriptها، Layout صفحات، Commentها، اشیای Embedded و Linkها اثر بگذارد. بنابراین باید مجموعه‌ای از فایل‌های پیچیده را آزمایشی تبدیل کرده و مالک واقعی فایل نتیجه را تأیید کند.
Permissionها نیز ممکن است دقیقاً منتقل نشوند؛ به‌خصوص برای کاربران داخلی، گروه‌ها، مهمان‌ها، لینک‌های Anonymous و دسترسی‌های سفارشی.
همچنین فهرستی از فایل‌هایی که نیاز به Export دستی، بازطراحی، آرشیو یا حذف دارند تهیه کنید.
نکته: Migration Manager فایل‌ها را کپی می‌کند و فایل‌های Google را حذف نمی‌کند؛ حذف فایل‌های مبدأ یک مرحله جداگانه و کنترل‌شده است.
Pilot، Cutover، DNS و Rollback
اجرای Pilot واقعی
Pilot نباید فقط با کاربران IT انجام شود. باید گروه‌های مختلف و کاربران چالش‌برانگیز را شامل شود:
- چند دپارتمان
- مدیران و دستیاران دارای Delegated Access
- کارکنان Remote و کاربران موبایل
- مالکان Shared Drive
- کاربران خارجی
- افرادی که اتاق رزرو می‌کنند
- حداقل یک کاربر با Mailbox بزرگ یا غیرمعمول
معیارهای موفقیت را از قبل تعیین کنید، مثلاً:
- ارسال و دریافت ایمیل درست کار کند.
- Login و MFA موفق باشد.
- Outlook، موبایل و Meetingها درست کار کنند.
- تبدیل فایل‌ها صحیح باشد.
- تعداد مشکلات قابل مدیریت باشد.
Pilot باید در شرایطی شبیه محیط واقعی اجرا شود. اگر مثلاً ۵٪ فایل‌ها نیاز به کار دستی دارند، این زمان را وارد برنامه کنید. ۹۵٪ انتقال موفق به‌تنهایی به معنی موفقیت Pilot نیست.
آماده‌سازی Cutover و DNS
قبل از انتقال نهایی:
- در صورت امکان TTL مربوط به DNS را از قبل کاهش دهید.
- مطمئن شوید به DNS Provider دسترسی دارید.
- تمام Recordهای فعلی را مستند کنید.
- مقادیر جدید Microsoft ۳۶۵ را آماده کنید.
- رکوردهای MX، Autodiscover، SPF، DKIM و DMARC را بررسی کنید.
- SPF باید فقط یک Record معتبر داشته باشد؛ ایجاد دو SPF TXT Record می‌تواند مشکل ایجاد کند.
- ارسال‌کنندگان ایمیل و Gatewayهای شخص ثالث را جداگانه تست کنید.
ترتیب اجرای Cutover
ترتیب پیشنهادی:
- تغییرات غیرضروری در حساب‌ها و ساختار را متوقف کنید.
- آخرین انتقال یا Delta Sync را انجام دهید.
- وضعیت Batchهای مهاجرت را بررسی کنید.
- رکوردهای مربوط به Mail Flow را تغییر دهید.
- ارسال و دریافت ایمیل را تست کنید.
- رکوردهای امنیتی Domain را فعال و بررسی کنید.
- کاربران را به‌صورت مرحله‌ای و Wave-based فعال کنید.
تغییر MX یک Service Transition واقعی است، نه صرفاً یک مرحله آماده‌سازی.
برنامه Rollback
قبل از Go-Live باید برنامه بازگشت مشخص باشد:
- چه کسی می‌تواند Migration را متوقف کند؟
- آخرین زمان امن برای تصمیم‌گیری چه زمانی است؟
- در صورت شکست، MX و Routing چگونه برگردانده می‌شوند؟
- ایمیل‌هایی که در Microsoft ۳۶۵ دریافت شده‌اند چه می‌شوند؟
- آیا کاربران می‌توانند همزمان در هر دو سیستم فایل‌ها را تغییر دهند؟
Rollback DNS فوری نیست، چون Cache وجود دارد. همچنین برگشت Mail Flow باعث Merge خودکار اطلاعات دو سیستم نمی‌شود.
در بسیاری از موارد، بهتر است Wave بعدی را متوقف و مشکل را رفع کنید تا اینکه کاربرانی را که با موفقیت منتقل شده‌اند به سیستم قبلی برگردانید.
Validation؛ تأیید نهایی
عبارت Completed در Migration Dashboard به معنی تأیید شدن مهاجرت توسط کسب‌وکار نیست.
باید موارد زیر بررسی شوند:
Identity
- Login
- MFA
- License
- Alias
- Group Owner
- وضعیت حساب‌های غیرفعال
- ایمیل ورودی، خروجی و داخلی
- Folder/Labelها
- Delegateها
- Aliasها
- Ruleها
- ایمیل‌های بزرگ و Exceptionها
Calendar
- جلسات تکرارشونده
- Time Zone
- Organizer
- اتاق‌ها
- Shared Calendar
- Mobile Sync
Files
- تعداد و حجم فایل‌ها با درنظرگرفتن تفاوت‌های Conversion
- Owner
- Permission
- External Access
- تأیید فایل‌های نمونه
Clients
عملکرد صحیح:
- Outlook
- Teams
- OneDrive
- Office Activation
روی Windows، macOS و موبایل.
Security
- Audit Log
- Conditional Access
- Sharing Controls
- Retention
- Emergency Access
Operations
فرایندهای مربوط به:
- استخدام کاربر جدید
- انتقال کاربر
- خروج کاربر
- Recovery
- Support
- Escalation
خطاهای رایج
مهم‌ترین مشکلات معمولاً قابل پیش‌بینی هستند:
- Accountهای بدون تطبیق → از بین رفتن Permission
- OneDrive یا Siteهای آماده‌نشده → عدم انتقال فایل
- Aliasهای قدیمی → Email Conflict
- منقضی شدن OAuth/API Permission
- فایل‌ها یا Pathهای پشتیبانی‌نشده
- Mapping اشتباه کاربران خارجی
- Retention Policyهایی که هنگام بررسی فایل‌ها را جابه‌جا می‌کنند
همچنین صرفاً تعداد فایل‌ها را مقایسه نکنید؛ چون Google-native files و Shortcutها باعث تفاوت طبیعی در تعداد می‌شوند.
هر اختلاف را در یکی از این چهار دسته قرار دهید:
Expected / Fixed / Accepted / Blocking
تمام Reportها، Errorها، Mappingها، DNS Recordها و تأییدیه‌ها را نگه دارید. کاربران پرریسک را جداگانه بررسی کنید، نه اینکه فقط میانگین کل کاربران را ببینید.
پس از پایان دوره Validation، دسترسی‌های موقت، Migration Appها، Service Accountها، Forwardingها و Routingهای قدیمی را حذف کنید.
آموزش کاربران و Change Management
کاربران لازم نیست تمام امکانات Microsoft 365 را یاد بگیرند؛ باید بدانند کار روزمره‌شان چه تغییری کرده است.
آموزش کوتاه و نقش‌محور برای این موارد ارائه کنید:
- Gmail Labels در برابر Outlook Folders/Categories
- OneDrive در برابر Google Drive
- Teams در برابر Chat
- SharePoint و مالکیت تیم
- ساخت Meeting
- رزرو اتاق
- فایل‌های Offline
- نحوه دریافت Support
روی تفاوت‌هایی تمرکز کنید که ممکن است باعث اشتباه شوند.
از کاربران Pilot به‌عنوان Champion استفاده کنید و در Waveهای اول ساعات مشخصی برای Help/Office Hours در نظر بگیرید.
اندازه‌گیری Adoption
بعد از مهاجرت موارد زیر را بررسی کنید:
- تعداد Loginها
- میزان استفاده فعال
- تعداد Ticketهای Support
- درخواست‌های حل‌نشده Sharing
- رشد Storage
- ادامه داشتن کار همزمان در Google
صرفاً به‌خاطر رسیدن به تاریخ Migration، Google Workspace را بازنشسته نکنید. ابتدا Validation، Retention، تأیید کسب‌وکار و الزامات قراردادی را تکمیل کنید.
یک مهاجرت موفق از Google Workspace فقط به این نیست که داده‌ها با چه سرعتی از Google خارج شوند. معیار اصلی این است که بعد از حذف سیستم قدیمی، کاربران بتوانند در Microsoft 365:
- به‌درستی با یکدیگر ارتباط برقرار کنند،
- اطلاعات موردنیازشان را پیدا کنند،
- سوابق و اطلاعات مهم را حفظ کنند،
- و با امنیت مناسب به کار خود ادامه دهند.
بیشتر مشکلاتی که می‌توان از آن‌ها جلوگیری کرد، با بررسی دقیق اولیه (Discovery) و تطبیق صحیح حساب‌های کاربری (Account Mapping) قابل پیشگیری هستند. مشکلات باقی‌مانده نیز معمولاً در آزمون Pilot مشخص می‌شوند؛ زمانی که هنوز فرصت کافی برای اصلاح آن‌ها وجود دارد.
از ابزارهای فعلی Microsoft متناسب با قابلیت‌های واقعی آن‌ها استفاده کنید و تمام محدودیت‌های شناخته‌شده را مستند کنید. صاحبان اطلاعات در کسب‌وکار باید تبدیل فایل‌ها و Permissionها را تأیید کنند.
با انتقال مرحله‌ای داده‌ها، تغییرات کنترل‌شده DNS، بررسی دقیق نتایج و آموزش هدفمند کاربران، مهاجرت می‌تواند قابل پیش‌بینی و مدیریت‌پذیر باشد.
این فرایند احتمالاً کاملاً بی‌نقص یا نامحسوس نخواهد بود، اما با برنامه‌ریزی صحیح می‌تواند روان و موفقیت‌آمیز انجام شود.
![چگونه مشکلات بهروزرسانی ویندوز ۱۱ نسخه ۲۵H۲ را برطرف کنیم؟ [راهکارهای ۱۰۰٪ مؤثر]](https://itresearches.ir/wp-content/uploads/2026/08/windows-11-25h2-spotted-150x150.webp)
