---
service: "Publicasta"
schema_version: "1.0"
article_id: 915
title: "يحوّل AWS Transform شفرة .NET من Azure، لكن الترحيل ما زال يحتاج إلى مراجعة معمارية"
language: "ar"
default_language: "en"
canonical_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review?lang=ar"
json_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.json?lang=ar"
api_url: "https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_transform_azure_code_conversion_migration_review?lang=ar"
channel_url: "https://publicasta.com/api/public/v1/channels/it_today_news"
channel_articles: "https://publicasta.com/api/public/v1/channels/it_today_news/articles"
search_url: "https://publicasta.com/api/public/v1/search"
documentation_url: "https://publicasta.com/api-docs#reading-publicasta"
openapi_url: "https://publicasta.com/api-docs/openapi.json"
published_at: "2026-10-19T17:11:20+00:00"
updated_at: "2026-10-19T17:11:20+00:00"
translations:
  - language: "ar"
    html_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review?lang=ar"
    markdown_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.md?lang=ar"
    json_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.json?lang=ar"
  - language: "de"
    html_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review?lang=de"
    markdown_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.md?lang=de"
    json_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.json?lang=de"
  - language: "en"
    html_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review?lang=en"
    markdown_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.md?lang=en"
    json_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.json?lang=en"
  - language: "es"
    html_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review?lang=es"
    markdown_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.md?lang=es"
    json_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.json?lang=es"
  - language: "fr"
    html_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review?lang=fr"
    markdown_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.md?lang=fr"
    json_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.json?lang=fr"
  - language: "pl"
    html_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review?lang=pl"
    markdown_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.md?lang=pl"
    json_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.json?lang=pl"
  - language: "ru"
    html_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review?lang=ru"
    markdown_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.md?lang=ru"
    json_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.json?lang=ru"
  - language: "zh"
    html_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review?lang=zh"
    markdown_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.md?lang=zh"
    json_url: "https://publicasta.com/it_today_news/aws_transform_azure_code_conversion_migration_review.json?lang=zh"
---

# يحوّل AWS Transform شفرة .NET من Azure، لكن الترحيل ما زال يحتاج إلى مراجعة معمارية

> يستطيع AWS Transform الآن ترجمة استدعاءات محددة من Azure SDK إلى نظيراتها في AWS لتطبيقات .NET الحديثة. لكن السؤال الأهم ليس ما إذا كانت الشفرة الناتجة تُجمّع، بل ما إذا كانت الهوية وسلوك البيانات ومعالجة الأعطال والعمليات ستظل تعمل بعد انتقالها إلى سحابة أخرى.

أعلنت AWS عن الإتاحة العامة لميزة لتحويل الشفرة في AWS Transform، تعيد كتابة استدعاءات محددة من Azure SDK في تطبيقات .NET الحديثة إلى نظيراتها في AWS. ويغطي الإعلان، المنشور في 16 أكتوبر، التحويل من Azure Functions إلى AWS Lambda، ومن Azure Blob Storage إلى Amazon S3، ومن Azure Queue Storage إلى Amazon SQS. أما التحويل من Azure Cosmos DB إلى Amazon DynamoDB فمتاح بوصفه تحويلاً تجريبياً.

 ![مهندس يراجع عملية ترحيل مفصلة لشفرة .NET من Azure إلى AWS مع التخزين وقوائم الانتظار والوظائف عديمة الخوادم وضوابط الهوية وفحوصات البنية المعمارية.](https://publicasta.com/storage/projects/17/pages/915/2026/10/a7d39b2f-4e0a-4a39-97e1-43f1a81cb581.webp)

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

 ينبغي أن يحدد هذا التمييز طريقة تقييم فرق المنصات والهندسة للميزة. تعاملوا مع AWS Transform بوصفه مسرّعاً لمسار عمل محدد للتحديث، لا موافقةً على تبديل المزوّد بمجرد قبول طلب سحب مولّد آلياً.

 ## ما أعلنته AWS

 يمكن لوكيل تحديث .NET في AWS Transform فحص الشفرة المصدرية المقدمة، وتحديد استخدام Azure SDK، وإدراج خيارات التحويل في تقرير تقييم وخطة تحديث. يستطيع الفريق قبول هذه الخيارات أو تغييرها أو إلغاء الاشتراك فيها قبل تشغيل التحويل.

 وتظل عمليات الربط المتاحة عموماً محدودة عمداً:

 - يمكن تحويل Azure Functions إلى دوال AWS Lambda.
- يمكن تحويل استدعاءات Azure Blob Storage SDK إلى استدعاءات Amazon S3 SDK.
- يمكن تحويل استدعاءات Azure Queue Storage إلى استدعاءات Amazon SQS.
- يُدرج التحويل من Azure Cosmos DB إلى Amazon DynamoDB بوصفه قدرة تجريبية.

 تقول AWS إن الميزة متاحة في ثماني مناطق: شرق الولايات المتحدة (شمال فرجينيا)، وآسيا والمحيط الهادئ (مومباي وطوكيو وسيول)، وآسيا والمحيط الهادئ (سيدني)، وكندا (الوسطى)، وأوروبا (فرانكفورت ولندن). وتوضح الوثائق أيضاً قيداً مهماً: فالقدرة تحوّل شفرة التطبيق ولا تتولى ترحيل البنية التحتية السحابية.

 هذا القيد ليس هامشاً. ففي خدمة حقيقية، لا تمثل حزمة SDK سوى طبقة واحدة من تبعية المزوّد. قد تعتمد Azure Function على خطة استضافة، وهوية مُدارة، وإعدادات تطبيق، ونقاط نهاية خاصة، وفتحات نشر، وارتباطات أحداث، وحسابات تخزين، ومراجع Key Vault، وقواعد مراقبة، وقيود على الشبكة. واستبدال مساحة أسماء واستدعاء طريقة يترك تلك الافتراضات المحيطة ليكتشفها الناس ويعيدوا بناءها.

 لذلك تعالج ميزة AWS جزءاً واضحاً من تكلفة الترحيل: ترجمة شفرة التطبيق الخاصة بالمزوّد. لكنها لا تلغي الحاجة إلى تحديد المعمارية المستهدفة.

 ## لماذا لا تعني «الخدمة المكافئة» سلوكاً مكافئاً

 تشجع أسماء الخدمات السحابية على تماثل زائف. فـ Blob Storage وS3 كلاهما مخزنا كائنات. وAzure Queue Storage وSQS كلاهما خدمتا قوائم انتظار. وAzure Functions وLambda منصتا حوسبة بلا خوادم. وعلى مستوى واجهة برمجة التطبيقات، تكون هذه المقارنات مفيدة. أما في وقت التشغيل، فهي غير مكتملة.

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

 يمثل تخزين الكائنات مثالاً جيداً. فقد يرفع مسار من مسارات الشفرة كائناً، ويضبط بياناته الوصفية، وينشئ عنوان URL مؤقتاً، ثم يفترض زمناً معيناً لظهور الكائن، أو سلوكاً محدداً عند الكتابة فوقه، أو اصطلاحاً معيناً للمجموع الاختباري، أو نموذج تفويض بعينه. وقد تدعم الخدمة المستهدفة عملية مماثلة، لكنها تستخدم قيماً افتراضية أو ترويسات أو أنواع أخطاء أو آليات دورة حياة أو مفردات سياسات مختلفة. يمكن لاستدعاء حُوّل آلياً أن يُجمّع بنجاح، ومع ذلك يغيّر السلوك الذي تراقبه الأنظمة اللاحقة.

 وتنشئ قوائم الانتظار مشكلة مشابهة. فالمنتج والمستهلك مرتبطان بأكثر من طريقة إرسال. إذ يعتمدان على دلالات التسليم، ومهل إخفاء الرسائل، والاحتفاظ بها، والحد الأقصى لحجم الرسالة، وتوقعات الترتيب، وسلوك الرسائل الميتة، وسياسة إعادة التوجيه، ومعالجة التكرارات، وتوقيت إعادة المحاولة. وقد ينتج التحويل من Azure Queue Storage إلى SQS استدعاءات AWS صحيحة، من دون إثبات أن المستهلك سيظل آمناً عند إعادة التسليم أو أن سير عمل الرسائل السامة القائم سيستمر في العمل.

 تضيف الدوال طبقة أخرى من التعقيد. فقد تُشغَّل دالة Azure بطلب HTTP، أو بطابور، أو بمؤقت، أو بتدفق أحداث، أو بربط يخفي تفاصيل التوصيل الخاصة بالمزوّد. أما Lambda فلها مصادر أحداثها، وأنماط الاستدعاء، وضوابط التزامن، وحدود المهلة، وحزم النشر، والأذونات، ونموذج المراقبة الخاص بها. وإذا كان التطبيق الأصلي يفترض عملية طويلة العمر، أو استمرار البيانات في نظام الملفات المحلي، أو نمط تهيئة مسبقة معين، أو شكلاً لطلب يُنشئه الربط، فستحتاج عملية التنفيذ المستهدفة إلى عمل تصميمي يتجاوز ترجمة حزم SDK.

 والنتيجة العملية بسيطة: نجاح التجميع إشارة مبكرة، وليس معيار قبول للترحيل.

 ## القراءة الصحيحة لتقرير التقييم

 تُعدّ آلية عمل AWS Transform مفيدة لأنها تضع قرارات التحويل قبل تنفيذ التحويل نفسه. وهذا يتيح للفريق نقطة يراجع فيها الهدف المقترح، بدلاً من اكتشاف كل قرار بعد إنشاء الشيفرة.

 استخدموا هذا التقرير بوصفه جرداً للتبعيات، مرفقاً بآراء وتقييمات.

 ابدؤوا بفصل ثلاث فئات:

 1. **الاستدعاءات المدعومة مباشرةً.** هذه مراجع SDK التي تقول الأداة إنها تستطيع تحويلها. وهي مرشحة للتحويل الآلي، لكنها لا تمثل مخرجات صحيحة تلقائياً.
2. **تبعيات المزوّد المجاورة.** تشمل هذه الهوية، والإعدادات، والشبكات، والنشر، والتسجيل، والتتبّع، والأسرار، وربط الأحداث، وتعريفات البنية التحتية. وقد تكون ظاهرة في المستودع نفسه، لكنها لا تغطيها تعيينات الخدمات المدرجة.
3. **سلوك الأعمال.** يشمل ذلك قابلية التنفيذ مرة واحدة، والترتيب، والاحتفاظ، ومقصد التفويض، والتحقق من البيانات، وإجراءات الاسترداد، ومعالجة الأخطاء الظاهرة للمستخدم. ولا يمكن استنتاجه بأمان من تعيين خدمة إلى خدمة على أساس واحد إلى واحد.

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

 ومن المستندات المفيدة للمراجعة جدول يضم صفاً لكل تبعية خاصة بالمزوّد:

<table>
<thead>
<tr>
<th>التبعية</th>
<th>سلوك المصدر</th>
<th>الهدف المقترح</th>
<th>السلوك المطلوب إثباته</th>
<th>المسؤول</th>
</tr>
</thead>
<tbody>
<tr>
<td>تحميل كائن ثنائي</td>
<td>الكتابة فوق البيانات، والبيانات الوصفية، والاحتفاظ</td>
<td>عملية S3</td>
<td>سلوك الاتساق والسياسات</td>
<td>فريق التخزين</td>
</tr>
<tr>
<td>استقبال رسالة من الطابور</td>
<td>قواعد إعادة المحاولة والرؤية</td>
<td>تدفق استقبال SQS</td>
<td>معالجة الرسائل المكررة والرسائل السامة</td>
<td>فريق الخدمة</td>
</tr>
<tr>
<td>مُشغّل الدالة</td>
<td>شكل الحدث والمهلة</td>
<td>استدعاء Lambda</td>
<td>المهلة، والتزامن، وإعادة المحاولات</td>
<td>فريق المنصة</td>
</tr>
<tr>
<td>الهوية</td>
<td>الهوية المُدارة والنطاقات</td>
<td>دور IAM والسياسات</td>
<td>أقل قدر من الامتيازات والتدوير</td>
<td>فريق الأمن</td>
</tr>
</tbody>
</table>

 ليس الهدف من ذلك البيروقراطية، بل منع فروق الشيفرة المُنشأة من التحول إلى وثيقة العمارة الفعلية بحكم الأمر الواقع.

 ## ما الذي تؤديه الميزة جيداً

 توجد مكاسِب حقيقية في الكفاءة عندما يستخدم التطبيق حزم Azure SDK المدعومة ضمن شيفرة .NET تقليدية. تستطيع الأداة العثور على مراجع الخدمات، وتقديم خطة للتحديث، وإعادة كتابة الأنماط المعروفة على نطاق كان سيستهلك وقتاً من المطورين لولا ذلك. كما يمكنها ترك علامات واضحة حيث يتعذر التحويل، بما في ذلك تعليقات TODO، أو القوالب الأولية، أو مستند للخطوات التالية، وفقاً لتوثيق AWS.

 وهذا مفيد في ثلاث حالات.

 الأولى هي تقييم المحفظة. إذ تستطيع مؤسسة لديها كثير من خدمات .NET استخدام التحليل لاكتشاف مدى ارتباط كل تطبيق بـ Azure. ويمكن للنتيجة تحسين ترتيب التنفيذ حتى عندما لا تكون الخدمة جاهزة للترحيل.

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

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

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

 ## مشكلة الهوية أكبر من مجرد تغيير مُنشئ العميل

 غالبًا ما تفشل عمليات الترحيل بين المزوّدين عند الحد الفاصل بين كود التطبيق والتفويض. تستخدم تطبيقات Azure عادةً الهويات المُدارة وتعيينات الأدوار. أما تطبيقات AWS فتستخدم أدوار وسياسات IAM، مع إسناد الأذونات إلى أدوار التنفيذ، أو أدوار المهام، أو ملفات تعريف المثيلات، أو هويات أخرى، بحسب بيئة التشغيل.

 لا يملك استدعاء SDK المُحوَّل أي صلاحية بحد ذاته. يجب أن يوفّر النشر المستهدف هويةً تستطيع تنفيذ الإجراءات المطلوبة بدقة على الموارد المطلوبة تحديدًا. وهذا يعني مواءمة ما هو أبعد من تحويل «يمكنه قراءة الكائن الثنائي» إلى «يمكنه قراءة الكائن»؛ إذ يجب أيضًا تحديد نطاق الوصول، وشروطه، وأسماء الموارد، ومفاتيح التشفير، ومسار الشبكة، والجهة المالكة تشغيليًا لذلك الوصول.

 ينبغي أن تجيب مراجعة الترحيل عن الأسئلة التالية:

 - ما الهوية التي تنفّذ كل وظيفة وعامل ومهمة نشر؟
- ما سياسات الموارد وسياسات الهوية التي تمنح الاستدعاء صلاحيةً مجتمعة؟
- هل يستخدم الهدف مفاتيح تشفير مُدارة من العميل، ومن يملك صلاحية استخدامها؟
- هل يستطيع الحمل الوصول إلى الخدمة عبر مسار الشبكة المقصود؟
- هل بيانات الاعتماد قصيرة الأجل وتُدوَّر من دون تغييرات في التطبيق؟
- ما الذي يُسجَّل عند فشل فحص التفويض؟

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

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

 ## يظل نقل البيانات ودلالاتها عملًا بشريًا

 لا ينقل AWS Transform البيانات الموجودة خلف Azure Blob Storage أو Azure Queue Storage أو Cosmos DB. قد يبدو ذلك بديهيًا، لكنه يغيّر الجدول الزمني للمشروع. ولا يمكن أن يسير تحويل الكود وترحيل البيانات بالتوازي إلا بعد أن يحدد الفريق كيفية تعايش الإصدارين.

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

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

 وبالنسبة إلى قواعد البيانات، فإن حالة المعاينة لتحويل Cosmos DB إلى DynamoDB إشارة إلى ضرورة توخي حذر شديد. فكثيرًا ما تختلف أنظمة NoSQL في التقسيم، والفهرسة، والاتساق، ونطاق المعاملات، ولغة الاستعلام، وحدود العناصر، وسلوك موجز التغييرات. ولا تثبت طبقة الوصول إلى البيانات بعد تحويلها أن نموذج البيانات المستهدف سيتوسع أو سيعيد النتائج نفسها. ينبغي للفرق نمذجة أنماط وصول ممثلة وتشغيل فحوص جودة البيانات قبل الالتزام بتحويل مباشر في بيئة حية.

 ينبغي أن تحدد خطة الترحيل مصدر الحقيقة في كل مرحلة. فعبارة «البيانات موجودة في السحابَتين» ليست استراتيجية اتساق.

 ## ينبغي للاختبارات مقارنة العقود، لا المخرجات فحسب

 قد تتحقق مجموعة اختبارات الوحدات التقليدية من أن الكود المُحوَّل يعيد القيم المتوقعة من عملاء وهميين. وهذا ضروري، لكنه غير كافٍ، لأن النماذج الوهمية عادةً ما تحافظ على التجريد الذي صممه المزوّد الأصلي.

 وتتضمن خطة الاختبار الأقوى عدة طبقات.

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

 تُشغّل **الاختبارات التفاضلية** أحمال عمل متكافئة مقابل تطبيقي المصدر والهدف، ثم تقارن النتائج على مستوى الأعمال. ولا ينبغي أن تتطلب المقارنة تطابق أخطاء المزوّد أو معرّفات الطلبات حرفياً، بل عليها التحقق مما يعتمد عليه المستخدمون والخدمات التابعة والمشغّلون.

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

 تتحقق **الاختبارات التشغيلية** من السجلات، والمقاييس، وآثار التتبع، والتنبيهات، ولوحات المعلومات، وأدلة التشغيل. فالخدمة المُرحّلة التي تعمل، لكن يتعذر تشخيصها، ليست مستعدة للإنتاج.

 تؤكد **اختبارات الأمان** سياسات أقلّ الصلاحيات، وتتحقق من أن حمل العمل لا يستطيع قراءة الموارد أو الكتابة إليها أو استدعاءها خارج حدوده المقصودة.

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

 ## تسلسل أكثر أماناً للترحيل

 يمكن للفريق الذي يقيّم الإمكانية الجديدة تقليل المخاطر عبر تضييق نطاق المشروع الأول.

 اختر خدمة لها مالك واضح، وعدد محدود من تبعيات المزوّد المدعومة، وآلية تراجع قابلة للاختبار. وتجنب البدء بالنظام الذي يجمع بين اتحاد الهوية، وتوزيع الأحداث على عدة وجهات، والبيانات الخاضعة للتنظيم، وإجراءات التشغيل غير الموثقة.

 قبل تشغيل التحويل، أنشئ خريطة لتبعيات المصدر. أدرج حزم SDK، ومتغيرات البيئة، والروابط، وبيانات نشر البنية التحتية، والأسرار، ونقاط نهاية الشبكة، ومخازن البيانات، وقوائم الانتظار، والمشغلات المجدولة، وتكاملات المراقبة.

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

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

 أنشئ البنية التحتية المستهدفة بشكل منفصل. استخدم أدوار IAM محددة النطاق، وموارد مشفرة، واتصالاً خاصاً عند الحاجة، وتسجيل الأحداث، والتنبيهات، والنسخ الاحتياطية، وضوابط النشر. ولا تستخدم شفرة التطبيق المُولّدة بديلاً عن مراجعة البنية التحتية.

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

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

 ## سؤال الحوكمة لفرق المنصات

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

 ينبغي لفرق المنصات وضع بوابة مراجعة معيارية لعمليات الترحيل المُولّدة. ويجب أن تتطلب:

 - جرد كامل لتبعيات المزوّد التي جرى تحويلها وتلك التي لم تُحوَّل؛
- بنية مستهدفة ونموذج هوية معتمدان؛
- خطة لترحيل البيانات والتراجع؛
- اختبارات للمعاني الخاصة بالمزوّد وسلوك التعامل مع حالات الفشل؛
- أدلة على أن قابلية الرصد والاستجابة للحوادث تعملان في البيئة المستهدفة؛
- مالك بشري محدد لكل عنصر TODO أو دالة بديلة لم يُحسم أمرها؛
- قرار موثّق بشأن أي تعيين افتراضي جرى تغييره.

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

 السياسة الأساسية هي إبقاء الشيفرة المُولَّدة قابلة للمراجعة. خزّن تقرير التقييم، وخطة التحديث، والفروقات الناتجة عن التحويل، وأدلة الاختبار، والاستثناءات مع سجل تغييرات الخدمة. وإذا أُعيد تشغيل التحويل لاحقًا، ينبغي أن يتمكن الفريق من شرح ما الذي تغيّر ولماذا.

 ## ما ينبغي مراقبته لاحقًا

 يغطي الإعلان الحالي مجموعة مركّزة من عمليات التعيين بين Azure وAWS، مع إبقاء التحويل من Cosmos DB إلى DynamoDB في مرحلة المعاينة. وهذا يوحي بأن AWS تبدأ بنقاط ترجمة شائعة وواضحة، بدل الادعاء بإمكانية نقل عامة بين المنصات.

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

 في الوقت الحالي، تتمثل النصيحة العملية في استخدام AWS Transform حيث يكون أقوى: جرد التبعيات وتسريع تغييرات الشيفرة المتكررة. أما البنية، والبيانات، والهوية، وقبول التشغيل في بيئة الإنتاج، فينبغي أن تبقى خاضعة لمراجعة بشرية صريحة. يمكن للميزة أن تُظهر فرع ترحيل بسرعة، لكنها لا تستطيع أن تجعل السحابتين تتشاركان العقود نفسها.

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