مهاجرت دوره‌ها به پلتفرم جدید؛ چک‌لیست بدون جاگذاشتن دانشجو
موفقیت مهاجرت با آپلودشدن آخرین ویدئو تمام نمی‌شود؛ دانشجو باید همان دسترسی درست را در مقصد پیدا کند و تیم بداند هنگام خطا چه کند.
انتقال دوره به پلتفرم جدید زمانی تمام می‌شود که دانشجو بتواند با دسترسی درست، درس درست را پیدا کند و ادامه بدهد. بارگذاری فایل‌ها فقط یک بخش کار است. ساختار سرفصل، مدت مجوز، سابقهٔ سفارش، تکلیف‌ها، پیوندهای قدیمی و راه ورود نیز باید تعیین تکلیف شوند.
این چک‌لیست برای انتقال مجاز محتوای متعلق به مجموعه یا محتوایی است که حق انتقال آن را دارید. دربارهٔ دسترسی به پایگاه دادهٔ سرویس قبلی، قابلیت واردکردن رمز عبور یا انتقال خودکار همهٔ سوابق فرض نمی‌کنیم. برنامهٔ زیر الگوی اجرایی است و باید با امکانات واقعی مبدأ و مقصد تکمیل شود.
در این مقاله چه می‌خوانید؟
مرحلهٔ اول: موجودی، مالک و مقصد هر داده
پایلوت را با نمونه‌های آسان محدود نکنید
پایان پروژه را با شواهد اعلام کنید
مرحلهٔ اول: موجودی، مالک و مقصد هر داده
پیش از خرید مقصد یا لغو مبدأ، یک فهرست قابل شمارش بسازید. «همهٔ ویدئوها» توصیف خوبی برای تحویل نیست؛ تعداد، شناسه و محل فایل لازم است. اطلاعات شخصی را در فایل عمومی یا لینک بدون محدودیت قرار ندهید.
دسته | چه چیزی ثبت شود؟ | کنترل پذیرش |
|---|---|---|
دوره و درس | شناسه، عنوان، ترتیب، پیش‌نیاز | تعداد و ترتیب مقصد با فهرست تأییدشده برابر است. |
فایل و زیرنویس | نسخهٔ مرجع، اندازه، مالکیت و زبان | فایل سالم باز می‌شود و به درس درست وصل است. |
کاربر و مجوز | شناسهٔ مبدأ، دوره‌های مجاز، پایان دسترسی | هر فرد فقط دسترسی تأییدشدهٔ خودش را دارد. |
سفارش و سابقه | مرجع سفارش، وضعیت و محل نگهداری | سوابق مالی دوباره به‌عنوان خرید جدید ثبت نمی‌شوند. |
تمرین و پیشرفت | قابل انتقال، قابل بایگانی یا غیرقابل انتقال | محدودیت به دانشجو و مدرس اعلام شده است. |
نشانی‌های قبلی | لینک صفحهٔ قدیمی و صفحهٔ مربوط به آن در سایت جدید | کاربر به صفحهٔ مرتبط می‌رسد، نه صفحهٔ نامرتبط. |
اگر انتقال خودکار بخشی از اطلاعات ممکن نیست، تصمیم را پیش از شروع بنویسید: نگهداری فقط‌خواندنی، خروجی امن برای مسئول آموزش یا شروع تازه با اطلاع کاربر. فقدان قابلیت را با ساختن تاریخچهٔ جعلی جبران نکنید.
نسخهٔ پشتیبان با بستهٔ قابل انتقال تفاوت دارد
به‌جای قبول نام «بکاپ»، فهرست دقیق اطلاعات و فایل‌های قابل دریافت را بنویسید: چند دوره، چند درس، چه فایل‌هایی و کدام سوابق باید منتقل شوند؟ یک نمونه را باز کنید و شناسه درس، نسخه فایل و ارتباط آن با دوره را با نسخهٔ اصلی مقایسه کنید.
برای داده‌هایی که قرار نیست منتقل شوند نیز تصمیم مکتوب داشته باشید؛ حذف ناخواسته را نباید بعداً به‌عنوان پاک‌سازی برنامه‌ریزی‌شده توجیه کرد.
آزمون بازیابی را در محیط جدا اجرا کنید و این موارد را در عمل بررسی کنید: درس باز می‌شود، پیوست درست است و حساب آزمایشی فقط به محتوای مجاز می‌رسد. راهنمای برنامه‌ریزی تداوم و بازیابی NIST بر داشتن برنامه برای برگرداندن اطلاعات و آزمایش این برنامه تأکید می‌کند. چک‌لیست این مقاله به انتقال دوره‌ها کمک می‌کند، اما به معنی رعایت تمام شرایط آن راهنما نیست. بنویسید چه کسی و چه زمانی نسخهٔ پشتیبان را تهیه کرده، آن را کجا نگه داشته‌اید و آیا توانسته‌اید اطلاعات را از آن برگردانید.
نگاشت هویت و مجوز را پیش از واردسازی حل کنید
نام و نام خانوادگی شناسهٔ یکتا نیست. حتی شمارهٔ تماس یا ایمیل نیز ممکن است ناقص، مشترک یا تغییرکرده باشد. یک جدول نگاشت کنترل‌شده میان شناسهٔ مبدأ و شناسهٔ مقصد لازم است و موارد مبهم باید برای بررسی جدا شوند، نه اینکه با حدس به هم متصل شوند.
فرض کنید در یک نمونهٔ کاملاً فرضی، دو هنرجو نام یکسان دارند و یکی به دو دوره دسترسی خریده است. تطبیق بر اساس نام می‌تواند دورهٔ پولی را به فرد اشتباه بدهد. ابتدا شناسهٔ هر کاربر را با اطلاعات اصلی و تأییدشدهٔ حساب او مقایسه کنید.
سپس بررسی کنید دوره‌های مجاز هر شناسه درست منتقل شده باشند. یکسان‌بودن تعداد کل کاربران این خطا را آشکار نمی‌کند.
رمز عبور را از کاربر در فایل یا پیام نخواهید. اگر نمی‌توانید اطلاعات ورود را با روشی امن و مورد تأیید دو سرویس منتقل کنید، از کاربران بخواهید حساب خود را با روش رسمی سرویس جدید فعال کنند یا رمز تازه بسازند. انتقال درس‌ها و سوابق، لزوماً روش ورود کاربران را هم منتقل نمی‌کند.
پایلوت را با نمونه‌های آسان محدود نکنید
یک گروه کوچک اما متنوع انتخاب کنید: کاربر تک‌دوره، چنددوره، دسترسی نزدیک انقضا، استفاده‌کنندهٔ موبایل، مدرس و مسئول پشتیبانی. اگر فقط حساب مدیر را امتحان کنید، احتمالاً بسیاری از خطاهای مجوز را نمی‌بینید.
حساب‌های آزمایشی باید دادهٔ غیرواقعی داشته باشند یا استفاده از دادهٔ واقعی در مسیر مجاز و محدود انجام شود.
تعداد درس‌ها و فایل‌ها را با فهرست مبدأ تطبیق دهید.
اولین، میانی و آخرین درس هر ساختار نمونه را باز کنید.
زیرنویس، فایل ضمیمه و ترتیب پیش‌نیاز را بررسی کنید.
ورود دانشجو و مشاهدهٔ فقط دوره‌های خودش را تست کنید.
انقضا و محرومیت حساب فاقد مجوز را در محیط آزمایشی بررسی کنید.
مسیر درخواست کمک و پاسخ پشتیبانی را اجرا کنید.
موارد ردشده را اصلاح و دوباره آزمایش کنید.
روز انتقال، مسئول تصمیم و برنامهٔ بازگشت داشته باشد
زمانی را انتخاب کنید که با کلاس یا مهلت تکلیف مهم تداخل نداشته باشد. مشخص کنید چه زمانی تغییر اطلاعات در سامانهٔ قدیمی متوقف می‌شود، سفارش‌های بین دو مرحله کجا ثبت می‌شوند و چه کسی اختلاف اطلاعات را برطرف می‌کند.
اگر دو سامانه هم‌زمان پذیرش ثبت‌نام دارند، باید مشخص کنید کدام سامانه سفارش‌ها را ثبت و پیگیری می‌کند؛ وگرنه ممکن است یک پرداخت دو بار پردازش یا یک دسترسی فراموش شود.
پیش از اجرا، معیار توقف را بنویسید. نمونهٔ فرضی: «هر مورد دسترسی به دورهٔ فرد دیگر، انتشار مقصد را متوقف می‌کند.» مشخص کنید در چه شرایطی باید به سرویس قبلی برگردید و چه کسی اجازهٔ این تصمیم را دارد. برای برگشت، عوض‌کردن یک لینک کافی نیست.
اطلاعاتی که در سرویس جدید ثبت شده، از جمله ثبت‌نام‌ها و درخواست‌های پشتیبانی، باید حفظ شود و به‌درستی به سرویس قبلی برگردد.
پیام اطلاع‌رسانی را از نگاه دانشجو بنویسید
الگوی قابل تکمیل: «دسترسی دوره‌های شما از [زمان و منطقهٔ زمانی] در [نشانی رسمی مقصد] ادامه پیدا می‌کند. برای ورود از [روش واقعی] استفاده کنید. [بخش‌های منتقل‌شده] منتقل می‌شوند و دربارهٔ [محدودیت مشخص] از مسیر [راهکار] اقدام کنید. در صورت مشکل، عنوان دوره و شناسهٔ پیگیری را از [کانال رسمی] بفرستید؛ رمز یا کد ورود را ارسال نکنید.»
لینک رسمی را از کانال شناخته‌شدهٔ مجموعه اعلام کنید و پیش از کلیک عمومی آن را روی موبایل آزمایش کنید. وعدهٔ «هیچ تغییری احساس نمی‌کنید» ندهید اگر روش ورود، پلیر یا سابقهٔ پیشرفت عوض می‌شود.
پایان پروژه را با شواهد اعلام کنید
پس از انتقال، تعداد کاربران، اجازه‌های دسترسی، درس‌ها و فایل‌ها را در دو سرویس مقایسه کنید. بررسی چند نمونه کافی نیست؛ مطمئن شوید همهٔ اطلاعات به کاربر و دورهٔ درست وصل شده‌اند. مشکلات حل‌نشده، مسئول پیگیری و زمان حل هر مشکل را بنویسید.
سرویس قبلی را تا پایان مهلت توافق‌شده و اطمینان از امکان برگرداندن اطلاعات خاموش نکنید. در پایان، دسترسی‌های موقت را ببندید و فایل‌های انتقال را طبق قواعد نگهداری مجموعه حذف یا بایگانی کنید.
برای انتخاب مقصد، جدول ارزیابی پلتفرم و مقایسهٔ مسئولیت وردپرس و سرویس آماده را ببینید. اگر یکپارچه‌سازی نیاز دارید، بخش توسعه‌دهندگان فاکسیمون را بررسی کنید و امکان انتقال اطلاعات را با چک‌لیست حریم خصوصی هماهنگ نگه دارید. مهاجرت خوب، ادامهٔ قابل اعتماد یادگیری است، نه صرفاً جابه‌جایی فایل.
زمان انتقال را از تقویم آموزش انتخاب کنید
پیش از هر تصمیم فنی، تاریخ کلاس‌های زنده، مهلت تکلیف‌ها، شروع فروش دوره تازه و پایان دسترسی گروه‌ها را روی یک تقویم بگذارید. انتقال در روزی که چند گروه باید آزمون بدهند، حتی اگر از نظر تیم فنی خلوت باشد، انتخاب خوبی نیست. برای هر دوره مشخص کنید چه مدت می‌توانید ایجاد محتوای تازه، ثبت‌نام و تغییر مجوز را متوقف کنید. اگر هیچ پنجره توقفی وجود ندارد، باید روش همگام‌سازی تغییرهای میان دو سامانه و مسئول آن را از قبل طراحی کنید.
یک «تاریخ انجماد داده» و یک «تاریخ تغییر نشانی عمومی» تعریف کنید. این دو الزاماً یکی نیستند. ممکن است نسخه اول درس‌ها را چند روز زودتر به مقصد ببرید، اما سفارش‌ها و پرسش‌های تازه تا لحظه انتقال در مبدأ ثبت شوند. برای فاصله میان این دو تاریخ، دفتر تغییرات داشته باشید: چه درسی ویرایش شد، چه کاربری ثبت‌نام کرد، کدام مجوز تمدید شد و چه کسی آن را در مقصد اعمال می‌کند. بدون این دفتر، مغایرت‌ها بعداً شبیه خطای تصادفی دیده می‌شوند.
اگر دوره‌ای در میانه آموزش است، تصمیم انتقال آن را با مدرس همان دوره بگیرید. شاید بهتر باشد گروه فعلی در بستر قدیم تمام کند و گروه تازه در مقصد شروع شود؛ شاید هم انتقال همراه با پشتیبانی ارزش بیشتری داشته باشد. هدف، کم‌کردن اختلال یادگیری و حفظ تعهدات قبلی است، نه صرفاً رسیدن به یک تاریخ اعلامی. تصمیم هر گروه را جدا ثبت کنید تا پشتیبانی پاسخ یکسان و درست بدهد.
برای هر داده، مقصد و روش کنترل پذیرش بنویسید
فهرست موجودی باید به جدول نگاشت تبدیل شود. برای هر دوره، شناسه مبدأ، عنوان، نشانی قدیم، شناسه یا نشانی مقصد، مالک محتوا و وضعیت انتقال را ثبت کنید. برای درس‌ها، ترتیب، پیش‌نیاز و پیوست را نیز بنویسید. برای کاربران، نگاشت شناسه و مجوز به دوره لازم است. تعداد کل برابر می‌تواند خطای مهم را پنهان کند: دو دانشجو جابه‌جا شده‌اند اما شمار نهایی تغییر نکرده است. پس علاوه بر شمار، چند رابطه واقعی را با حساب آزمایشی بررسی کنید.
ستون «قابل انتقال است؟» را با پاسخ‌های روشن پر کنید: خودکار، دستی، فقط بایگانی یا غیرقابل انتقال. اگر سامانه قبلی تاریخچه تماشای درس را خروجی نمی‌دهد، آن را حدس نزنید و در مقصد پیشرفت ساختگی نسازید. در پیام به هنرجو توضیح دهید کدام بخش ادامه پیدا می‌کند و کدام بخش فقط در نسخه بایگانی قابل مشاهده است. اگر فایل اصلی یک ویدئو در دسترس نیست و فقط نسخه پخش‌شده را می‌بینید، حق و امکان فنی انتقال آن را جدا روشن کنید.
در پایان هر ردیف، معیار پذیرش عملی بگذارید. «فایل منتقل شد» کافی نیست؛ باید روی دستگاه مخاطب باز شود، به درس درست وصل باشد و نسخه به‌روز آن باشد. برای زیرنویس و فایل متنی، زبان، جهت نوشتار و خوانایی را بررسی کنید. برای حساب، علاوه بر ورود موفق، نبود دسترسی به دوره نامربوط را امتحان کنید. این معیارها به شما اجازه می‌دهد از عبارت مبهم «تقریباً همه چیز منتقل شد» عبور کنید.
پیوندهای قدیمی و سئوی دوره را در برنامه مهاجرت بیاورید
اگر نشانی صفحه دوره یا مقاله عوض می‌شود، یک جدول «URL قدیم ← URL مرتبط جدید» بسازید. هر صفحه قدیم باید تا حد امکان به صفحه متناظر خودش هدایت شود؛ فرستادن همه نشانی‌ها به صفحه اصلی، هم کاربر را سردرگم می‌کند و هم فهم رابطه محتوا را سخت می‌سازد. طبق راهنمای رسمی گوگل برای جابه‌جایی نشانی سایت، نگاشت URL، هدایت دائمی سمت سرور، به‌روزرسانی لینک‌های داخلی و سایت‌مپ جدید بخش‌های مهم انتقال‌اند. اگر فقط سامانه درسِ پشت ورود عوض می‌شود و نشانی عمومی ثابت می‌ماند، همین راهنما را بی‌دلیل به پروژه تعمیم ندهید.
برای صفحه‌های عمومی مهم، قبل و بعد از تغییر عنوان، توضیح، canonical، وضعیت index/noindex و لینک ثبت‌نام را ثبت کنید. صفحه مقصد باید از بیرون حساب قابل باز شدن باشد اگر قرار است در جستجو دیده شود. اگر محیط آزمایشی را با noindex بسته‌اید، هنگام انتشار آن را فقط برای صفحه‌های عمومیِ مورد نظر بردارید. فایل‌های PDF یا تصویرهایی که قبلاً لینک گرفته‌اند نیز در فهرست URL جا نمانند. یک پست قدیمی با لینک به جزوه نباید پس از انتقال به خطا یا فایل اشتباه برسد.
پس از انتشار، سایت‌مپ مقصد را بررسی کنید و نمونه‌ای از URLهای مهم را در Search Console دنبال کنید. جابه‌جایی نشانی می‌تواند با نوسان موقت دیده‌شدن همراه باشد؛ زمان ایندکس دوباره را نمی‌توان تضمین کرد. اگر سایت قدیم در اختیار شما نیست، درباره امکان هدایت یا نگه داشتن صفحه اطلاع‌رسانی در همان محل تصمیم بگیرید. در هر حالت، لینک‌هایی که خودتان کنترل می‌کنید، مثل معرفی دوره در شبکه‌ها و ایمیل‌های فعال، باید به مقصد درست به‌روزرسانی شوند.
ثبت‌نام و پرداخت در لحظه جابه‌جایی چه می‌شود؟
انتقال محتوا معمولاً ساده‌تر از انتقال وضعیت سفارش و حق دسترسی است. برای هر پرداختِ نزدیک به زمان تغییر، باید معلوم باشد کدام سامانه مرجع است و چه کسی موفق یا ناموفق بودن آن را بررسی می‌کند. یک شناسه سفارش را در دو سامانه به دو خرید مستقل تبدیل نکنید. اگر ثبت‌نام موقتاً بسته می‌شود، زمان آغاز و پایان را روشن اعلام کنید و لینک فروش را در کانال‌های فعال بررسی کنید. اگر بسته نمی‌شود، برای هر سفارش جدید مسیر ثبت در مقصد و روش کنترل مغایرت را بنویسید.
سه حساب آزمایشی بسازید: دانشجوی مجاز، فرد بدون مجوز و مدرس. با هر سه، ورود، مشاهده دوره، پایان دسترسی و ثبت پرسش را در محیط مقصد آزمایش کنید. اگر دوره چند سطح دسترسی دارد، نمونه‌ای از هر سطح بگذارید. تأیید با حساب مدیر به‌تنهایی گمراه‌کننده است چون مدیر معمولاً محدودیت دانشجو را نمی‌بیند. برای آزمون پرداخت واقعی از روش مجاز و کنترل‌شده استفاده کنید؛ در این راهنما هیچ پرداخت یا ثبت‌نام واقعی لازم نیست.
در برنامه بازگشت، تکلیف سفارش‌هایی که بعد از شروع انتقال در مقصد ثبت شده‌اند را هم مشخص کنید. اگر مجبور شدید به مبدأ برگردید، نادیده گرفتن این سفارش‌ها می‌تواند به از دست رفتن دسترسی پرداخت‌شده منجر شود. به همین دلیل «برگرداندن DNS» یا «بازکردن لینک قدیمی» به‌تنهایی برنامه بازگشت نیست. باید داده‌های جدید، پیام‌های پشتیبانی و مسئول پاسخ‌گویی نیز در نظر گرفته شوند.
دانش دوره را برای دستیار هوشمند هم منتقل و بازبینی کنید
اگر در مقصد از دستیار پاسخ‌گو استفاده می‌کنید، فقط فایل درس را بارگذاری نکنید. پرسش‌های متداول، نسخه درست سرفصل، محدودیت دسترسی، روش تدریس مدرس و پاسخ‌های تأییدشده را نیز فهرست کنید. قبل از فعال‌کردن پاسخ برای هنرجویان، چند سؤال واقعیِ بی‌نام را در سه گروه آزمایش کنید: پاسخ صریح در درس، سوءبرداشت رایج و پرسشی خارج از دامنه. ببینید دستیار به کدام نسخه محتوا استناد می‌کند و آیا در موضوعی که به مدرس نیاز دارد ارجاع می‌دهد.
در طول مهاجرت ممکن است درس قدیمی و تازه هم‌زمان در دسترس باشند. اگر دستیار بر نسخه قدیمی تکیه کند، پاسخ ظاهراً روان ولی نادرست برای ترم جدید می‌دهد. تاریخ و مالک هر منبع را ثبت کنید، نسخه منسوخ را از مسیر پاسخ فعال کنار بگذارید و پس از اصلاح، سؤال نمونه را دوباره بپرسید. استاد باید بتواند پاسخ را ببیند و اصلاح کند؛ این حلقه بازخورد برای تبدیل ابزار به یک دستیار واقعیِ هماهنگ با درس ضروری است.
در فاکسیمون، امکانات مدیریت دوره و دستیار را با سناریوی خودتان آزمایش کنید و فقط قابلیت‌هایی را در برنامه انتقال فرض بگیرید که در حساب و پلن شما فعال‌اند. اگر بعد از مهاجرت پرسش‌های پرتکرار کمتر وقت مدرس را بگیرند، می‌توان آن زمان را به اصلاح درس یا تولید دوره بعدی اختصاص داد؛ مقدار صرفه‌جویی و اثر بر فروش باید از داده واقعی مجموعه خودتان سنجیده شود، نه از یک وعده کلی.
روز انتقال را مثل یک تمرین عملی اجرا کنید
برای روز اصلی، یک فهرست کوتاه با ساعت و مسئول بسازید: آخرین خروجی از مبدأ، کنترل سلامت فایل، واردسازی تغییرهای دیرهنگام، آزمون حساب‌ها، تغییر لینک عمومی، ارسال پیام و فعال‌کردن پشتیبانی. برای هر گام یک نفر انجام‌دهنده و یک نفر تأییدکننده داشته باشید. اگر آزمون دسترسیِ دانشجوی فاقد مجوز شکست خورد، انتشار را متوقف کنید؛ این مشکل از جابه‌جایی جزئی یک تصویر مهم‌تر است. معیار توقف باید پیش از روز انتقال نوشته شده باشد تا فشار زمان تصمیم را تغییر ندهد.
یک تمرین خشک با داده ساختگی یا گروه کوچک انجام دهید و مدت واقعی هر گام را ثبت کنید. اگر واردسازی چند دوره بیش از انتظار طول می‌کشد، برنامه روز اصلی را اصلاح کنید. مسیر بازگشت را هم در همان تمرین امتحان کنید: آیا نسخه مبدأ هنوز در دسترس است، آیا فایل‌های جدید قابل نگه‌داری‌اند و چه کسی به دانشجو خبر می‌دهد؟ راهنمای NIST درباره برنامه تداوم و بازیابی برای فکرکردن به آزمون برنامه مفید است، اما این پروژه را به الزام یک نظام فدرال آمریکا تبدیل نمی‌کند.
بعد از تغییر، یک تیم پاسخ‌گو برای بازه مشخص داشته باشید. مشکلات را با شناسه، نوع دستگاه، دوره، زمان و وضعیت پیگیری ثبت کنید؛ از دانشجو رمز یا کد ورود نخواهید. خطاهای مشابه را دسته‌بندی کنید تا روشن شود مسئله از یک درس، یک نوع حساب یا یک مسیر فنی است. وقتی مشکل حل شد، راهنما و پیام عمومی را نیز اصلاح کنید تا همه کاربران مجبور نباشند همان سؤال را جدا بپرسند.
چه وقت می‌توان مبدأ را واقعاً کنار گذاشت؟
خاموش‌کردن سرویس قدیم را به پایان بارگذاری فایل‌ها گره نزنید. ابتدا تعداد دوره‌ها، درس‌ها، فایل‌ها و مجوزها را با فهرست توافق‌شده مقایسه کنید. نمونه‌های حساس مثل چنددوره‌ای، نزدیک انقضا و مدرس را دوباره آزمایش کنید. مواردی که منتقل نمی‌شوند باید در فهرست استثنا با راه جایگزین و مسئول مشخص باشند. پیام دانشجو باید نشانی رسمی، روش ورود، بخش‌های تغییرکرده و مسیر دریافت کمک را واضح بگوید.
یک مهلت نگهداری مبدأ و نسخه پشتیبانِ قابل بازیابی تعیین کنید. پیش از پایان آن مهلت، گزارش مشکلات باز و وضعیت سفارش‌های بین دو سامانه را مرور کنید. دسترسی‌های موقتِ تیم انتقال را پس از اتمام کار ببندید و فایل‌های واسط حاوی اطلاعات شخصی را طبق سیاست مجموعه حذف یا بایگانی کنید. برای مقصدی که هنوز انتخاب نشده، از برگه انتخاب پلتفرم فروش دوره و محاسبه هزینه کل کمک بگیرید.
مهاجرت موفق برای دانشجو یعنی مسیر یادگیری‌اش قابل فهم مانده است. اگر می‌خواهید انتقال به فاکسیمون را بررسی کنید، از ثبت‌نام و یک دوره آزمایشی کوچک شروع کنید؛ قبل از جابه‌جایی همه هنرجویان، مجوز، محتوای درس، پرسش‌وپاسخ و پیام‌های پشتیبانی را با همین چک‌لیست آزمایش کنید. نتیجه آزمون تعیین می‌کند چه بخش‌هایی آماده‌اند و کدام بخش‌ها به تصمیم یا اتصال بیشتر نیاز دارند.
سه پرسش عملی پیش از اعلام پایان مهاجرت
اگر یک دانشجو بگوید دوره‌اش گم شده، از کجا شروع کنیم؟ ابتدا شناسه حساب و مرجع سفارش را از مسیر امن پشتیبانی بررسی کنید، نه با درخواست رمز عبور. سپس جدول نگاشت کاربر و دوره را ببینید: آیا سفارش در مبدأ معتبر است، آیا شناسه مقصد درست وصل شده و آیا پایان دسترسی همان چیزی است که به دانشجو گفته شده؟ مشکل را با شماره پیگیری ثبت کنید. اگر یک الگوی مشترک در چند حساب دیده شد، بررسی را از سطح فردی به قاعده واردسازی ببرید.
اگر همه فایل‌ها منتقل شده‌اند، چرا هنوز مبدأ را نگه داریم؟ چون فایل تنها یکی از اجزای خدمت است. ممکن است دانشجو هنوز از لینک قدیمی وارد شود، سابقه پرداخت برای پشتیبانی لازم باشد یا یک خطای مجوز فقط در نمونه کم‌تعداد دیده شود. مدت نگهداری باید با قرارداد، نیاز عملی و سیاست داده مجموعه تعیین شود. در این مدت، دسترسی مبدأ را فقط برای افراد مجاز و هدف روشن نگه دارید؛ باز ماندن دو سامانه برای همیشه نیز هزینه و ابهام ایجاد می‌کند.
اگر مقصد API دارد، آیا انتقال خودکار قطعی است؟ نه. وجود API درباره قالب داده، محدودیت درخواست، مجوز ورود، نگاشت شناسه و امکان انتقال همه سوابق چیزی را به‌تنهایی ثابت نمی‌کند. یک نمونه کوچک با داده ساختگی را از ابتدا تا انتها منتقل کنید و نتیجه را در حساب دانشجو و مدرس ببینید. اگر بخشی مانند پیشرفت درس یا گفت‌وگوی گذشته قابل واردسازی نیست، آن را در تصمیم و پیام انتقال صریح ثبت کنید. اتصال موفق در یک نمونه نیز جای آزمون حجم و شرایط واقعی را نمی‌گیرد.
چک‌لیست کوتاه اجرا
نگاشت هویت و مجوز را پیش از واردسازی حل کنید
پایلوت را با نمونه‌های آسان محدود نکنید
پیام اطلاع‌رسانی را از نگاه دانشجو بنویسید
پایان پروژه را با شواهد اعلام کنید