الإجابة المختصرة: دفعت ثغرات PHP2Shell (CVE-2026-109618 وCVE-2026-109619) كثيرًا من المؤسسات إلى إعادة تقييم أنظمة PHP القديمة لديها. نعيد بناء تطبيقات PHP غير القابلة للتحديث أو غير الموثقة أو صعبة الصيانة على ASP.NET Core، وننقل البيانات دون فقدان، ونحافظ على بنية الروابط لانتقال سلس. وإذا كان لديكم نظام PHP حديث وسليم فنوصي أولًا بـ ترقية إصدار PHP؛ ونتخذ القرار الصحيح معكم بناءً على تحليل مسبق مجاني.
متى يكون الانتقال إلى.NET قرارًا صحيحًا؟
- عندما يعمل التطبيق على PHP 5.x أو 7.x دون إطار عمل أو بإطار قديم جدًا، وتتطلب الترقية جهدًا يقارب إعادة الكتابة.
- عندما تعمل مؤسستكم على Azure وActive Directory / Entra ID وSQL Server وMicrosoft 365 وترغب في التوحيد على منظومة تقنية واحدة.
- عندما تعملون في قطاع شديد التنظيم مثل البنوك والتأمين والصحة والقطاع الحكومي وتحتاجون إلى دعم طويل الأمد (LTS) ومنصة صارمة الأنواع.
- عندما يتقن فريقكم الداخلي C# بينما تتراجع خبرة PHP وترتفع تكلفة الصيانة كل عام.
متى لا ينبغي الانتقال؟
لا داعي لنقل موقع WordPress أو WooCommerce أو Laravel حديث إلى منصة أخرى بسبب PHP2Shell وحدها؛ فالتحديث وترقية الإصدار يغلقان الثغرة. وفي هذه الأنظمة يكون البقاء على PHP غالبًا الخيار الأفضل من حيث إدارة المحتوى ومنظومة الإضافات والتكلفة. ونعرض هذه المقارنة في التحليل المسبق مع تقديرات المدة والميزانية.
مراحل الانتقال
- الاستكشاف: حصر الوحدات وقواعد العمل والتكاملات وأدوار المستخدمين ومخطط قاعدة البيانات، وتوثيق قواعد العمل غير المكتوبة من خلال مراجعة الشيفرة.
- البنية: تصميم ASP.NET Core (MVC / Razor Pages أو Web API مع واجهة حديثة) وEntity Framework Core وإدارة الهوية والسجلات والمراقبة.
- التطوير وحدة تلو الأخرى: نبدأ بأهم مسار عمل، ويمكن تشغيل النظامين القديم والجديد جنبًا إلى جنب لفترة (نهج strangler).
- نقل البيانات: عمليات نقل تجريبية ومطابقة أعداد السجلات والمبالغ وإعادة بناء تخزين كلمات المرور بطريقة آمنة.
- تحسين محركات البحث والحفاظ على الروابط: الإبقاء على بنية الروابط أو إعداد خريطة تحويلات 301 ومتابعة Search Console.
- الإطلاق والدعم: انتقال مع خطة تراجع، يليه عقد صيانة ودعم.
مقارنة الخيارات
| الخيار | متى يناسب | المدة | المخاطر |
|---|---|---|---|
| تحديث PHP مع ترقية الإصدار | WordPress / Laravel حديث وشيفرة سليمة | أيام إلى أسابيع | منخفضة |
| إعادة الكتابة على Laravel حديث | PHP قديم والفريق يتقن PHP | أسابيع إلى أشهر | متوسطة |
| إعادة الكتابة على ASP.NET Core | منظومة Microsoft والحاجة إلى دعم مؤسسي طويل | أسابيع إلى أشهر | متوسطة |
| Node.js / منظومة JavaScript حديثة | منتجات فورية أو قائمة على واجهات API | أسابيع إلى أشهر | متوسطة |
المقابل التقني بين المنصتين
| في PHP | في.NET |
|---|---|
| Laravel / توجيه خاص | توجيه ASP.NET Core أو MVC أو Minimal APIs |
| Eloquent / PDO | Entity Framework Core أو Dapper |
| الجلسات وتسجيل الدخول الخاص | ASP.NET Core Identity أو Entra ID أو OpenID Connect |
| مهام Cron | Hosted Services أو Hangfire أو Azure Functions |
| قوالب Blade / PHP | Razor Pages أو Blazor أو واجهة React / Angular منفصلة |
| حزم Composer | حزم NuGet |
أمان مدمج في المنصة الجديدة
الانتقال فرصة لإزالة نقاط الضعف التي جعلت حماية النظام القديم صعبة. في ASP.NET Core نعتمد الوصول المُعلَّم إلى البيانات عبر Entity Framework Core، والحماية المدمجة من تزوير الطلبات عبر المواقع، وخوارزميات تجزئة حديثة لكلمات المرور، وسجلات مركزية، وفحص الاعتماديات في خط CI/CD. وتتلقى إصدارات.NET طويلة الدعم تحديثات أمنية منتظمة من Microsoft وفق جدول معلن، فيصبح التحديث عملًا روتينيًا لا حالة طوارئ.
سيناريو توضيحي: بوابة موزعين قديمة
سيناريو توضيحي، وليس مرجعًا لعميل. شركة توزيع تدير بوابة طلبات للموزعين كُتبت قبل أكثر من عشر سنوات بلغة PHP 7.2 دون إطار عمل. غادر المطورون الأصليون، ولا يوجد توثيق، ولا يستطيع مزوّد الاستضافة تقديم سوى تحديثه الخاص لثغرة PHP2Shell، بينما تستخدم الشركة Entra ID وSQL Server بالفعل. في حالة كهذه نبدأ بحماية البوابة القديمة بإجراءات مؤقتة، ونوثّق قواعد الطلب والتسعير من الشيفرة، ثم نعيد بناء البوابة على ASP.NET Core وحدة تلو الأخرى: الدخول وحسابات الموزعين أولًا، ثم الكتالوج والطلبات، ثم التقارير. وتُطابق بيانات MySQL في عمليات تجريبية قبل الانتقال النهائي، وتُحوّل الروابط القديمة بتحويلات 301.
الفريق ونماذج التعاقد
- مشروع انتقال بنطاق محدد: التحليل والتطوير ونقل البيانات والإطلاق يتولاها فريقنا.
- فريق مخصص: مطورو.NET ومهندس جودة وقائد تقني يعملون مع مالك المنتج لديكم؛ ونتوسع من شخص واحد إلى أكثر من 200 شخص.
- تعزيز الفريق: مطورو.NET أو مطورو PHP ينضمون إلى فريقكم عن بُعد أو في الموقع أو بنظام هجين.
تبدأ الفرق عادة خلال أسبوع إلى أسبوعين، وإذا لزم استبدال أحد أعضاء الفريق نطبّق آلية استبدال منظمة مع تسليم واضح.
قائمة تحقق قبل اتخاذ القرار
- ما قواعد العمل الموجودة في الشيفرة فقط وغير الموثقة في أي مكان؟
- ما التكاملات (ERP وCRM والدفع والجهات الحكومية) التي يجب أن تعمل من اليوم الأول؟
- ما أجزاء النظام قليلة الاستخدام التي يمكن الاستغناء عنها بدل نقلها؟
- من سيصون النظام الجديد: فريقكم أم نحن أم الطرفان معًا؟
- ما حجم الزيارات العضوية، وما الروابط التي يجب الحفاظ عليها؟
- ما التزامات حماية البيانات والاحتفاظ بها التي تنطبق على البيانات المنقولة؟
نجيب عن هذه الأسئلة في التحليل المسبق المجاني بالتعاون مع الإدارات المعنية لديكم، وتكون النتيجة توصية واضحة تتضمن الخيارات والمخاطر والأطر الزمنية التقريبية، لتتخذوا القرار داخليًا على أساس متين.
مؤشرات الأداء أثناء الانتقال
| المؤشر | ما يوضحه |
|---|---|
| الوحدات المنقولة | التقدم مقارنة بخطة الوحدات المتفق عليها |
| مطابقة البيانات | تطابق أعداد السجلات والمجاميع بين النظامين القديم والجديد |
| اتجاه الأخطاء | الأخطاء المفتوحة حسب الخطورة قبل كل إصدار |
| استمرارية محركات البحث | الروابط المفهرسة وأخطاء التحويل والزيارات العضوية بعد الإطلاق |
ما الذي يحدد التكلفة والمدة (دون أسعار ثابتة)
- عدد الوحدات وقواعد العمل
- التكاملات مع أنظمة ERP وCRM والدفع والأنظمة الحكومية
- حجم البيانات وجودتها
- الحاجة إلى تشغيل النظامين بالتوازي
- نطاق الواجهة: التصميم نفسه أو إعادة تصميم
- البيئة المستهدفة: Azure أو سحابة أخرى أو خوادم داخلية
العقد والملكية الفكرية وحماية البيانات
الشيفرة المصدرية والتصميم وجميع الحسابات ملك لكم، ونقل الملكية الفكرية جزء من عقد الخدمات بين الشركات. تُوقّع اتفاقية عدم الإفصاح قبل أول اجتماع. وعند نقل بيانات شخصية نلتزم بأنظمة حماية البيانات الشخصية المعمول بها في السعودية والإمارات وقطر بحسب الحالة، وتخضع معالجتنا في تركيا لقانون KVKK. للمشكلات الأمنية العاجلة راجعوا إصلاح ثغرات PHP الأمنية، وللجرد على مستوى المجموعة التدقيق الأمني لـ PHP للشركات.
الأسئلة الشائعة
هل من المنطقي تحويل موقع PHP لدي إلى.NET؟
ليس لكل نظام PHP. فبالنسبة لموقع Laravel أو WordPress حديث تكون ترقية الإصدار غالبًا أسرع وأوفر. أما إذا كان لديكم تطبيق PHP قديم وغير موثق وغير قابل للتحديث وحرج للأعمال، أو كانت مؤسستكم تعمل في منظومة Microsoft، أو تريدون دعمًا مؤسسيًا طويل الأمد، فالانتقال إلى.NET خيار قوي.
ماذا سيحدث لقاعدة البيانات؟
يمكن الإبقاء على قاعدة بيانات MySQL أو MariaDB لأن Entity Framework Core يعمل معهما، ويمكن أيضًا التخطيط للانتقال إلى SQL Server أو PostgreSQL. يتم نقل البيانات مع أعداد مطابقة وعمليات تجريبية.
هل سيتوقف الموقع أثناء الانتقال؟
لا. يُطوّر النظام الجديد بالتوازي ويُختبر في بيئة اختبار ويُفعّل وحدة تلو الأخرى. تبقى بنية الروابط كما هي مع تحويلات 301 عند الحاجة، فلا تُفقد زيارات محركات البحث.
كم يستغرق الانتقال وكم يكلف؟
تعتمد المدة والتكلفة على عدد الوحدات والتكاملات وحجم البيانات. يُنقل موقع الشركة خلال أسابيع قليلة، بينما تستغرق البوابة متعددة الوحدات أو التطبيق الشبيه بأنظمة ERP بضعة أشهر. وبعد التحليل المسبق المجاني نقدم المدة والسعر بندًا بندًا.
ماذا عن خطر PHP2Shell أثناء انتظار الانتقال؟
عند بدء المشروع نطبّق تحديثًا أو إجراءً مؤقتًا على نظام PHP القديم، ويبقى محميًا حتى يجهز النظام الجديد.
هل يستطيع فريقنا تولي النظام الجديد؟
نعم. نوثّق البنية ونسلّم المستودعات وخطوط النشر، ويمكننا تنفيذ دورات عمل مشتركة حتى يصبح فريقكم جاهزًا لصيانة الشيفرة.
هل تعملون مع شركات في الخليج؟
نعم. نعمل عن بُعد مع فارق توقيت صفري مع الرياض والدوحة وساعة واحدة مع دبي، ويمكن تقديم دعم ميداني عند الحاجة.
لمن تعود ملكية الشيفرة؟
لكم. الشيفرة المصدرية وملفات التصميم والتوثيق وجميع حسابات السحابة والمستودعات ملك لكم.
اطلبوا تحليل الانتقال
أرسلوا إلينا عنوان موقعكم والمنصة ونوع الاستضافة. اتصلوا على +90 850 335 10 87 أو عبر واتساب أو البريد info@360-soft.com أو من صفحة التواصل. جميع الخدمات: خدمات التعهيد.
