تاریخ پایان پشتیبانی SQL Server 2016 اکنون آن‌قدر نزدیک شده که نیاز به برنامه‌ریزی عملی دارد. مایکروسافت، SQL Server 2016 را به‌عنوان یک محصول با چرخه عمر ثابت معرفی کرده است؛ پشتیبانی اصلی آن در ۱۳ ژوئیه ۲۰۲۱ پایان یافته و پشتیبانی تمدیدشده آن نیز در ۱۴ ژوئیه ۲۰۲۶ به پایان می‌رسد. برای بسیاری از سازمان‌های بریتانیا و اتحادیه اروپا، این مهلت فقط به یک موتور پایگاه‌داده مربوط نمی‌شود، بلکه موضوعاتی مانند بیمه سایبری، آمادگی برای ممیزی، ریسک GDPR، دسترس‌پذیری برنامه‌ها، قراردادهای تأمین‌کنندگان، بازیابی بحران و بودجه‌های آینده IT را نیز تحت تأثیر قرار می‌دهد.

SQL Server 2016 سال‌ها به‌عنوان یک پلتفرم قابل‌اعتماد برای سیستم‌های مالی، پایگاه‌داده‌های ERP، گزارش‌گیری، فروشگاه‌های آنلاین، نرم‌افزارهای تولیدی و ابزارهای سازمانی استفاده شده است. همین ماندگاری دلیل اهمیت این مهلت است. پایگاه‌داده‌هایی که سال‌ها بدون مشکل کار کرده‌اند، معمولاً عمیقاً به فرایندهای کسب‌وکار وابسته‌اند. اگر برنامه‌ریزی تا ماه‌های پایانی به تعویق بیفتد، ممکن است زمان کافی برای بررسی وابستگی‌ها، تست سازگاری برنامه‌ها، برنامه‌ریزی لایسنس‌ها و انجام یک مهاجرت امن وجود نداشته باشد.

این راهنما توضیح می‌دهد که پایان پشتیبانی تمدیدشده چه معنایی دارد، ریسک پایان عمر SQL Server 2016 چگونه باید درک شود، SQL Server 2016 ESU چه مشکلاتی را حل می‌کند و چه محدودیت‌هایی دارد، و چه زمانی ارتقا از SQL Server 2016 به 2022 منطقی است.

در ۱۴ ژوئیه ۲۰۲۶ دقیقاً چه اتفاقی می‌افتد؟

طبق صفحه چرخه عمر مایکروسافت برای SQL Server 2016، پشتیبانی تمدیدشده این محصول در ۱۴ ژوئیه ۲۰۲۶ پایان می‌یابد. مدل چرخه عمر مایکروسافت معمولاً برای نسخه‌های SQL Server حداقل ۱۰ سال پشتیبانی ارائه می‌دهد: پنج سال پشتیبانی اصلی و سپس پنج سال پشتیبانی تمدیدشده. پشتیبانی اصلی شامل به‌روزرسانی‌های عملکرد، مقیاس‌پذیری و امنیت است، در حالی که پشتیبانی تمدیدشده بیشتر بر به‌روزرسانی‌های امنیتی تمرکز دارد.

وقتی پشتیبانی تمدیدشده SQL Server 2016 به پایان برسد، کانال‌های استاندارد پشتیبانی و به‌روزرسانی‌های امنیتی عادی دیگر مانند قبل ادامه نخواهند داشت. پایگاه‌داده ممکن است همچنان کار کند، اما استفاده از آن برای بارهای کاری حساس به‌عنوان یک پلتفرم عملیاتی، به‌مرور سخت‌تر توجیه می‌شود. این تفاوت مهم است: پایان پشتیبانی به معنی خاموش شدن نرم‌افزار نیست، بلکه یعنی سطح ریسک تغییر می‌کند.

کسب‌وکارهایی که با داده‌های مشتریان، اطلاعات کارکنان، سیستم‌های پرداخت یا بارهای کاری حیاتی سروکار دارند، باید این تاریخ را به‌عنوان یک مهلت مدیریتی در نظر بگیرند. اگر پس از پایان پشتیبانی یک آسیب‌پذیری جدی کشف شود و شما برنامه مهاجرت یا قرارداد مناسب Extended Security Updates نداشته باشید، گزینه‌های محدودی خواهید داشت. در محیط‌های قانون‌گذاری‌شده یا مبتنی بر قرارداد، این موضوع می‌تواند حتی از خود ارتقای فنی نیز فشار بیشتری ایجاد کند.

تفاوت پایان عمر و پایان پشتیبانی SQL Server 2016

عبارت «پایان عمر SQL Server 2016» معمولاً به‌صورت غیررسمی برای اشاره به پایان دوره پشتیبانی عادی مایکروسافت استفاده می‌شود. از نظر فنی، مایکروسافت در مستندات خود بیشتر از اصطلاح «پایان پشتیبانی» استفاده می‌کند. اما در برنامه‌ریزی روزمره IT، هر دو اصطلاح معمولاً به یک سؤال مشترک اشاره دارند: آیا می‌توان پس از ژوئیه ۲۰۲۶ همچنان با مسئولیت‌پذیری این پلتفرم را در محیط عملیاتی نگه داشت؟

پاسخ به این موضوع به نوع بار کاری، میزان در معرض بودن سیستم، حساسیت داده‌ها و کنترل‌های امنیتی جایگزین بستگی دارد. یک سرور آرشیوی آفلاین که فقط گاهی برای استفاده داخلی به کار می‌رود، با یک پایگاه‌داده متصل به اینترنت که اطلاعات شخصی را ذخیره می‌کند متفاوت است. همچنین یک پایگاه‌داده ERP با سفارشی‌سازی سنگین که به‌سرعت قابل ارتقا نیست، شرایط متفاوتی دارد. نکته مهم این است که تاریخ پایان پشتیبانی باید باعث بررسی موجودی سیستم‌ها و ارزیابی ریسک شود، نه ایجاد وحشت در آخرین لحظه.

برای سازمان‌های بریتانیا و اتحادیه اروپا، ریسک فقط فنی نیست. طبق GDPR و قوانین محلی حفاظت از داده، سازمان‌ها موظف‌اند اقدامات فنی و مدیریتی مناسبی برای محافظت از داده‌های شخصی انجام دهند. استفاده از زیرساخت بدون پشتیبانی لزوماً به معنی عدم انطباق با قوانین نیست، اما اگر یک حادثه امنیتی قابل پیشگیری رخ دهد، دفاع از این تصمیم دشوار خواهد بود. شرکت‌های بیمه، حسابرسان و مشتریان سازمانی نیز ممکن است بپرسند آیا پلتفرم‌های اصلی هنوز توسط فروشنده پشتیبانی می‌شوند یا نه.

چرا این مهلت برای کسب‌وکارهای بریتانیا و اتحادیه اروپا اهمیت دارد؟

بسیاری از شرکت‌های بریتانیا و اتحادیه اروپا زیرساخت‌های IT پایدار و محافظه‌کارانه‌ای را بر پایه فناوری‌های قدیمی مایکروسافت ساخته‌اند. این موضوع قابل درک است، چون مهاجرت پایگاه‌داده می‌تواند بر عملکرد برنامه‌ها، یکپارچه‌سازی‌ها، گزارش‌گیری، فرایندهای بکاپ و گردش کار کاربران تأثیر بگذارد. اما هرچه یک پلتفرم به پایان پشتیبانی نزدیک‌تر شود، به تعویق انداختن تصمیم‌گیری می‌تواند پرهزینه‌تر شود.

پنج ریسک رایج تجاری در این زمینه وجود دارد:

اول، ریسک امنیتی افزایش می‌یابد. پس از پایان پشتیبانی تمدیدشده، اصلاحات امنیتی منظم دیگر از طریق کانال عادی ارائه نمی‌شوند و مهاجمان معمولاً به سراغ پلتفرم‌های قدیمی می‌روند، چون می‌دانند بسیاری از سازمان‌ها کند عمل می‌کنند.

دوم، ارائه شواهد انطباق سخت‌تر می‌شود. اگر سازمان شما باید به مشتریان، نهادهای نظارتی، حسابرسان یا بیمه‌گران ثابت کند که استانداردهای امنیتی را رعایت می‌کند، استفاده از زیرساخت پایگاه‌داده بدون پشتیبانی می‌تواند به یک نقطه ضعف تبدیل شود.

سوم، زنجیره پشتیبانی فروشندگان ممکن است قطع شود. شرکت‌های تولیدکننده نرم‌افزار ممکن است دیگر محصولات خود را برای SQL Server 2016 تأیید نکنند، حتی اگر سیستم داخلی شما ظاهراً همچنان کار کند. این موضوع می‌تواند بر تیکت‌های پشتیبانی، ارتقاها و مسئولیت‌های قراردادی اثر بگذارد.

چهارم، هزینه جذب نیرو و مهارت افزایش پیدا می‌کند. مدیران پایگاه‌داده باتجربه هنوز می‌توانند با نسخه‌های قدیمی SQL Server کار کنند، اما بسیاری از تیم‌ها ترجیح می‌دهند روی پلتفرم‌های جدید، اتوماسیون و ابزارهای متصل به فضای ابری تمرکز کنند.

پنجم، مهاجرت عجولانه خطرناک است. ارتقای پایگاه‌داده زمانی امن‌تر است که زمان کافی برای شناسایی وابستگی‌ها، تست بازیابی، بررسی سازگاری، سنجش عملکرد، تست پذیرش کاربران و برنامه‌ریزی بازگشت وجود داشته باشد.

جدول فشرده برنامه‌ریزی فنی

چگونه برای مهاجرت امن SQL Server 2016 برنامه‌ریزی کنیم

یک مهاجرت موفق با شناسایی کامل سیستم‌ها شروع می‌شود. تمام Instanceهای SQL Server 2016 را فهرست کنید و مشخص کنید کدام پایگاه‌داده‌ها برای کسب‌وکار حیاتی هستند. مالک سیستم، برنامه‌ها، یکپارچه‌سازی‌ها، Jobهای نگهداری، Linked Serverها، SQL Agent Jobها، سرویس‌های گزارش‌گیری، زمان‌بندی بکاپ و هشدارهای مانیتورینگ را ثبت کنید. بسیاری از سازمان‌ها تازه در این مرحله متوجه می‌شوند که چه تعداد سرویس به پایگاه‌داده‌ای وابسته‌اند که تصور می‌کردند «هیچ‌کس از آن استفاده نمی‌کند».

سپس بارهای کاری را دسته‌بندی کنید. برخی باید سریع به SQL Server 2022 منتقل شوند، برخی نیاز به همکاری فروشنده نرم‌افزار دارند، بعضی قابل حذف هستند و برخی ممکن است موقتاً به ESU نیاز داشته باشند. این دسته‌بندی از ایجاد یک پروژه سنگین و پیچیده جلوگیری می‌کند و دید بهتری از هزینه‌های لایسنس و خدمات به تیم مالی می‌دهد.

ارزیابی فنی باید شامل Data Migration Assistant مایکروسافت یا ابزارهای مشابه، بررسی عملکرد Queryها، ارزیابی ذخیره‌سازی و I/O، تأیید بکاپ و بررسی امنیت باشد. اگر نرم‌افزار توسط شرکت دیگری ارائه شده، تأییدیه رسمی نسخه‌های پشتیبانی‌شده SQL Server را دریافت کنید و به راهنماهای قدیمی نصب اکتفا نکنید.

تست‌ها باید عملی باشند، نه صرفاً تئوری. یک نسخه از پایگاه‌داده عملیاتی را در محیط جدید Restore کنید، گردش کار برنامه‌ها را اجرا کنید، گزارش‌ها و Jobهای زمان‌بندی‌شده را بررسی کنید و عملکرد را مقایسه کنید. سناریوهای مهم مانند بستن حساب مالی، به‌روزرسانی موجودی، پردازش سفارش یا حقوق و دستمزد را نیز در تست‌ها لحاظ کنید. صرفاً Attach شدن موفق پایگاه‌داده کافی نیست.

در نهایت، برای Cutover برنامه‌ریزی کنید. مشخص کنید آیا به ارتقای درجا (In-Place Upgrade)، مهاجرت Side-by-Side، بکاپ و Restore، Log Shipping، Replication، Availability Group یا مهاجرت توسط فروشنده نیاز دارید. مسیر بازگشت (Rollback)، زمان Downtime و زمان‌بندی اجرای تغییرات را مستند کنید. در صنایعی مانند خرده‌فروشی، تولید، سلامت، لجستیک و خدمات حرفه‌ای، انتخاب زمان مناسب مهاجرت می‌تواند به‌اندازه روش فنی آن مهم باشد.

ملاحظات لایسنس هنگام مهاجرت از SQL Server 2016

موضوع لایسنس باید از همان ابتدا بررسی شود، چون بر بودجه، معماری و فرایند خرید تأثیر می‌گذارد. لایسنس SQL Server بسته به ادیشن، تعداد Coreها، مدل مجازی‌سازی و استفاده از Client Access License (CAL) متفاوت است. محیطی که در سال ۲۰۱۶ به‌درستی لایسنس شده بود، ممکن است امروز دیگر بهترین یا به‌صرفه‌ترین مدل نباشد.

برای سازمان‌های کوچک و متوسط، SQL Server Standard همچنان گزینه‌ای مناسب برای سیستم‌های دپارتمانی، ERP، نرم‌افزارهای سازمانی و گزارش‌گیری است. اما محیط‌های بزرگ یا دارای دسترس‌پذیری بالا ممکن است به ادیشن‌های دیگر نیاز داشته باشند. مجازی‌سازی نیز می‌تواند محاسبات لایسنس را تغییر دهد، مخصوصاً زمانی که پایگاه‌داده‌ها روی هاست‌ها یا کلاسترهای اشتراکی اجرا می‌شوند.

اگر هنوز لازم است هم‌زمان با برنامه‌ریزی مهاجرت، محیط فعلی را حفظ کنید، امکان استفاده از لایسنس‌های SQL Server 2016 Standard نیز وجود دارد. اما برای برنامه‌ریزی بلندمدت، معمولاً استفاده از نسخه‌های پشتیبانی‌شده مانند SQL Server 2022 منطقی‌تر از ادامه وابستگی به نسخه‌های قدیمی است.

چه زمانی استفاده از SQL Server 2016 ESU منطقی است؟

ESU زمانی منطقی است که سازمان برنامه مهاجرت مشخصی داشته باشد اما به زمان بیشتری نیاز پیدا کند. برای مثال، ممکن است فروشنده نرم‌افزار پشتیبانی از SQL Server 2022 را فقط در نسخه آینده برنامه خود ارائه دهد، یا شرکت بخواهد مهاجرت پایگاه‌داده را بعد از ارتقای ERP انجام دهد. در سازمان‌های دولتی یا قانون‌گذاری‌شده نیز فرایندهای خرید ممکن است جایگزینی فوری را غیرواقع‌بینانه کند.

در این شرایط، ESU باید به‌عنوان یک استثنای کنترل‌شده مدیریت شود. باید مالک پروژه، تاریخ پایان، بودجه، برنامه مهاجرت و مستند پذیرش ریسک مشخص باشد. سؤال اصلی نباید این باشد که «آیا می‌توانیم یک سال دیگر بخریم؟» بلکه باید این باشد که «در این یک سال دقیقاً چه چیزی را کامل خواهیم کرد؟». بدون این نظم، ESU فقط باعث عقب افتادن تصمیم‌ها تا مهلت بعدی می‌شود.

اشتباهات رایجی که باید از آن‌ها اجتناب کرد

اولین اشتباه این است که تصور شود پایگاه‌داده ایزوله است. بسیاری از SQL Serverها به ابزارهای گزارش‌گیری، اتصال‌های قدیمی ODBC، فایل‌های Excel، Middlewareها، خروجی‌های زمان‌بندی‌شده و سرویس‌های شخص ثالث متصل هستند. بنابراین فرایند شناسایی باید فراتر از خود سرور پایگاه‌داده باشد.

دومین اشتباه، موکول کردن موضوع لایسنس به پایان پروژه است. اگر خرید لایسنس بعد از مرحله تست شروع شود، ممکن است زمان‌بندی پروژه به تأخیر بیفتد. باید از ابتدا مشخص شود که به Standard یا Enterprise، مدل Server + CAL یا Core Licensing و چه نوع حقوق مجازی‌سازی نیاز دارید.

سومین اشتباه، فرض کردن تضمین عملکرد است. نسخه‌های جدید SQL Server پیشرفت‌های زیادی دارند، اما همچنان باید Query Planها، Compatibility Level و رفتار برنامه‌ها تست شوند. قبل از مهاجرت، عملکرد بارهای کاری مهم را اندازه‌گیری کنید تا بتوانید نتایج را به‌صورت واقعی مقایسه کنید.

چهارمین اشتباه، نادیده گرفتن مستندسازی است. پشتیبانی آینده به مستندات دقیق از نام Instanceها، مالک پایگاه‌داده‌ها، Jobهای نگهداری، محل بکاپ‌ها، Service Accountها و Connection Stringها وابسته است. پروژه مهاجرت فرصت خوبی برای ایجاد مستنداتی است که شاید سال‌ها وجود نداشته‌اند.

زمان‌بندی پیشنهادی تا ژوئیه ۲۰۲۶

اگر هنوز شروع نکرده‌اید، بهترین زمان همین حالاست. یک برنامه عملی برای بسیاری از سازمان‌ها می‌تواند به این شکل باشد:

مرحله اول: شناسایی و تعیین مالکیت
تمام Instanceهای SQL Server 2016 را شناسایی کنید، برنامه‌ها را مستند کنید و برای هر سیستم مالک مشخص تعیین کنید. مشخص کنید کدام پایگاه‌داده‌ها حیاتی، کم‌ریسک یا قابل حذف هستند.

مرحله دوم: انتخاب مقصد
تصمیم بگیرید هر بار کاری به SQL Server 2022، Azure، پلتفرم پشتیبانی‌شده دیگر، ESU یا بازنشستگی منتقل شود. همچنین پشتیبانی فروشنده نرم‌افزار و نیازهای لایسنس را بررسی کنید.

مرحله سوم: تست و رفع مشکلات
محیط مقصد را آماده کنید، پایگاه‌داده‌ها را Restore کنید، تست‌های سازگاری را انجام دهید، فرایندهای کسب‌وکار را بررسی کنید و مشکلات برنامه‌ها را رفع کنید. پیش از راه‌اندازی نهایی، تنظیمات امنیت و بکاپ را نیز بررسی کنید.

مرحله چهارم: مهاجرت نهایی و بستن پروژه
بارهای کاری عملیاتی را منتقل کنید، نتایج را تأیید کنید، عملکرد را مانیتور کنید، در صورت نیاز Instanceهای قدیمی را از مدار خارج کنید و اطلاعات دارایی‌ها را به‌روزرسانی کنید.

در محیط‌های پیچیده ممکن است این مراحل هم‌پوشانی داشته باشند، اما نباید حذف شوند. بزرگ‌ترین خطر این نیست که SQL Server 2016 در ۱۴ ژوئیه ۲۰۲۶ ناگهان از کار بیفتد؛ خطر اصلی این است که یک سیستم حیاتی بدون پشتیبانی باقی بماند، چون زمان کافی برای جایگزینی صحیح آن وجود نداشته است.

توصیه نهایی

پایان پشتیبانی SQL Server 2016 باید به‌عنوان یک نقطه مهم در برنامه‌ریزی امنیت و تداوم کسب‌وکار در نظر گرفته شود. اگر پایگاه‌داده از عملیات فعال، داده‌های مشتریان یا فرایندهای قانون‌گذاری‌شده پشتیبانی می‌کند، بهتر است هرچه زودتر فرایند شناسایی و انتخاب مسیر آینده را آغاز کنید.

برای بسیاری از کسب‌وکارهای بریتانیا و اتحادیه اروپا، منطقی‌ترین راهکار بلندمدت ارتقا از SQL Server 2016 به 2022 است و ESU فقط باید در مواردی استفاده شود که نیاز کوتاه‌مدت آن مستند شده باشد.

برنامه‌ریزی زودهنگام، تست دقیق و جلوگیری از تبدیل یک تاریخ قابل‌پیش‌بینی به پروژه‌ای اضطراری، مهم‌ترین عامل موفقیت در این مهاجرت خواهد بود.