مهاجرت مرحله‌ای نرم‌افزار زمانی انتخاب مناسبی است که بتوان مسئولیت سامانه قدیم و جدید را به‌روشنی جدا کرد و هزینه دوره هم‌زیستی آن‌ها را پذیرفت. مهاجرت یک‌باره زمانی قابل دفاع است که محدوده انتقال مشخص، توقف عملیات قابل برنامه‌ریزی و بازگشت به وضعیت قبلی واقعاً تمرین شده باشد. هیچ‌کدام به‌تنهایی تضمین موفقیت نیست؛ تصمیم اصلی درباره محل ثبت قطعی اطلاعات، مرز جابه‌جایی کاربران و توان سازمان برای اداره دوره گذار است.
این مقاله برای زمانی است که یک سامانه عملیاتی دارید و می‌خواهید جایگزینش کنید؛ نه زمانی که درباره تحویل تدریجی قابلیت‌های یک محصول تازه تصمیم می‌گیرید. ممکن است نرم‌افزار جدید در چند مرحله ساخته شود، اما همه کاربران در یک روز به آن منتقل شوند. برعکس، محصول می‌تواند آماده باشد و انتقال شعب یا فرایندها طی چند نوبت انجام شود. جدا کردن برنامه ساخت از برنامه انتقال، اولین قدم برای مقایسه درست پیشنهادهای اجرایی است.
تفاوت دو روش در روز کاری کاربران چیست؟
در انتقال یک‌باره، در یک بازه از پیش تعیین‌شده ثبت عملیات در سامانه قدیم متوقف می‌شود، تغییرات نهایی منتقل و کنترل می‌شوند و سامانه جدید مرجع کار روزانه می‌شود. منظور از «یک‌باره» نداشتن آمادگی قبلی نیست. آموزش، آزمایش، پاک‌سازی داده و تمرین انتقال باید قبل از آن انجام شده باشند. تفاوت در این است که نقطه تغییر مرجع اصلی، برای دامنه انتخاب‌شده مشترک است.
در انتقال مرحله‌ای، دامنه‌های مشخص در زمان‌های متفاوت جابه‌جا می‌شوند؛ مثلاً یک شعبه مستقل، یک گروه سفارش یا یک فرایند با مرز روشن. بخش منتقل‌شده با سامانه جدید کار می‌کند و بخش باقی‌مانده هنوز در سامانه قبلی است. مسئله سخت، روشن کردن وضعیت عملیات مشترک میان این دو بخش است. اگر سفارش در سیستم قدیم ایجاد شود و تحویل آن در سیستم جدید ثبت شود، باید معلوم باشد اصلاح، لغو و گزارش نهایی از کدام مسیر انجام می‌شود.
بنابراین سؤال درست این نیست که «کدام روش سریع‌تر نصب می‌شود؟» باید پرسید در هر روز از دوره انتقال، کاربر برای انجام هر کار دقیقاً کجا می‌رود و چه کسی اختلاف میان دو سامانه را حل می‌کند.
پیش از انتخاب، پنج واقعیت عملیاتی را ثبت کنید
۱. چه میزان توقف را واقعاً می‌پذیرید؟
پاسخ کلی «آخر هفته انجام می‌دهیم» کافی نیست. ممکن است فروشگاه سفارش بگیرد، دستگاه صنعتی داده ارسال کند یا واحد پشتیبانی همان زمان فعال باشد. یک بازه واقعی تعیین کنید و مشخص کنید چه ورودی‌هایی باید متوقف، صف‌بندی یا بعداً ثبت شوند. زمان لازم برای بررسی نتیجه و تصمیم بازگشت هم جزو همین بازه است؛ تمام زمان موجود را به کپی اطلاعات اختصاص ندهید.
۲. آیا دامنه‌ای مستقل برای انتقال وجود دارد؟
شعبه‌ای که موجودی، مشتری و حساب تسویه مشترک با شعب دیگر دارد لزوماً دامنه مستقل نیست. همین موضوع درباره یک ماژول با ظاهر جداگانه صدق می‌کند. مرز مناسب باید از روی گردش واقعی داده و مسئولیت افراد پیدا شود. اگر تقریباً هر عملیات از مرز عبور می‌کند، تقسیم پروژه به چند انتقال کوچک ممکن است فقط تعداد نقاط هماهنگی را بیشتر کند.
۳. چه کسی مالک هر نوع داده است؟
برای مشتری، سفارش، موجودی و وضعیت انجام کار، مرجع ثبت قطعی را مشخص کنید. نمایش اطلاعات یکسان در دو صفحه به معنی مجاز بودن ویرایش در هر دو نیست. اگر اصلاح تلفن مشتری در هر دو سامانه ممکن باشد، قاعده حل اختلاف لازم است. بهتر است تا حد امکان در هر مرحله، یک مسیر مشخص برای تغییر هر دسته اطلاعات وجود داشته باشد و مسیر دیگر صرفاً مصرف‌کننده باشد.
۴. سامانه قبلی تا چه زمانی قابل استفاده است؟
پایان پشتیبانی، محدودیت قرارداد، خرابی زیرساخت یا نبود نیروی آشنا می‌تواند مدت هم‌زیستی را محدود کند. برنامه مرحله‌ای که به ماه‌ها کار موازی متکی است، با سامانه‌ای که امکان ادامه مطمئن ندارد سازگار نیست. در مقابل، عجله برای خاموش کردن نرم‌افزار قدیمی نباید باعث شود وابستگی‌های پنهان مانند گزارش ماهانه یا تبادل فایل با شریک تجاری دیده نشوند.
۵. تیم عملیات چقدر ظرفیت تغییر دارد؟
در انتقال مرحله‌ای ممکن است تیم پشتیبانی مدتی پاسخ‌گوی دو رابط، دو مجموعه خطا و چند مسیر گزارش‌گیری باشد. در انتقال یک‌باره فشار آموزش و پشتیبانی در یک بازه متمرکز می‌شود. انتخاب باید با شیفت‌ها، مرخصی‌ها، فصل پرتراکم کسب‌وکار و حضور افراد کلیدی هماهنگ باشد. توان فنی پیمانکار جای ظرفیت پذیرش سازمان را نمی‌گیرد.
چه زمانی مهاجرت مرحله‌ای انتخاب بهتری است؟
وقتی می‌توانید یک محدوده نماینده و قابل کنترل را جدا کنید، انتقال مرحله‌ای امکان یادگیری از استفاده واقعی را فراهم می‌کند. برای مثال، ابتدا یک واحد خدماتی با فرایند استاندارد منتقل می‌شود و مشکلات آموزش یا گزارش‌گیری پیش از گسترش دامنه اصلاح می‌شوند. آن واحد نباید صرفاً آسان‌ترین مورد باشد؛ لازم است بخشی از پیچیدگی واقعی سازمان را نشان دهد تا نتیجه آزمون گمراه‌کننده نباشد.
شرط دیگر، داشتن بودجه و مسئول مشخص برای دوره گذار است. اتصال موقت دو سامانه، گزارش تطبیقی و پاسخ‌گویی به اختلاف داده کارهای واقعی‌اند، نه جزئیات رایگان پروژه. برای هر اتصال موقت باید تاریخ بازبینی و شرط حذف تعریف شود. در غیر این صورت، معماری موقت ممکن است به وضعیت دائمی تبدیل شود و سازمان هزینه نگهداری هر دو سامانه را برای مدت نامعلوم بپردازد.
یک نمونه فنی از جایگزینی تدریجی، الگوی Strangler Fig در مستندات مایکروسافت است که درخواست‌ها را میان بخش قدیمی و جدید هدایت می‌کند. این الگو معادل همه انواع مهاجرت مرحله‌ای نیست؛ صرفاً یکی از شیوه‌های پیاده‌سازی آن در شرایط مناسب معماری است.
چه زمانی انتقال یک‌باره قابل دفاع است؟
اگر سامانه محدود و وابستگی‌ها شناخته‌شده‌اند، هزینه ساخت هم‌زیستی ممکن است از منفعت آن بیشتر شود. نمونه فرضی، سامانه داخلی کوچکی است که ورودی بیرونی پیوسته ندارد و همه کاربران می‌توانند در یک بازه مشخص کار را متوقف کنند. در این وضعیت، یک تمرین کامل و یک نقطه انتقال روشن ممکن است برنامه ساده‌تر و قابل کنترل‌تری بسازد.
اما کوچک بودن سازمان معیار کافی نیست. یک مجموعه کم‌جمعیت ممکن است گردش کاری حساس و اتصال‌های متعددی داشته باشد. تصمیم باید بر اساس پیچیدگی عملیات گرفته شود، نه تعداد کارکنان. همچنین آماده بودن صفحه‌های نرم‌افزار جدید به معنی آماده بودن انتقال نیست؛ دسترسی کاربران، چاپ‌ها، پیوست‌ها، کارهای زمان‌بندی‌شده و خروجی مورد نیاز واحدهای دیگر باید بررسی شوند.
برای انتقال یک‌باره، تصمیم «ادامه یا توقف» باید پیش از پایان فرصت بازگشت گرفته شود. اگر تیم تا آخرین دقیقه صرفاً امیدوار به حل خطا بماند، داشتن نسخه پشتیبان دیگر به معنی داشتن امکان بازگشت در زمان قابل قبول نیست. مسئول تصمیم، شواهد لازم و ساعت آخر تصمیم‌گیری را قبل از روز اجرا تعیین کنید.
هزینه را فقط با مبلغ اجرای اولیه مقایسه نکنید
در پیشنهاد مرحله‌ای، هزینه اتصال موقت، هماهنگی تغییرات، آموزش چندمرحله‌ای، پشتیبانی موازی و خاموش‌سازی نهایی را جدا بخواهید. در پیشنهاد یک‌باره، هزینه تمرین انتقال، آماده‌باش تیم، توقف برنامه‌ریزی‌شده و اصلاح عملیات پس از شروع را ببینید. قیمت کمتر ممکن است صرفاً حاصل حذف بخشی از مسئولیت‌ها از پیشنهاد باشد.
به‌جای درخواست یک درصد عمومی برای صرفه‌جویی، از پیمانکار بخواهید مفروضات برآورد را بنویسد. تعداد انتقال‌ها، حجم تغییرات میان دو انتقال، تعداد ارتباط‌های بیرونی و مسئول اصلاح داده چه هستند؟ برآوردی که این موارد را پنهان می‌کند، حتی با عدد دقیق هم برای مقایسه مناسب نیست. عدم قطعیت‌ها باید قابل مشاهده باشند تا تغییر دامنه بعداً به اختلاف قراردادی تبدیل نشود.
برای تصمیم مدیریتی می‌توانید یک برگه مقایسه ساده داشته باشید: هزینه مستقیم اجرا، هزینه داخلی تیم، مدت حفظ سامانه قبلی، توقف قابل انتظار و سناریوی رسیدگی به شکست. لازم نیست همه ریسک‌ها را به عدد ظاهراً دقیق تبدیل کنید؛ مواردی که هنوز شواهد ندارند باید به‌عنوان مجهول و نیازمند آزمایش ثبت شوند.
مثال: انتقال سامانه سفارش و عملیات کارگاه
فرض کنید کارگاهی سفارش، رزرو مواد، برنامه انجام کار و تحویل را در یک سامانه قدیمی ثبت می‌کند. پیشنهاد اول انتقال مشتریان در هفته اول، سفارش‌ها در هفته دوم و موجودی در هفته سوم است. این تقسیم‌بندی ظاهراً مرحله‌ای است، اما ممکن است هر سفارش را میان چند مرجع تقسیم کند. نتیجه می‌تواند افزایش تماس‌های دستی برای پیدا کردن وضعیت درست سفارش باشد.
پیشنهاد جایگزین این است که یک جریان کامل سفارش با شرایط مشخص منتقل شود؛ مثلاً سفارش‌های جدید یک خط خدماتی که وابستگی محدود و قابل کنترل دارد. سفارش‌های باز قبلی تا پایان در مسیر قدیم باقی می‌مانند. باید مشخص شود سفارش برگشتی، تغییر نوع خدمت یا مصرف ماده مشترک چه حکمی دارد. اگر این استثناها مرز را دائماً نقض کنند، انتخاب دامنه باید بازنگری شود.
در همین مثال، اگر همه خطوط منابع مشترک دارند و جداسازی قابل اتکا نیست، انتقال یک‌باره پس از تمرین ممکن است مناسب‌تر باشد. این یک نتیجه قطعی برای همه کارگاه‌ها نیست. هدف مثال نشان دادن روش تصمیم‌گیری است: ابتدا وابستگی و استثنا را بررسی کنید، سپس نام روش انتقال را انتخاب کنید؛ نه برعکس.
برنامه بازگشت باید تکلیف عملیات جدید را روشن کند
بازگشت فقط روشن کردن نسخه قبلی نیست. اگر بعد از شروع سامانه جدید سفارش یا تغییر موجودی ثبت شده باشد، باید معلوم باشد آن عملیات چگونه حفظ و به مسیر درست منتقل می‌شود. بازگرداندن نسخه پشتیبان قدیمی بدون رسیدگی به این تغییرات ممکن است اطلاعات جدید را از دسترس عملیات خارج کند. روش جبران باید پیشاپیش طراحی و در محیط آزمایش تمرین شود.
در راهنمای تمرین بازیابی نرم‌افزار درباره اثبات عملی توان بازیابی توضیح داده‌ایم. در پروژه مهاجرت، علاوه بر بازیابی فنی، بازگشت فرایندی هم لازم است: کاربران از کدام لحظه در سامانه قبلی کار می‌کنند، چه ورودی‌هایی موقتاً متوقف می‌شوند و چه کسی تطبیق عملیات باقی‌مانده را تأیید می‌کند؟
هرچه از زمان شروع کار واقعی بگذرد، بازگشت ممکن است پیچیده‌تر شود. به همین دلیل یک برنامه خوب فقط مسیر عقب‌گرد ندارد؛ برای برخی خطاهای محدود، اصلاح رو به جلو را هم تعریف می‌کند. انتخاب میان این دو باید تابع اثر خطا و امکان حفظ صحت داده باشد، نه صرفاً تمایل تیم به اعلام موفقیت انتشار.
معیار عبور از هر مرحله را قبل از اجرا بنویسید
چه انتقال یک‌باره باشد چه مرحله‌ای، معیار پذیرش نباید «کاربران وارد شدند» باشد. ورود موفق فقط یک کنترل اولیه است. چند مسیر واقعی از شروع تا پایان، نقش‌های مجاز، گزارش‌های مهم، پیوست‌ها و ارتباط‌های بیرونی را بررسی کنید. نمونه‌های آزمون باید موارد معمول و استثناهای پرتکرار را پوشش دهند، نه فقط رکوردهای مرتب و بدون پیچیدگی.
برای خود داده‌ها، از چک‌لیست اعتبارسنجی انتقال داده استفاده کنید. در این مقاله تمرکز بر تصمیم روش انتقال است؛ صحت اطلاعات یک شرط مستقل پذیرش است و با انتخاب نام یک روش تضمین نمی‌شود. مسئول کسب‌وکار باید خروجی عملیاتی را ببیند و تیم فنی هم شواهد کنترل‌های خود را نگه دارد.
پس از شروع، یک بازه مراقبت تقویت‌شده تعیین کنید. در این بازه، خطاهای متوقف‌کننده، اختلاف‌های داده و درخواست‌های صرفاً آموزشی باید جدا ثبت شوند. هر مورد مالک و زمان پیگیری داشته باشد. گسترش دامنه در روش مرحله‌ای را تا روشن شدن علت خطاهای مهم متوقف کنید؛ رسیدن تاریخ مرحله بعد به‌تنهایی دلیل آمادگی نیست.
جمع‌بندی: روش مناسب، مسئولیت روشن می‌خواهد
مهاجرت مرحله‌ای را زمانی انتخاب کنید که مرز انتقال، مالکیت داده و هزینه هم‌زیستی روشن باشند. انتقال یک‌باره را زمانی جدی بگیرید که دامنه مهارشدنی، توقف توافق‌شده و تمرین بازگشت معتبر دارید. اگر هیچ‌کدام از این شرایط فراهم نیست، مسئله با انتخاب یک برچسب حل نمی‌شود؛ ابتدا باید ابهام‌های عملیاتی برطرف شوند.
برای بررسی پروژه خود، فهرست سامانه‌ها و اتصال‌ها، جریان‌های حیاتی، محدودیت توقف و وضعیت سفارش‌ها یا پرونده‌های باز را آماده کنید. از طریق خدمات طراحی نرم‌افزار سفارشی ایزی‌ساز می‌توانید ارزیابی مسیر جایگزینی را مطرح کنید؛ خروجی مورد انتظار باید یک نقشه انتقال با مرز مسئولیت، معیار پذیرش و برنامه بازگشت باشد، نه صرفاً تاریخ نصب نرم‌افزار جدید.