Software Development - RushKar

A business application can remain useful long after the technology it was built with starts showing its age. A PHP-based ERP, customer portal or order management system may still handle daily operations, but maintaining it can become harder when the runtime is outdated, dependencies are no longer supported or changes to one feature keep affecting another.

PHP2Shell has brought renewed attention to the security of PHP environments. On October 21, 2026, the PHP team published two critical vulnerabilities that can allow unauthenticated remote code execution in affected deployments. Fixed releases are available, and the official advisory states that updating is the only safe option. Businesses running potentially affected versions should check the official PHP security advisory and confirm their patch status.

The security update is the immediate priority. Replacing the application is a different decision.

For a business with a maintained PHP application, applying the fix and continuing with the existing system may be entirely reasonable. The situation changes when the application also relies on unsupported libraries, contains years of accumulated workarounds or requires extensive manual testing whenever a developer makes a change.

At that point, the business has a broader question to answer. Is the existing application worth maintaining, would an upgrade or refactoring solve the problem, or is a move to .NET justified?

The answer depends on the software the business already has, the problems it needs to solve and the cost of keeping the application operational. PHP2Shell is a reason to check the environment. It is not a reason to assume that every PHP application needs a rewrite.

02. What PHP2Shell Means for Existing Applications

PHP2Shell refers to CVE-2026-109618 and CVE-2026-109619. Both vulnerabilities affect PHP's internal runtime behaviour and can allow remote code execution without authentication in affected environments.

The underlying issues involve memory handling and the state of internal request data. One vulnerability concerns an out-of-memory condition that can leave request data partially initialized. The other involves stale internal state after memory has been freed. These are runtime-level flaws, so updating a website's theme, plugin or application framework does not necessarily fix them.

The PHP advisory identifies several potentially affected web-serving configurations, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The actual exposure depends on the deployed environment. The advisory identifies mod_php as the highest-risk configuration among those discussed.

The fixed releases listed in the October 21, 2026 advisory are:

These version numbers should be checked against the latest official advisory before publication or deployment. Businesses running older PHP branches should confirm whether their hosting provider or software vendor supplies a supported security fix. Some vendors backport patches, so the installed version number alone may not establish whether the relevant fix is present.

The production environment needs to be checked directly. A developer's local setup may use a newer PHP release than the live server, and background workers or containers may have separate runtime configurations.

If the environment is affected, apply the appropriate fix through the supported deployment process. Test the application after the update and investigate signs of possible compromise if the system was exposed. An update addresses the known runtime vulnerability, but it cannot establish whether an attacker accessed the environment before the fix was applied.

03. What to Check Before Deciding on Migration

Once the immediate security issue is addressed, the business can assess the condition of its PHP application. The first question is whether the existing system can still be maintained without disproportionate effort.

Take an order management application used by a distributor. It handles customer accounts, negotiated prices, stock allocation, order approvals, invoices and accounting exports. The application may have been extended by several development teams over the years, with different parts of the workflow implemented in different ways.

A change to customer pricing might affect order entry, invoice calculations and reports. If the rules are duplicated across the codebase, a developer must locate each implementation and check that the results remain consistent. If the application has limited automated testing, much of that verification may have to be done manually.

The application is still working, but every change carries more uncertainty than it should.

Before choosing a modernization approach, review the following areas:

• PHP runtime and dependencies: Check whether the deployed version is supported and whether its framework, libraries and packages can be maintained.
• Business logic: Identify where pricing, approval, permissions and other business rules are implemented, including rules stored in database procedures or scheduled jobs.
• Database structure: Review the relationships, constraints, historical records and reporting requirements that the application depends on.
• External integrations: Establish which accounting, payment, CRM or internal systems rely on existing APIs and data formats.
• Testing and deployment: Determine whether the team can verify important workflows and release changes without relying entirely on manual checks.
• Future requirements: Identify the changes the business expects to make and whether the current architecture can support them.

The findings help establish whether the problem is limited to the PHP runtime or extends into the application itself. Those situations require different responses.

04. Upgrade PHP, Refactor the Code or Migrate to .NET?

A runtime upgrade, a refactoring project and a migration are not interchangeable. Each changes a different part of the system, and the right choice depends on what is preventing the application from being maintained or extended.

PHP Upgrade

A PHP upgrade moves the application to a supported runtime while retaining its existing architecture. The work may involve updating dependencies, replacing incompatible libraries, addressing deprecated functionality and adjusting configuration.

For example, a customer portal may have a stable database, a maintained framework and clearly separated business rules but still run on an outdated PHP release. If the dependencies support a newer version and the application passes regression testing, an upgrade may be all the business needs.

There is little reason to rebuild working functionality simply because the runtime needs updating. However, a PHP upgrade does not automatically correct duplicated code, weak access controls or architectural problems elsewhere in the application.

PHP Application Refactoring

Refactoring changes how the existing application is organized without intentionally changing its business behaviour. It may involve separating business logic from presentation code, removing duplicated calculations, improving database access or replacing unsupported dependencies.

In the distributor's order management system, pricing rules may be repeated across order entry and invoice generation. Refactoring can bring those rules into a defined component and introduce tests for customer agreements, discounts and invoice totals. The business keeps its PHP application while making that part of the system easier to maintain.

The work requires an accurate understanding of the existing behaviour. If developers cannot establish how a pricing exception or approval rule currently works, restructuring the code without first validating that rule can introduce defects.

PHP-to-.NET Migration

A PHP-to-.NET migration replaces some or all of the existing application with a solution built on .NET. Depending on the scope, this can involve rebuilding the user interface, transferring business logic, changing database access, replacing integrations and migrating existing records.

Migration becomes worth considering when the current architecture repeatedly obstructs development, important dependencies cannot be maintained or the business has a clear reason to move its application services to .NET.

The objective should be to address those limitations, not to reproduce the old application line by line in C#. If duplicated rules and tightly coupled components are carried into the replacement, the business may end up with the same maintenance problems in a different language.

05. Which Approach Fits Your Application?

The expected life of the application also matters. A system scheduled for retirement in six months has a different investment case from one expected to support the business for another five years. In the latter case, the cost of repeated workarounds and difficult releases may justify a larger modernization project.

06. When Moving to .NET Is Not the Answer

Migration is not automatically the best response to a legacy application. If the current PHP system is supported, secure, reasonably easy to maintain and capable of meeting the business's requirements, replacing it may add cost without solving a meaningful problem.

A migration can also be premature when the business has not documented its existing processes. An application may contain customer-specific pricing, approval exceptions, reporting calculations and integration rules that are not obvious from the screens users see. Rebuilding the visible features without accounting for those rules can leave the new system unable to handle normal business operations.

Security needs the same distinction. A move to .NET does not automatically remove weak authentication, excessive permissions, unsafe data handling or poor deployment practices. Those issues need to be addressed as part of the design and implementation, regardless of the language.

Before approving a migration, the business should be able to identify the limitations it intends to remove and explain why an upgrade or targeted refactoring would not adequately address them. If that case has not been established, a technical assessment is a better starting point than a full rewrite.

07. What Needs to Be Included in a PHP-to-.NET Migration?

Moving the source code is only one part of the work. The replacement also needs to preserve the business rules, data relationships and integrations that allow the application to operate.

Business Rules and Existing Workflows

The team needs to identify how the current system processes real business transactions. In an order management application, that includes customer pricing, stock allocation, approval thresholds, tax calculations, invoice creation and accounting synchronization.

Some rules may sit in PHP classes, while others may be implemented in database procedures or scheduled jobs. The migration scope should account for all of them, including exceptions that are rarely used but remain important to the business.

Database and Historical Data

The existing database may be retained, adapted or replaced, depending on the target architecture. The decision requires a review of table relationships, constraints, stored procedures, indexes, historical records and reporting dependencies.

Data migration needs to be validated against business outcomes, not just record counts. For the distributor, the team should check whether order totals, taxes, invoice references, payment records and customer balances remain consistent after the transfer. Reconciliation rules should identify discrepancies before the new system becomes the primary source of data.

APIs and Third-Party Integrations

An application may exchange information with accounting software, payment providers, CRM platforms, shipping services or internal reporting systems. These connections often rely on specific API contracts, authentication methods, field names or response formats.

The migration plan should identify each integration and test how it behaves when requests succeed, fail or time out. Where an external system cannot be updated alongside the application, the team may need a compatibility layer or a versioned API to avoid disrupting existing operations.

Testing and Cutover

Testing should cover complete workflows rather than isolated screens. An order should be traceable from creation through approval and stock allocation to invoice generation and accounting synchronization.

The cutover plan must also establish when the new system becomes authoritative, how transactions created during the transition will be handled and what conditions would trigger a rollback. For applications that cannot tolerate a long outage, the team may need a staged deployment or a carefully controlled transition between the old and new systems.

These requirements affect both the project scope and its cost. The number of pages in a PHP application is not a reliable measure of migration effort when the underlying business rules and integrations are complex.

08. Full Migration or Phased Replacement?

A full migration replaces the application through a planned release. It may suit a contained system when its requirements are understood, the data transfer is manageable and the business can accommodate a controlled cutover.

A phased migration replaces selected functions while the remaining PHP application continues to operate. For example, a business might move a reporting service or a clearly separated workflow to .NET before replacing the rest of the system.

The important requirement is a clear boundary between the old and new components. The team must know which system owns each record, how data changes are shared and what happens when an integration fails. If the application relies heavily on shared code and database behaviour, separating its functions may require substantial work before a phased approach becomes practical.

A full replacement carries its own risks. If too many critical workflows change at once, problems in data handling or business logic may affect a large part of the operation. A phased approach can limit the scope of each release, but keeping two implementations running can add cost and maintenance work.

The choice should follow the application's structure, integration dependencies and operational requirements. Neither approach should be treated as a guaranteed shortcut.

09. Should You Choose .NET or Another Technology?

.NET is worth considering when the business needs a C# application layer, already operates Microsoft-based systems or wants a defined foundation for its web applications and APIs. ASP.NET Core supports web application and API development, but the target architecture still needs to fit the workload, data model and operational environment.

MERN, which combines MongoDB, Express.js, React and Node.js, may suit some applications. It is not a universal replacement for PHP or a default alternative to .NET. A system that relies on relational data, transaction integrity and established reporting needs careful consideration of how those requirements will be handled in the new architecture.

The technology decision should account for the application's integration requirements, hosting environment, developer expertise and long-term maintenance. A new stack is useful only if it addresses a real business or engineering need.

Businesses considering a move to .NET can review Rushkar's ASP.NET development services, which include PHP framework migration.

10. Related Reading: Modernizing an Existing Application Without Replacing Everything

Not every legacy application needs to be rebuilt from the ground up. Sometimes the problem lies in a specific architectural weakness that can be corrected while the rest of the system remains in place.

Rushkar's related case study, How Rushkar Isolated Patient and Encounter Context Across Browser Tabs in a Legacy EHR, examines a different type of legacy application problem. It provides a relevant example for readers considering whether a targeted architectural change may be more appropriate than replacing an entire system.

The circumstances differ from a PHP runtime vulnerability, but the engineering question is related: identify the problem that needs to be solved, understand what depends on the existing behaviour and choose a change that addresses the issue without creating unnecessary replacement work.

11. Frequently Asked Questions

Does PHP2Shell mean every PHP application is vulnerable?

No. The advisory identifies specific vulnerabilities affecting relevant PHP runtime environments. Businesses need to check their deployed version, configuration and vendor patch status before determining their exposure.

Can updating a PHP framework fix PHP2Shell?

Updating a framework does not necessarily update the PHP runtime. The production runtime must be checked and patched according to the official advisory and the guidance applicable to the hosting environment.

When should a business migrate from PHP to .NET?

Migration is worth evaluating when the existing architecture restricts necessary development, critical dependencies cannot be maintained or the business has a clear long-term reason to adopt .NET. The decision should follow an assessment of the existing system and the alternatives.

Can a PHP application retain its existing database after migration?

Yes, if the database structure and access patterns remain suitable for the new application. A redesign may be necessary in some cases, but it adds data transformation, compatibility and validation work.

Does migrating to .NET make an application more secure?

Not by itself. Security depends on the application's design, code, dependencies, permissions, configuration, deployment and ongoing maintenance. Migration provides an opportunity to improve these areas, but the new application must implement and verify the necessary controls.

How is PHP-to-.NET migration cost estimated?

The estimate depends on the application architecture, business rules, database, integrations, testing requirements, data migration and deployment constraints. A technical assessment is needed to establish the scope. Counting pages or source files alone does not provide a reliable estimate.

12. Planning Your Next Step

PHP2Shell requires businesses running affected environments to address the security issue promptly. Whether the application should remain on PHP is a separate decision that depends on its condition and the business's future requirements.

If the existing system is maintainable, an upgrade may be enough. If specific parts of the code have become difficult to change, refactoring may be more appropriate. If the architecture or support requirements no longer fit the business, a move to .NET may be justified.

Rushkar Technologies provides .NET development and application migration services for businesses evaluating these options. The starting point is to understand the existing application, its business workflows and the technical constraints that need to be addressed.

Considering a PHP-to-.NET migration?

Review Rushkar's ASP.NET development services to explore the migration approach for your existing application.