Modernise Existing Software
Your PHP application is still needed, but an upgrade is approaching? I review the existing code and plan the changes, so you know what can be retained and what needs modernising.
Discuss your modernisationStefan Pilz · PHP development and codebase reviews · 100% remote
SERVICE OVERVIEW
Software modernisation means developing an existing application further without prematurely replacing important business processes. SP Webconsulting supports the analysis and modernisation of PHP applications, including updates, new integrations and additional functionality. I compare incremental changes with possible replacements based on the actual system.
An application often remains valuable even as changes become harder: its runtime is old, dependencies are unclear, documentation is missing or the original developer is no longer available. At the same time, it supports workflows that a standard product cannot easily replace. A technical assessment clarifies the possible next steps.
SERVICE SCOPE
I assess the structure, runtime, libraries, database and external connections, together with the workflows that matter most in daily operation. Technical issues do not all have the same priority. We distinguish immediate obstacles, necessary groundwork and improvements that can follow later.
Based on the assessment, I plan possible steps for updating PHP, frameworks and libraries. Changes are tested in a separate environment where one exists or can be set up. If test coverage is missing, important workflows are first documented clearly and protected through targeted checks.
Modernisation can also mean adding an integration, replacing a manual import or isolating a particularly difficult part of an application. Feature requests and technical cleanup are evaluated separately, so it remains clear which need each change addresses.
POSSIBLE USE CASES
Example workflow
Test a change before adopting it.A possible approach. Tests, backups and recovery depend on the application.
The following examples describe possible assignments, not documented client projects.
Dependencies and important business processes are reviewed first. The application is then adjusted incrementally in a test environment, with incompatibilities documented and addressed as they emerge.
An application that is still needed must exchange data with a store or ERP system. We review existing export methods and possible integrations before making changes deep inside the application.
One part frequently causes problems while the rest of the system remains useful. That task can be isolated and replaced gradually where data and functional dependencies allow it.
DELIVERABLES & SCOPE
We agree the deliverables before starting. Depending on the scope, these may include:
Some changes may not be possible without source code, suitable access or replaceable dependencies. An initial assessment can also reveal problems that could not be estimated reliably beforehand. Assumptions and scope are therefore documented. A release without interruption cannot be promised in every case, especially where data changes are involved.
Information about your PHP version, framework, hosting and known issues is helpful, along with a description of the main workflows. Incomplete information is enough for an initial conversation. We then agree the actual review, necessary access and a limited analysis scope. My work is entirely remote.
WORKING TOGETHER
We clarify source-code access, runtime, database and the main user workflows. Missing information is recorded as open questions.
I explain which updates depend on others and what alternatives exist. A complete rebuild is not assumed automatically.
An agreed stage is implemented and tested against relevant workflows. Results and new findings inform the next steps.
Before production changes, we clarify backups, possible interruptions and rollback options. The next stage is decided based on what has been achieved.
RELEVANT EXPERIENCE
For a custom-built website, I adapted the existing PHP code to a newer runtime. This anonymised project demonstrates that upgrading an existing application can be possible; the effort for your system needs a separate assessment.
Anonymised client project · Starting point
An established website with many individual PHP files needed to remain in use. Its existing functionality and code formed the starting point.
The same project · Implemented result
The code was adapted and retained. A complete rewrite was not needed for this project. A review establishes whether the same approach is suitable for your application.
RELATED SERVICES
Adapt code to PHP 8.4 or 8.5. Security support for PHP 8.2 ends on 31 December 2026.
Step by step via the LTS releases to Symfony 7.4 LTS or 8.
Establish which code is still needed and remove legacy code safely.
Remove orphaned tables and outdated data with a backup and a way back.
Fix slow pages and Core Web Vitals issues at the source.
QUESTIONS & ANSWERS
Development and testing can take place separately from live operation. Whether release requires an interruption depends particularly on database changes.
I consider the condition of the code, its dependencies and the business processes that must be preserved. We then compare incremental modernisation, targeted replacement components and a possible rebuild. Effort, risks and future requirements matter more than the application's age alone.
Source-code access, information about PHP and database versions, and a description of the main workflows are useful. Existing documentation and a test environment make the review easier. Credentials are exchanged later through an agreed secure channel, rather than through the enquiry form.
We first document important business workflows and known error cases. Tests can be added for particularly relevant areas before making changes. The appropriate level of protection depends on the scope, testability and importance of the affected functions.
Often, yes. For example, we can first investigate critical dependencies, then update the runtime and subsequently add features. The order follows technical dependencies and operational risks. Each agreed stage has a clear scope and acceptance criteria.
NEXT STEP
Tell me about the application, known technical issues and the most important change you want. We will establish what is needed for an initial assessment.
Your enquiry goes directly to me, Stefan Pilz. We agree the scope and costs before you commission any work.
I read your enquiry and get back to you. Together, we clarify your goals, constraints and open questions.
Depending on the project, we start with a specific implementation or an analysis agreed in advance.
You know which services and deliverables are included. We agree on scope, effort and costs before you commission the work.