نقل موقع الشركة: هل يلزم نقل النطاق إلى مسجل آخر؟

نقل الموقع إلى مزود استضافة مختلف لا يتطلب بالضرورة نقل تسجيل النطاق إلى مسجل آخر. قبل تكليف جهة بتغيير المزود، افصلوا بين إطلاق الموقع وإدارة تسجيل النطاق وأي تغيير لصاحب التسجيل. تسمية هذه الأمور كلها «نقل النطاق» قد تجعل إطلاق الموقع معلقا على خطوة لا يحتاج إليها أصلا.

هذا دليل للتخطيط، لا إذن بتغيير حساب أو نقل نطاق أو تجاوز قفل. أكدوا القواعد المنطبقة مع الجهات المسؤولة عن النطاق الفعلي. لا تفترضوا أن إرشادات ICANN لنقل التسجيل بين المسجلين تحكم كل نطاق ذي امتداد وطني بالطريقة نفسها.

سموا التغيير المطلوب فعلا

لنتخيل شركة استشارات تستبدل موقعها القديم. يمكن أن يبقى المسجل الحالي مسؤولا عن التسجيل بينما يعمل الموقع الجديد لدى جهة أخرى. وقد ترغب الشركة أيضا في تغيير المسجل، أو تحتاج إلى تصحيح صاحب التسجيل. هذه متطلبات مستقلة حتى عندما يبيعها مورد واحد في حزمة واحدة.

اكتبوا النتيجة المطلوبة لكل جزء: أين سيعمل الموقع، ومن سيدير التسجيل، وأي خدمة ستجيب عن استعلامات DNS، وهل سيتغير صاحب التسجيل. قول المورد «نتولى كل شيء» لا يغنيه عن تحديد التغييرات التي يشملها عرضه والتغييرات التي تبقى خارج نطاقه.

تذكر الأسئلة الشائعة الرسمية لدى ICANN عن نقل النطاق تغيير مزود استضافة الويب بدلا من المسجل بوصفه خيارا قد يجنب إجراء النقل بين المسجلين. كما تذكر تغيير خوادم الأسماء أو عنوان IP للاستضافة، وتوصي بسؤال المسجل أو مزود الاستضافة عن الخيارات المتاحة.

تحققوا من قابلية النقل قبل ربطها بموعد الإطلاق

تصف الصفحة نفسها ظروفا قد تمنع النقل أو تقيده، منها التسجيل الحديث والنقل السابق وبعض تغييرات معلومات صاحب التسجيل. وتفرق بين حالات يجوز فيها للمسجل رفض الطلب وحالات يتعين عليه فيها الرفض.

لا تحولوا هذه الأمثلة إلى وعد بأن أي نطاق قابل للنقل فورا، أو إلى افتراض أن لكل قفل زرا يمكن إطفاؤه. اسألوا المسجل المسؤول عن السبب الفعلي والسياسة المنطبقة والخطوة التالية المسموح بها لنطاقكم. وقبل تعديل جهة الاتصال أو صاحب التسجيل، اطلبوا تأكيد أثر التعديل المقترح في تسلسل النقل.

لا يعني ذلك ترك معلومات تسجيل غير صحيحة دون معالجة. المقصود الحصول على خطة مدعومة من الجهة المسؤولة بدلا من إجراء تعديل عابر ثم اكتشاف أن موعد النقل لم يعد ممكنا. وإذا كان نقل الموقع يستطيع المضي مستقلا، فسجلوا هذا الخيار بدلا من تأجيل المشروع كله دون تفسير واضح للعميل.

افصلوا تأكيد التسجيل عن استمرار الخدمات

في متطلبات الانتقال، حددوا من سيحافظ على إعدادات DNS اللازمة أو يعيد إنشاءها، ومن سيتحقق من الموقع والبريد. إرسال طلب نقل التسجيل لا يثبت أن الخدمات تعمل في الوجهة المقصودة. وفي المقابل، تحميل الموقع الجديد بنجاح لا يثبت أن إدارة التسجيل انتقلت.

هذه ضوابط قبول مقترحة، وليست ضمانات تقدمها صفحة ICANN. أكدوا ما إذا كانت خدمة DNS أو البريد تعتمد على المورد الذي ستغادرونه، واتفقوا على استمرارها أو بديلها قبل إنهائها. لا تلغوا الحزمة القديمة لمجرد أن جزءا واحدا من الانتقال يبدو مكتملا؛ فقد تتضمن خدمة أخرى ما زال العمل يعتمد عليها.

أبقوا مواد التفويض خارج مستندات المشروع العادية. تصف الأسئلة الشائعة رمز Auth-Code المستخدم في النقل بين المسجلين. ينبغي لصاحب النطاق المصرح له التعامل مع هذه المواد عبر الإجراءات الآمنة للمزودين، لا نسخ رمز حقيقي في تذكرة عامة أو مسودة مقال أو محادثة. يحتاج سجل التخطيط إلى المسؤولية والحالة، لا إلى الرمز نفسه.

اقبلوا كل نتيجة على حدة

اتفقوا على دليل لكل تغيير داخل النطاق المطلوب. إدارة التسجيل وبيانات صاحبه وخدمة DNS ووظائف الموقع واستمرار البريد تحتاج إلى فحوص مستقلة. سجلوا نقل المسجل غير المكتمل بصدق حتى إن أصبح الموقع الجديد متاحا. لا تصفوا الطلب المعلق بأنه عملية منجزة.

استخدموا خريطة خدمات مختلقة في مناقشة نقل موقع الشركة. ضمنوا حالة تتغير فيها الاستضافة ويبقى التسجيل لدى الجهة نفسها، وحالة أخرى يؤكد فيها المسجل وجود قيد على النقل. اطلبوا من المورد شرح الترتيب المسموح والفحوص التي تحمي الخدمات المستمرة، وحددوا من يسجل نتيجة كل فحص.

النتيجة المفيدة خطة انتقال ذات اعتماديات صريحة، لا وعد مبهم بعنوان «ننقل النطاق». لم يُغيّر أي نطاق أو حساب مزود أو خادم أسماء أو موقع فعلي لإعداد هذا المقال.