سعودی کاروباروں کے لیے کلاؤڈ مائیگریشن چیک لسٹ

سعودی کاروباروں کے لیے ایک عملی، مرحلہ وار کلاؤڈ مائیگریشن چیک لسٹ — دریافت، ڈیٹا ریزیڈنسی اور PDPL تعمیل، DNS اور ای میل کٹ اوور، ٹیسٹنگ اور رول بیک کا احاطہ کرتی ہے، ان حقیقی کمانڈز کے ساتھ جنہیں آپ خود چلا سکتے ہیں۔

1. دریافت: جان لیں کہ آپ اصل میں کیا چلا رہے ہیں

جس چیز کو آپ نے ناپا ہی نہیں، اسے منتقل نہیں کر سکتے۔ کسی بھی چیز کو چھونے سے پہلے، ایک ہی انوینٹری شیٹ تیار کریں۔

• ڈومینز اور DNS ریکارڈز — ہر A، AAAA، CNAME، MX، TXT (SPF/DKIM/DMARC)، اور SRV ریکارڈ کی فہرست بنائیں۔
• ورک لوڈز — سائٹس، ڈیٹابیسز، میل باکسز، کرون جابز، بیک گراؤنڈ ورکرز۔
• ڈیٹا کے حجم — ہر ڈیٹابیس اور دستاویزی اسٹور کا حجم نوٹ کریں تاکہ آپ ہدف کا سائز درست طور پر طے کر سکیں۔
• انحصارات (Dependencies) — تھرڈ پارٹی APIs، پیمنٹ گیٹ ویز، اور کوئی بھی ہارڈ کوڈڈ IP اجازت نامہ فہرستیں (allowlists)۔

کمانڈ لائن سے DNS تیزی سے حاصل کریں:

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

2. ڈیٹا ریزیڈنسی اور تعمیل

سعودی اداروں کے لیے، ڈیٹا کہاں رہتا ہے یہ ایک بنیادی تقاضا ہے، بعد میں سوچنے والی کوئی بات نہیں۔ سعودی عرب کا پرسنل ڈیٹا پروٹیکشن لاء (PDPL)، جسے SDAIA نافذ کرتا ہے، ذاتی ڈیٹا کی سرحد پار منتقلی کو محدود کرتا ہے، اور نیشنل سائبر سیکیورٹی اتھارٹی (NCA) کے ضروری سائبر سیکیورٹی کنٹرولز کی توقع ہے کہ حساس ورک لوڈز کو مناسب حفاظتی تدابیر کے ساتھ ہوسٹ کیا جائے۔

ان کنگڈم (مملکت کے اندر) انفراسٹرکچر پر ہوسٹنگ اس گفتگو کے سب سے مشکل حصے کو ختم کر دیتی ہے۔ Skyline Cloud بطورِ ڈیفالٹ ڈیٹا کو مملکت کے اندر رکھتا ہے، جو آپ کے PDPL ڈیٹا ٹرانسفر جائزے کو آسان بناتا ہے اور سعودی صارفین کے لیے لیٹنسی کو کم رکھتا ہے۔ ہر ورک لوڈ کے لیے دستاویز بنائیں:

• ڈیٹا کی درجہ بندی (عوامی، اندرونی، خفیہ، ذاتی)۔
• ہوسٹنگ ریجن اور پروسیسر (آپ کا ہوسٹنگ معاہدہ اس کا احاطہ کرتا ہے)۔
• برقراری (retention) اور بیک اپ کا مقام۔

ہر ورک لوڈ کو درست پروڈکٹ ٹیئر سے ملانے کے لیے کلاؤڈ ہوسٹنگ سروس کا جائزہ دیکھیں۔

3. ہدف کا فنِ تعمیر (Architecture) منتخب کریں

ہر ورک لوڈ کو اس سادہ ترین پروڈکٹ سے ملائیں جو موزوں ہو:

حد سے زیادہ فراہم کرنے کے بجائے درست سائز کا انتخاب کریں۔ ایک VPS کو بعد میں عمودی طور پر اسکیل کرنا آسان ہے، لہٰذا اسی سے آغاز کریں جس کا آپ کی دریافت کے اعداد و شمار جواز پیش کرتے ہوں۔

4. فراہم کریں اور اسٹیج کریں — کٹ اوور سے پہلے

ہدف کا ماحول بنائیں اور ڈیٹا منتقل کریں جبکہ پرانا سسٹم لائیو رہے۔ یہی اسٹیجنگ کا مرحلہ مائیگریشن کو واپس پلٹنے کے قابل (reversible) بناتا ہے۔

ایک عام سائٹ + ڈیٹابیس کو 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 (time to live) کی بنیاد پر پھیلتی ہیں۔ منصوبہ بند کٹ اوور سے کم از کم 24-48 گھنٹے پہلے ان ریکارڈز کا TTL، جنہیں آپ بدلیں گے، 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 کو بھی اپ ڈیٹ کریں تاکہ آؤٹ باؤنڈ میل توثیق (authentication) میں کامیاب ہوتی رہے۔ شائع کیے جانے والے درست ریکارڈز کے لیے بزنس ای میل ہوسٹنگ کی رہنمائی دیکھیں۔

7. کٹ اوور کریں اور تصدیق کریں

کٹ اوور کے دن، ترتیب سے کام کریں: ڈیٹا اور میل کا ایک حتمی ڈیلٹا سِنک کریں، پھر DNS ریکارڈز کو اپ ڈیٹ کریں (پہلے A/AAAA، آخر میں MX)۔ چونکہ TTL کم ہے، اشاعت (propagation) تیز ہوتی ہے۔ فوری تصدیق کریں:

# 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. ختم کریں (Decommission) — لیکن رول بیک کا راستہ کھلا رکھیں

پرانے ماحول کو فوری طور پر حذف نہ کریں۔ اسے کم از کم ایک سے دو ہفتے تک منجمد (frozen) حالت میں چلتا رہنے دیں۔ اگر کچھ بھی خراب ہوتا ہے، تو پرانے سرور کے ریکارڈز کو دوبارہ اوپر لے آنا (TTL ابھی بھی کم ہے) آپ کا فوری رول بیک ہے۔ صرف ایک صاف نگرانی کی مدت کے بعد ہی آپ کو پرانے سسٹم کا حتمی بیک اپ لینا چاہیے اور اسے ختم کرنا چاہیے۔

فوری حوالہ چیک لسٹ

• [ ] ڈومینز، ورک لوڈز، ڈیٹا کے حجم، انحصارات کی مکمل انوینٹری
• [ ] PDPL/NCA کے لیے ڈیٹا کی درجہ بندی + ریزیڈنسی دستاویز شدہ
• [ ] ہدف کا فنِ تعمیر حقیقی اعداد و شمار سے سائز کیا گیا
• [ ] ہدف پر ڈیٹا اور میل اسٹیج اور ٹیسٹ کیے گئے
• [ ] DNS TTL کو 24-48 گھنٹے پہلے 300s تک کم کیا گیا
• [ ] ای میل سِنک کی گئی؛ SPF/DKIM/DMARC اپ ڈیٹ کیے گئے
• [ ] کٹ اوور کی ابتدا سے انتہا تک تصدیق کی گئی
• [ ] پرانا ماحول رول بیک کے لیے منجمد، پھر ختم کیا گیا

اس طریقے سے کی گئی مائیگریشن میں کوئی خوفناک "بِگ بینگ" نہیں ہوتا — ہر مرحلہ قابلِ ٹیسٹ اور قابلِ واپسی ہے، اور آپ کا ڈیٹا کبھی مملکت سے باہر نہیں جاتا۔

شروع کرنے کے لیے تیار ہیں؟ آج ہی اپنا Skyline Cloud اکاؤنٹ بنائیں اور اپنا ہدف کا ماحول فراہم کریں — پہلے دن سے ہی ان کنگڈم ڈیٹا ریزیڈنسی اور مقامی عربی سپورٹ کے ساتھ۔