هر سازمانی که چند سال از شیرپوینتش می‌گذرد، دیر یا زود به این نقطه می‌رسد: نسخه فعلی کهنه شده، بسته‌های امنیتی دیگر نمی‌آیند، سرورها عمرشان را کرده‌اند و کسی در تیم به‌طور کامل نمی‌داند چه سفارشی‌سازی‌هایی سال‌ها پیش انجام شده است. در این لحظه، مدیران معمولاً یکی از دو واکنش را نشان می‌دهند: یا ارتقا را به تعویق می‌اندازند تا «بعداً» که بودجه بیشتر شد، یا با عجله شروع می‌کنند و در میانه راه با مشکلاتی روبه‌رو می‌شوند که انتظارش را نداشتند.
هیچ‌کدام از این دو، راه خوبی نیست. مهاجرت از یک نسخه مایکروسافت شیرپوینت به نسخه جدیدتر اگر خوب برنامه‌ریزی شود، یک پروژه قابل پیش‌بینی است، نه یک ماجراجویی. در این نوشته، نقشه راهی عملی ارائه می‌دهم که از ارزیابی وضع موجود شروع می‌شود و تا مراقبت‌های پس از مهاجرت ادامه می‌یابد.
چرا نمی‌شود صبر کرد؟
اولین پرسش منطقی این است: اگر سیستم کار می‌کند، چرا دست بزنیم؟ پاسخ در چرخه عمر نرم‌افزار است. هر نسخه از شیرپوینت دوره پشتیبانی مشخصی دارد و پس از پایان آن، مایکروسافت وصله امنیتی منتشر نمی‌کند. نسخه‌های ۲۰۱۶ و ۲۰۱۹ طبق اعلام مایکروسافت به پایان دوره پشتیبانی رسیده یا بسیار به آن نزدیک‌اند و مسیر رسمی ادامه راه، نسخه Subscription Edition است. پیش از تصمیم‌گیری، تاریخ‌های دقیق را از صفحه رسمی چرخه عمر محصولات مایکروسافت بررسی کنید.
ماندن روی نسخه بدون پشتیبانی، فقط یک ریسک نظری نیست. شیرپوینت معمولاً حاوی حساس‌ترین اسناد سازمان است و آسیب‌پذیری‌های کشف‌شده در آن، اغلب مدت کوتاهی پس از انتشار، هدف حمله قرار می‌گیرند. علاوه بر امنیت، سازگاری هم مطرح است: سیستم‌عامل‌ها و نسخه‌های SQL قدیمی‌تر هم رو به پایان عمرند و هر سال که می‌گذرد، یافتن سخت‌افزار و پشتیبانی برای آن‌ها دشوارتر می‌شود.
همچنین، ارتقای تدریجی همیشه ارزان‌تر از ارتقای اضطراری است. وقتی مجبور باشید در عرض چند هفته، زیر فشار یک حادثه امنیتی یا یک ممیزی، مهاجرت کنید، تصمیم‌هایتان بدتر و هزینه‌ها بالاتر خواهد بود.
گام اول: ممیزی بدون تعارف
قبل از هر چیز باید بدانید چه چیزی دارید. شاید بدیهی به نظر برسد، ولی بسیاری از سازمان‌ها این کار را درست انجام نمی‌دهند. فهرستی دقیق تهیه کنید از این موارد:
- تعداد وب‌اپلیکیشن‌ها، مجموعه‌سایت‌ها و حجم هر کدام.
- سایت‌هایی که طی دوازده ماه گذشته فعالیتی نداشته‌اند.
- راه‌حل‌های سفارشی: Farm Solution، وب‌پارت‌های اختصاصی، فرم‌های سفارشی و ماژول‌های جانبی.
- گردش‌کارها، به‌خصوص آن‌هایی که با ابزارها و فناوری‌های قدیمی ساخته شده‌اند.
- اتصال‌ها به سیستم‌های بیرونی مثل اتوماسیون اداری، سیستم مالی یا پایگاه‌های داده دیگر.
- نسخه سیستم‌عامل، SQL و تمامی وابستگی‌ها.
- تنظیمات احراز هویت، گواهی‌ها و آدرس‌های دسترسی.
در این مرحله، معمولاً کشف می‌کنید که بخش قابل توجهی از محتوا اصلاً استفاده نمی‌شود. من در یک پروژه دیدم که بیش از چهل درصد حجم دیتابیس‌ها مربوط به سایت‌هایی بود که سه سال دست‌نخورده مانده بودند. این یعنی فرصتی برای کوچک‌تر کردن پروژه، پیش از اینکه شروع شود. آرشیو کردن یا حذف محتوای مرده، مهاجرت را سریع‌تر و ارزان‌تر می‌کند.
گام دوم: انتخاب استراتژی
به‌طور کلی چند رویکرد برای مهاجرت وجود دارد و انتخاب بین آن‌ها به شرایط شما بستگی دارد. طبق مستندات مایکروسافت، مسیرهایی مثل ارتقای درجا (In-place) و روش انتقال دیتابیس (Database Attach) برای نسخه‌های مختلف پشتیبانی می‌شوند؛ اما اینکه کدام مسیر برای نسخه فعلی شما مجاز است، باید از مستندات رسمی بررسی شود و فرض نکنید که همه نسخه‌ها همه مسیرها را دارند.
در روش انتقال دیتابیس، فارم جدید را موازی با فارم قدیمی می‌سازید، دیتابیس‌های محتوا را به آن متصل می‌کنید و پس از آزمایش، کاربران را به فارم جدید هدایت می‌کنید. مزیت بزرگ این روش این است که فارم قدیمی دست‌نخورده می‌ماند و اگر مشکلی پیش آمد، راه برگشت دارید. هزینه‌اش این است که به سخت‌افزار یا منابع مجازی اضافه نیاز دارید و باید تنظیمات و سفارشی‌سازی‌ها را در فارم جدید بازسازی کنید.
ارتقای درجا، سخت‌افزار کمتری لازم دارد ولی ریسک بالاتری دارد، چون کار روی همان سیستم زنده انجام می‌شود. به‌ندرت این روش را برای فارم‌هایی توصیه می‌کنم که سفارشی‌سازی زیاد دارند یا زمان خرابی قابل تحمل ندارند. قاعده کلی من این است: هرجا تردید دارید، مسیری را انتخاب کنید که امکان بازگشت دارد.
گام سوم: محیط آزمایشی، بدون مصالحه
هیچ مهاجرتی نباید برای اولین بار روی سیستم زنده اجرا شود. یک محیط آزمایشی بسازید که تا حد ممکن مشابه محیط واقعی باشد؛ با نسخه مشابه، دیتابیس‌های کپی‌شده و همان سفارشی‌سازی‌ها. اول مهاجرت را روی آن اجرا کنید و زمان هر مرحله را ثبت کنید. این اعداد برای برنامه‌ریزی پنجره خرابی لازم‌اند. وقتی بدانید ارتقای دیتابیس‌های شما دقیقاً چهار ساعت و بیست دقیقه طول می‌کشد، می‌توانید به مدیران بگویید سیستم از جمعه شب تا شنبه صبح در دسترس نخواهد بود.
در محیط آزمایشی، فقط به فنی بودن نگاه نکنید. چند نفر از کاربران واقعی را دعوت کنید تا کارهای روزمره‌شان را انجام دهند. اگر فرم‌ها درست باز می‌شوند، جستجو کار می‌کند، دسترسی‌ها همان‌طور که بود حفظ شده‌اند و گردش‌کارها اجرا می‌شوند، می‌توانید با اطمینان بیشتری ادامه دهید. ایرادهایی که در این مرحله پیدا می‌شوند، یک‌دهم هزینه ایرادهای پس از راه‌اندازی را دارند.
مسئله فارسی‌سازی در مهاجرت
یکی از جاهایی که مهاجرت‌ها در سازمان‌های ایرانی سرد می‌شود، سفارشی‌سازی‌های فارسی است. اگر در فارم قدیمی از ماژول‌های تقویم شمسی، قالب‌های راست‌چین یا بسته‌های بومی‌سازی استفاده شده، باید مطمئن شوید که نسخه سازگار با ورژن جدید وجود دارد. این موضوع را از همان مرحله ممیزی بررسی کنید، نه آخرین هفته.
اگر هنوز برای نسخه جدید راه‌حلی ندارید، بررسی فارسی ساز شیرپوینت می‌تواند نشان بدهد چه گزینه‌های بومی‌سازی در دسترس است و آیا با مسیر ارتقای رسمی سازگارند. توصیه من این است که بومی‌سازی را جدا از هسته نگه دارید و در برنامه مهاجرت، آزمایش فارسی را یک مرحله مستقل قرار دهید: تاریخ شمسی در لیست‌ها، مرتب‌سازی حروف، جستجوی فارسی و نمایش درست فرم‌ها.
گام چهارم: ارتباط با کاربران
هیچ مهاجرتی فقط فنی نیست. کاربران باید بدانند چه زمانی قرار است سیستم در دسترس نباشد، چه چیزهایی تغییر می‌کند و در صورت مشکل با چه کسی تماس بگیرند. چند هفته پیش از موعد، اطلاع‌رسانی را شروع کنید. یک ایمیل کوتاه و روشن با تاریخ، ساعت و آنچه از کاربران انتظار می‌رود، بهتر از ده ایمیل طولانی است.
اگر ظاهر یا رفتار سیستم تغییر می‌کند، ولو جزئی، قبل از مهاجرت، تصاویر و راهنمای کوتاه آماده کنید. کاربری که صبح دوشنبه به سیستمی تازه وارد می‌شود و چیزی را پیدا نمی‌کند، به‌جای شکایت از «تغییر»، از «خراب شدن» حرف می‌زند، و این برداشت ذهنیِ بدی ایجاد می‌کند. چند نفر را به‌عنوان کاربران پیشرو معرفی کنید که در هر واحد به همکاران کمک کنند.
گام پنجم: اجرا، با فهرست بازبینی
در روز مهاجرت، مهم‌ترین ابزار شما یک فهرست بازبینی (Runbook) دقیق است. هر مرحله، مسئول آن، زمان تقریبی و معیار موفقیت باید مشخص باشد. پیش از شروع، از تمام دیتابیس‌ها و پیکربندی‌ها نسخه پشتیبان بگیرید و حتماً بازیابی‌پذیر بودن آن‌ها را تأیید کنید. فارم قدیمی را در حالت فقط‌خواندنی قرار دهید تا در حین انتقال، داده جدید نوشته نشود.
در طول اجرا، ارتباط تیم را باز نگه دارید. یک کانال گفتگو برای گزارش وضعیت لحظه‌ای کافی است. اگر پیش از موعد با مشکلی روبه‌رو شدید که در محیط آزمایشی ندیده بودید، تصمیم بگیرید: آیا قابل رفع در همین پنجره است یا باید بازگشت (Rollback) کنید؟ مشخص کنید از ابتدا چه معیاری باعث بازگشت می‌شود، تا در لحظه فشار، تصمیم احساسی نگیرید.
پس از اتمام، فهرست آزمون‌های پذیرش را اجرا کنید: ورود کاربران، باز شدن سایت‌های کلیدی، آپلود و دانلود سند، جستجو، گردش‌کارهای اصلی و گزارش‌ها. تا زمانی که این‌ها تأیید نشده، اعلام موفقیت نکنید.
پس از مهاجرت؛ هفته‌های حساس
بسیاری از تیم‌ها پس از روز مهاجرت نفس راحتی می‌کشند و پروژه را بسته اعلام می‌کنند. این اشتباه است. دو تا چهار هفته اول، بحرانی‌ترین دوره است. کاربران به‌تدریج مواردی را پیدا می‌کنند که در آزمون‌ها دیده نشده بود: یک دسترسی که جا مانده، لینکی که به آدرس قدیمی اشاره می‌کند، گزارشی که قالبش به‌هم ریخته است. باید پاسخ‌گویی سریع داشته باشید و فهرست مشکلات را ثبت و اولویت‌بندی کنید.
در همین دوره، پایش را تقویت کنید. زمان پاسخ‌گویی صفحات، مصرف حافظه و وضعیت جستجو را از نزدیک ببینید. ایندکس جستجو پس از مهاجرت معمولاً باید از نو ساخته شود و تا کامل شدن آن، نتایج جستجو ممکن است ناقص باشد؛ این را از قبل به کاربران بگویید. فارم قدیمی را بلافاصله حذف نکنید. چند هفته آن را در حالت خواندنی نگه دارید تا اگر سندی جا ماند یا نیاز به مقایسه شد، دسترسی داشته باشید.
چگونه بفهمیم مهاجرت موفق بوده است؟
موفقیت یعنی فقط بالا آمدن سرور نیست. پیش از شروع پروژه، معیارهایی تعریف کنید که بعد از اتمام بتوانید با آن‌ها بسنجید. برای مثال: درصد سایت‌های کلیدی که بدون مشکل کار می‌کنند، زمان میانگین بارگذاری صفحه اصلی، تعداد درخواست‌های پشتیبانی در دو هفته اول، رضایت کاربران پیشرو و تعداد دفعاتی که فارم باید به‌خاطر مشکل راه‌اندازی دوباره می‌شد.
همچنین جلسه‌ای پس از پروژه (Retrospective) برگزار کنید. چه چیزی خوب پیش رفت؟ چه چیزی غافلگیرمان کرد؟ اگر بار دیگر انجام می‌دادیم، چه تغییری ایجاد می‌کردیم؟ این درس‌ها را مستند کنید. دفعه بعد، شاید خود شما نباشید، ولی کسی که این مسئولیت را می‌گیرد، از این یادداشت‌ها سپاسگزار خواهد بود. اگر می‌خواهید تصویر بزرگ‌تری از مسیر محصول و گزینه‌های آن داشته باشید، سری به شیرپوینت و منابع مرتبط بزنید و با تیم خود درباره گام بعدی صحبت کنید.
چه زمانی به کمک بیرونی نیاز دارید؟
مهاجرت‌ها از آن دسته پروژه‌هایی هستند که در تیم‌های داخلی کم اتفاق می‌افتند. شاید فقط هر چند سال یک بار با آن روبه‌رو شوید و تجربه تیم برای هر بار تازه است. اینجاست که کمک گرفتن از متخصصانی که ده‌ها مهاجرت انجام داده‌اند، ارزش پیدا می‌کند. آن‌ها مشکلات رایج را می‌شناسند و می‌دانند چه چیزی را باید زودتر آزمایش کرد.
اگر مایلید ببینید یک مجموعه حرفه‌ای در حوزه خدمات شیرپوینت چه مواردی را برای مهاجرت پوشش می‌دهد، مرور آن به شما ایده می‌دهد که در مذاکره چه چیزی را بخواهید. به همین ترتیب، پس از اتمام پروژه، تداوم رابطه با تیم پشتیبانی شیرپوینت باعث می‌شود پس از مهاجرت، مشکلات کوچک پیش از بزرگ شدن حل شوند. نکته مهم این است که پشتیبانی پس از مهاجرت را از ابتدا در قرارداد بیاورید، نه وقتی مشکل پیش آمده.
در پایان، از شریک بالقوه بپرسید که تجربه ارتقا در محیط‌های فارسی را دارد یا نه، چه راهبردی برای بازگشت در نظر می‌گیرد و کدام بخش‌های کار را به عهده تیم شما می‌گذارد. پاسخ‌های مبهم، علامت خوبی نیستند.
خطاهایی که گران تمام می‌شوند
از تجربه چند مهاجرت، چند الگوی تکراری را جمع‌بندی کرده‌ام. اول، شروع بدون ممیزی. بدون دانستن اینکه چه دارید، نمی‌توانید زمان و هزینه را برآورد کنید. دوم، حذف محیط آزمایشی به دلیل کمبود وقت. این صرفه‌جویی تقریباً همیشه گران تمام می‌شود. سوم، نادیده گرفتن سفارشی‌سازی‌های قدیمی. چیزی که ده سال پیش نوشته شده و هیچ‌کس مستندش نکرده، معمولاً بعد از مهاجرت از کار می‌افتد.
چهارم، برنامه‌ریزی بدون حاشیه ایمنی. اگر آزمایش‌ها چهار ساعت طول کشیده، پنجره پنج‌ساعته در نظر نگیرید؛ هشت ساعت بگیرید. پنجم، اطلاع‌رسانی دیرهنگام به کاربران. ششم و شاید مهم‌تر از همه، اعلام موفقیت زودهنگام. مهاجرت وقتی تمام می‌شود که کاربران بتوانند دقیقاً همان کارهای قبل را بدون مانع انجام دهند، نه وقتی که سرور بالا آمده است.
جمع‌بندی
مهاجرت شیرپوینت، پروژه‌ای ترسناک نیست اگر آن را به گام‌های کوچک و قابل کنترل بشکنید. با ممیزی صادقانه شروع کنید، راهبردی با امکان بازگشت انتخاب کنید، در محیط آزمایشی تمرین کنید، با کاربران شفاف ارتباط برقرار کنید و پس از اجرا حداقل چند هفته مراقب بمانید.
و مهم‌تر از همه، مهاجرت را فرصتی برای مرتب کردن خانه ببینید، نه صرفاً یک هزینه اجباری. سازمان‌هایی که از این فرصت درست استفاده کردند، با سیستمی سبک‌تر، تمیزتر و قابل اعتمادتر بیرون آمدند؛ و همان‌ها هستند که سال‌های بعد، وقتی نسخه بعدی از راه می‌رسد، با آرامش از آن عبور می‌کنند.
بدون دیدگاه