सऊदी व्यवसायों के लिए क्लाउड माइग्रेशन चेकलिस्ट

सऊदी व्यवसायों के लिए एक व्यावहारिक, चरण-दर-चरण क्लाउड माइग्रेशन चेकलिस्ट — जिसमें डिस्कवरी, डेटा रेज़िडेंसी और PDPL अनुपालन, DNS और ईमेल कटओवर, परीक्षण और रोलबैक शामिल हैं, साथ ही असली कमांड जिन्हें आप चला सकते हैं।

1. डिस्कवरी: वास्तव में जो चल रहा है उसकी सूची बनाएं

आप उसे माइग्रेट नहीं कर सकते जिसे आपने मापा ही नहीं है। कुछ भी छूने से पहले, एक ही इन्वेंट्री शीट तैयार करें।

• डोमेन और DNS रिकॉर्ड — हर A, AAAA, CNAME, MX, TXT (SPF/DKIM/DMARC), और SRV रिकॉर्ड की सूची बनाएं।
• वर्कलोड — साइटें, डेटाबेस, मेलबॉक्स, क्रॉन जॉब्स, बैकग्राउंड वर्कर्स।
• डेटा वॉल्यूम — प्रत्येक डेटाबेस और डॉक्यूमेंट स्टोर का आकार नोट करें ताकि आप लक्षित सिस्टम का आकार सही ढंग से तय कर सकें।
• निर्भरताएं (Dependencies) — थर्ड-पार्टी API, पेमेंट गेटवे, और कोई भी हार्ड-कोडेड IP एलाउलिस्ट।

कमांड लाइन से DNS को जल्दी से प्राप्त करें:

dig alskyline.com ANY +noall +answer
dig MX alskyline.com +short
dig TXT alskyline.com +short

2. डेटा रेज़िडेंसी और अनुपालन

सऊदी संगठनों के लिए, डेटा कहाँ रहता है यह एक प्राथमिक आवश्यकता है, कोई बाद में सोचने वाली बात नहीं। सऊदी अरब का व्यक्तिगत डेटा संरक्षण कानून (PDPL), जिसे SDAIA द्वारा लागू किया जाता है, व्यक्तिगत डेटा के सीमा-पार स्थानांतरण को प्रतिबंधित करता है, और राष्ट्रीय साइबर सुरक्षा प्राधिकरण (NCA) के आवश्यक साइबर सुरक्षा नियंत्रण (Essential Cybersecurity Controls) यह अपेक्षा करते हैं कि संवेदनशील वर्कलोड को उचित सुरक्षा उपायों के साथ होस्ट किया जाए।

इन-किंगडम इन्फ्रास्ट्रक्चर पर होस्टिंग करने से उस चर्चा का सबसे कठिन हिस्सा समाप्त हो जाता है। Skyline Cloud डिफ़ॉल्ट रूप से डेटा को इन-किंगडम रखता है, जो आपके PDPL डेटा-ट्रांसफर मूल्यांकन को सरल बनाता है और सऊदी उपयोगकर्ताओं के लिए लेटेंसी को कम रखता है। प्रत्येक वर्कलोड के लिए दस्तावेज़ीकृत करें:

• डेटा का वर्गीकरण (सार्वजनिक, आंतरिक, गोपनीय, व्यक्तिगत)।
• होस्टिंग रीजन और प्रोसेसर (आपका होस्टिंग अनुबंध इसे कवर करता है)।
• रिटेंशन और बैकअप का स्थान।

प्रत्येक वर्कलोड को सही प्रोडक्ट टियर से मैप करने के लिए क्लाउड होस्टिंग सेवा अवलोकन की समीक्षा करें।

3. लक्षित आर्किटेक्चर चुनें

प्रत्येक वर्कलोड को उसके लिए उपयुक्त सबसे सरल प्रोडक्ट से मिलाएं:

ओवर-प्रोविजन करने के बजाय सही आकार चुनें। एक VPS को बाद में वर्टिकली स्केल करना आसान है, इसलिए उसी से शुरू करें जिसे आपके डिस्कवरी आंकड़े उचित ठहराते हैं।

4. प्रोविज़न और स्टेज करें — कटओवर से पहले

लक्षित वातावरण बनाएं और डेटा को जबकि पुराना सिस्टम चालू रहता है माइग्रेट करें। यही स्टेजिंग चरण माइग्रेशन को रिवर्सिबल बनाता है।

VPS पर एक सामान्य साइट + डेटाबेस मूव के लिए:

# On the source: export the database
mysqldump -u dbuser -p --single-transaction --quick mydb > mydb.sql

# Copy database and files to the new server
scp mydb.sql user@new-server-ip:/tmp/
rsync -avz --progress /var/www/mysite/ user@new-server-ip:/var/www/mysite/

# On the target: import
mysql -u dbuser -p mydb < /tmp/mydb.sql

फिर एक टेस्ट होस्टनेम या अपनी लोकल hosts फ़ाइल को नए सर्वर के IP पर पॉइंट करें और पुष्टि करें कि एप्लिकेशन लोड होता है, लॉग इन होता है, और डेटाबेस में सही ढंग से लिखता है — यह सब किसी भी सार्वजनिक DNS परिवर्तन से पहले।

5. कटओवर से पहले DNS TTL कम करें

DNS परिवर्तन TTL (टाइम टू लिव) के आधार पर प्रोपेगेट होते हैं। जिन रिकॉर्ड को आप बदलेंगे उन पर TTL को नियोजित कटओवर से कम से कम 24-48 घंटे पहले 300 सेकंड (5 मिनट) तक कम करें। मौजूदा रिज़ॉल्वर तब स्विच करते समय पुराने उत्तर को जल्दी भूल जाएंगे।

# Verify the current TTL on your A record
dig A www.alskyline.com +nocomments +ttlid

इन परिवर्तनों को Skyline managed DNS के साथ साफ-सुथरे तरीके से प्रबंधित करें ताकि कम किया गया TTL और कटओवर एक ही कंसोल में हों।

6. ईमेल को सावधानी से माइग्रेट करें

ईमेल वह वर्कलोड है जो जल्दबाजी करने पर सबसे कष्टदायक रूप से टूटता है। पहले लक्षित सिस्टम पर मेलबॉक्स प्रोविज़न करें, फिर मौजूदा मेल को imapsync के साथ सिंक करें ताकि कुछ भी न खोए:

imapsync \
  --host1 old-mail.example.com --user1 ahmed@alskyline.com --password1 'OLD' \
  --host2 mail.alskyline.com   --user2 ahmed@alskyline.com --password2 'NEW' \
  --ssl1 --ssl2

एक ट्रांज़िशन विंडो के लिए पुराने सर्वर को मेल स्वीकार करते रहने दें। जब आप MX रिकॉर्ड स्थानांतरित करें, तो SPF, DKIM, और DMARC को भी अपडेट करें ताकि आउटबाउंड मेल ऑथेंटिकेशन में पास होता रहे। प्रकाशित करने के लिए सटीक रिकॉर्ड के लिए बिज़नेस ईमेल होस्टिंग मार्गदर्शन देखें।

7. कटओवर करें और सत्यापित करें

कटओवर वाले दिन, क्रम में काम करें: डेटा और मेल का एक अंतिम डेल्टा सिंक करें, फिर DNS रिकॉर्ड अपडेट करें (पहले A/AAAA, सबसे अंत में MX)। चूँकि TTL कम है, प्रोपेगेशन तेज़ होता है। तुरंत सत्यापित करें:

# Confirm the new IP is being served
dig A www.alskyline.com +short
curl -sI https://www.alskyline.com | head -n 1

# Confirm mail is routing to the new host
dig MX alskyline.com +short

पूरी चेकलिस्ट पर चलें: साइट एक वैध सर्टिफिकेट के साथ HTTPS पर लोड होती है, लॉगिन काम करते हैं, एक टेस्ट ट्रांज़ैक्शन पूरा होता है, शेड्यूल किए गए जॉब्स चलते हैं, और एक टेस्ट ईमेल दोनों दिशाओं में भेजा और प्राप्त किया जाता है।

8. डीकमीशन करें — लेकिन रोलबैक का रास्ता खुला रखें

पुराने वातावरण को तुरंत न हटाएं। इसे कम से कम एक से दो सप्ताह के लिए फ़्रोज़न अवस्था में चालू रखें। यदि कुछ भी प्रतिगमन (regress) करता है, तो पुराने सर्वर के रिकॉर्ड को वापस ऊपर उठाना (TTL अभी भी कम है) आपका तुरंत रोलबैक है। केवल एक साफ-सुथरी मॉनिटरिंग विंडो के बाद ही आपको पुराने सिस्टम का अंतिम बैकअप लेना चाहिए और उसे डीकमीशन करना चाहिए।

त्वरित संदर्भ चेकलिस्ट

• [ ] डोमेन, वर्कलोड, डेटा आकार, निर्भरताओं की पूरी इन्वेंट्री
• [ ] PDPL/NCA के लिए डेटा वर्गीकरण + रेज़िडेंसी दस्तावेज़ीकृत
• [ ] वास्तविक आंकड़ों से आकारित लक्षित आर्किटेक्चर
• [ ] लक्षित सिस्टम पर डेटा और मेल स्टेज और परीक्षण किया गया
• [ ] DNS TTL 24-48 घंटे पहले 300s तक कम किया गया
• [ ] ईमेल सिंक किया गया; SPF/DKIM/DMARC अपडेट किया गया
• [ ] कटओवर अंत-से-अंत सत्यापित किया गया
• [ ] पुराना वातावरण रोलबैक के लिए फ़्रोज़न, फिर डीकमीशन किया गया

इस तरह से किया गया माइग्रेशन कोई डरावना "बिग बैंग" नहीं होता — हर चरण परीक्षण योग्य और रिवर्सिबल होता है, और आपका डेटा कभी किंगडम से बाहर नहीं जाता।

शुरू करने के लिए तैयार हैं? आज ही अपना Skyline Cloud अकाउंट बनाएं और अपना लक्षित वातावरण प्रोविज़न करें — पहले दिन से ही इन-किंगडम डेटा रेज़िडेंसी और स्थानीय अरबी सपोर्ट के साथ।