چطور سایت را منتقل کنیم و سفارش‌ها و ایمیل را از دست ندهیم؟

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

برای یک سایت معرفی شرکت، انتقال معمولاً ساده‌تر از فروشگاهی با سفارش‌های پیوسته است. در این آموزش روند را قدم‌به‌قدم توضیح می‌دهیم. «بدون قطعی» هدف برنامه‌ریزی است، نه تضمینی که فقط با تغییر DNS به دست بیاید؛ بعضی برنامه‌ها برای حفظ درست داده به توقف کوتاهِ ثبت تغییر نیاز دارند.

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

نسخهٔ پشتیبان مستقل بگیرید و دسترسی مقصد را آماده کنید. در برنامه بنویسید چه کسی تصمیم تغییر DNS را می‌گیرد و اگر مقصد مشکل داشت، چه کسی برگشت را انجام می‌دهد. سرور قبلی را تا پایان بررسی نگه دارید.

اگر قرار است TTL را کاهش دهید، از قبل انجام دهید تا پاسخ‌های ذخیره‌شدهٔ قدیمی فرصت پایان اعتبار داشته باشند. آموزش انتشار DNS توضیح می‌دهد چرا تغییر در پنل برای همه فوری دیده نمی‌شود.

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

از میزبان روش پیش‌نمایش صحیح با نام اصلی دامنه را بخواهید. بعضی پروژه‌ها به نام دامنه، HTTPS یا کوکی وابسته‌اند و بازکردن IP خام آن‌ها را درست آزمایش نمی‌کند. مدیر فنی می‌تواند با روش کنترل‌شده، فقط کامپیوتر آزمایش‌کننده را به مقصد جدید هدایت کند، بدون تغییر مسیر همهٔ کاربران.

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

اگر صبح کپی گرفته‌اید و شب تغییر DNS می‌دهید، اطلاعات امروز صبح تا شب ممکن است فقط در سایت قبلی باشد. برای وبلاگ شاید یک نوشتهٔ تازه باشد؛ برای فروشگاه، سفارش و پرداخت است.

برای انتقال معمول فروشگاه، می‌توان در زمان کم‌ترافیک ثبت سفارش و تغییرات را کوتاه‌مدت متوقف کرد، آخرین نسخهٔ سازگار داده را منتقل کرد، بررسی انجام داد و سپس مقصد جدید را فعال کرد. برای پروژه‌ای که حتی این توقف کوتاه هم قابل قبول نیست، همگام‌سازی و مسیر نوشتن داده باید به‌طور تخصصی طراحی شود؛ دو دیتابیس مستقل را نمی‌توان صرفاً با تغییر DNS هماهنگ فرض کرد.

زمان توقف احتمالی را به کاربران و مسئولان مرتبط اعلام کنید. پس از تغییر نیز مطمئن شوید سایت قبلی سفارش جدیدِ جداگانه ثبت نمی‌کند. چون برخی کاربران هنوز پاسخ DNS قبلی دارند، باید برای مراجعهٔ آن‌ها روش مناسب، مانند هدایت کنترل‌شده به مقصد واحد، با مدیر فنی تعیین شود.

اگر ایمیل روی سرویس قبلی است، باید بدانید قرار است همان‌جا بماند یا منتقل شود. حفظ رکوردهای MX و رکوردهای تأیید ارسال اهمیت دارد. کپی سایت به معنی کپی صندوق‌های ایمیل نیست.

برای انتقال صندوق‌ها، نسخهٔ پیام‌ها و پیام‌های تازهٔ حین انتقال باید در برنامه باشند. پس از تغییر، از یک آدرس بیرونی به صندوق نمونه پیام بفرستید و از آن هم پاسخ بدهید. نمایش صندوق در پنل ثابت نمی‌کند ارسال و دریافت اینترنتی درست است.

اگر بعد از فعال‌شدن مقصد، سفارش جدید ثبت شده باشد، برگشت سادهٔ DNS به سرور قبلی می‌تواند داده را دو قسمت کند. قبل از هر برگشت، مسئول فنی باید وضعیت اطلاعات تازه و تراکنش‌ها را بررسی کند. برنامهٔ برگشت فقط «IP قبلی را وارد کن» نیست.

برای همین بهتر است تغییرهای اولیه محدود و قابل بررسی باشند و بعد از انتقال، سفارش‌ها، فرم‌ها و لاگ خطا را نزدیک‌تر دنبال کنید. شمارهٔ نمونه و ساعت رخداد را نگه دارید تا مقایسه با مقصد قبلی ممکن باشد.

وقتی صفحات، خرید، ایمیل، فایل‌ها و بکاپ مقصد تأیید شدند و دورهٔ تغییر مسیر هم سپری شد، دربارهٔ کنارگذاشتن سرویس قبلی تصمیم بگیرید. اگر در انتخاب هاست یا اجرای انتقال کمک می‌خواهید، محدودهٔ خدمات مدیریت سرور را روشن کنید. انتقال خوب کاری است که نتیجه‌اش را بتوانید در استفادهٔ واقعی ببینید و اگر اشکالی پیدا شد، راه پیگیری مشخص داشته باشید.