Updating Business Software: Why It Matters and When to Plan It

Updating business software keeps its technical foundation compatible, maintainable and able to receive necessary security fixes. The work can involve the runtime, framework, libraries, platform and application code. Timing depends on version support, identified risks and development plans. A working interface alone does not reveal the condition of all these components or whether they can support the business's next changes.

“The system works. Why should we invest in an update?”

It is a reasonable question. If orders are coming in, employees can access the administration area and customers are not complaining, a technical upgrade can struggle to become a priority. Especially when the screens may look almost identical afterwards.

The value lies in the system's ability to keep serving the business: receiving necessary fixes, working with external services and supporting the next changes. That is part of what technical maintenance delivers.

What actually gets updated in a business system?

A business system has several technical layers that are maintained separately but depend on one another. Updating one layer does not automatically bring the others up to date.

“We updated the server” and “we updated the application” therefore describe different scopes. Before commissioning work, establish which components will change and who is responsible for each.

Why might working software need an update?

Software can perform its current tasks while relying on components whose support has ended or which restrict future development. Normal day-to-day operation does not check every technical risk.

Vendors set support periods for their releases. Standard fixes may stop when those periods end. For example, PHP publishes separate periods for active support and security fixes, while Node.js recommends supported LTS releases for production applications. LTS means long-term support. 12

An outdated component does not prove that a system has already been compromised. It does require checking what maintenance the installation actually receives and how a new problem would be handled.

The business question is whether the platform can be maintained predictably through the next period.

What is the difference between a security patch, an upgrade and modernisation?

A security patch addresses a specific security problem. An upgrade moves a component to another version, while modernisation can involve broader changes to architecture and operation. These activities can be related, but each needs a clearly defined scope.

Version names and policies differ between technologies. Even a small update deserves verification appropriate to the system's criticality.

For an urgent issue, applying an available fix for the particular environment may be the appropriate first step, with a larger upgrade planned separately. The decision requires checking official guidance and the actual installation.

What business risks can prolonged postponement create?

Postponement becomes a problem when it increases dependence on unsupported components, obstructs necessary changes or leaves an important risk without a workable plan. The consequences depend on the system and cannot be determined from its age alone.

Three areas usually deserve attention:

• Maintainability. Are fixes available, and who can apply them?
• Development. Can the required feature be added with a reasonable scope of work?
• Compatibility. Do integrations and dependencies continue to support the versions in use?

For example, a business may request another payment method, only to discover that the maintained integration library requires a newer runtime. The payment task then acquires technical work that had not been anticipated. This is an illustrative scenario, rather than a specific client case.

Planned updates help reveal those dependencies earlier, so they can be considered alongside the company's budget and operations.

Why might changing the version in a hosting panel be insufficient?

Changing the server runtime does not automatically adapt application code and libraries. Before switching, check that the application and every critical component support the target version.

A larger upgrade may require changes to obsolete functions, configuration or third-party packages. The official Symfony major-version upgrade guide, for example, describes removing deprecated usage and adapting the code. 3

A task can therefore require coordination between the hosting provider, a systems administrator and an application developer. The administrator supplies the appropriate environment; the application team verifies how the software behaves.

That dependency exists across different technology combinations. The complete working configuration needs to be checked.

What does the PHP example show?

PHP illustrates why patching the runtime and upgrading the framework need to be considered separately. A vulnerability in the runtime requires action at that level, even when the application code has not changed.

Our article on PHP2Shell, patches and securing PHP applications examines a specific case. The official PHP advisories are the primary sources for technical conditions and affected versions. 56

There is another important detail: some vendors bring fixes into older packages without changing their main version number. This is called backporting and is described, for example, in Red Hat's maintenance practice. The exact package and confirmed support matter; a short version number alone may be insufficient. 4

Such a fix addresses a particular problem. It does not automatically establish that every other dependency is maintained or that a future upgrade is unnecessary.

When should you plan a technical update?

A technical update deserves assessment before support ends, when a significant incompatibility appears or when planned development depends on newer components. An identified urgent risk needs its own timeframe based on the problem and available measures.

Signals for a conversation with the technical team include:

• A key version is approaching, or has reached, the end of support.
• Responsibility for monitoring and applying security fixes is unclear.
• A new integration needs a library the current system cannot support.
• Changes are blocked by abandoned packages.
• A hosting or infrastructure move is planned.
• The store, portal or internal system is about to undergo substantial development.

Every new release does not need to trigger an immediate project. The target should be a supported, compatible version with a suitable maintenance horizon.

What does a well-planned upgrade involve?

A well-planned upgrade has a clear purpose, a dependency map, checks of critical processes and a prepared deployment. A good outcome includes a working system after the change, beyond simply displaying a newer version number.

1. Define the purpose. A security fix, continued support, a new integration or another business requirement.
2. Take an inventory. Actual versions, packages, extensions, external services and responsible people.
3. Choose the target state. A supported combination of components and a justified order for updating them.
4. Adapt and verify. Code changes and testing in a separate environment appropriate to the project.
5. Prepare deployment. Backups, a verifiable recovery path, a change window and communication.
6. Deploy and monitor. Check the real environment, errors, integrations and completion of critical tasks.

For an online store, checks commonly include login, search, the basket, checkout, payment and synchronisation. For a CRM, they may cover customer creation, quotes, permissions and reports. The actual business process determines the list.

If data changes, the rollback plan must account for it too. Restoring only the previous code may be insufficient after the database has changed.

Does an update require a rewrite or a new design?

A technical update can preserve the business rules, data and familiar interface. The need for broader rework is assessed separately against the system's condition and future requirements.

At Sirius Software, reliability, long-term usefulness and the ability to develop a system further guide the approach. Effective business processes deserve to be preserved.

For a discussion of extending a system versus broader rework, see our article on maintaining and developing existing software.

A newer version may offer improvements, but its effect on performance needs to be measured with the specific application. Changing the runtime will not fix every slow screen.

How much does updating an existing system cost?

Cost depends on the gap between current and target versions, dependencies, custom changes and the required verification. The scope needs to be established before a reliable estimate can be given.

When comparing proposals, look for clarity on:

• Components being updated and necessary code changes.
• Critical features and integrations that will be checked.
• Work required from developers and administrators.
• Any data or infrastructure migration.
• Deployment, recovery and monitoring after launch.
• Activities included in, and excluded from, the scope.

Also ask whether the target version has enough support time remaining. A short technical transition can make sense, provided the next step is understood.

Frequently asked questions

How often should business software be updated?

Frequency depends on the technologies, the system's criticality and its maintenance policy. Regular reviews of versions and security advisories are useful. Urgent fixes are assessed when they emerge; larger transitions are planned in advance.

Is it enough for the hosting provider to handle updates?

That depends on the agreed scope. The provider may maintain infrastructure and part of the runtime, while application code, extensions and integrations remain another team's responsibility. The division of work should be explicit.

Can an update be completed without downtime?

Some systems allow deployment without a planned interruption. Others require pausing writes or scheduling a migration window. This is established during preparation and should not be promised for every application in advance.

Can another team update the system?

Yes, provided the necessary rights and access are available and the technical assessment supports the work. Understanding the business, code, dependencies and deployment process is part of preparation. Missing documentation can increase the effort required.

What should you prepare for the first conversation?

For an initial consultation, a system URL or demonstration, known versions, hosting information and intended changes are useful. If you do not know the technologies, start by describing the problem.

• What does the system do, and which processes depend on it?
• Who maintains it today?
• Has a provider issued a warning, or is there a specific problem?
• What development is planned?
• Are there periods when a change should be avoided?

There is no need to send passwords or source code with the initial enquiry.

Sirius Software can help plan and deliver the update

Sirius Software develops and maintains business systems, online stores and integrations. We can help assess required changes, coordinate application and infrastructure work, carry out technical updates and verify the result after deployment within the agreed scope.

Send an enquiry for a free consultation. Describe the system, current difficulties and development plans. We will discuss which further checks and actions are appropriate for your situation.

When an internal review is needed, we agree access and sign an NDA before the code is provided. Learn more about our work through our software development service.

About the author: Georgi Papucharov is a co-founder of Sirius Software. He works on custom business systems, integrations and the long-term development of existing software.

Sources

Technical sources were checked on 26 October 2026. Support periods and security advisories should be checked again when planning a specific change.

1. PHP: Supported Versions - the official PHP version lifecycle.
2. Node.js Releases - release status and LTS recommendations.
3. Symfony: Upgrading a Major Version - dependencies and adaptation during major upgrades.
4. Red Hat: Backporting Security Fixes - applying fixes to older packages.
5. PHP advisory: RCE via OOM corruption - a primary source for the specific PHP example.
6. PHP advisory: RCE via stale global state - a primary source for the specific PHP example.