“What is wrong with PHP?” usually follows an event: an update breaks a form, the store slows down again or a contractor proposes expensive rework. The language alone does not explain it. Old versions, architectural limitations and unclear maintenance combine into costs and delays. Assess migration through the cost of running a working service rather than developers’ preferences.
When familiar simplicity ends
A small website is easy to launch with a ready-made CMS. Then a catalogue, newsletters, accounts and accounting integrations appear. Each extension may introduce its own storage. Changing one requires checking the others. The owner still sees a simple website while a complicated system operates underneath. That gap makes change estimates less predictable.
PHP has supported versions and continues to develop. But a new release does not make an old project immediately upgradeable. Custom code and extensions may depend on previous behaviour. The owner must then pay for compatibility or retain the old environment. That dependency is a stronger reason to reconsider the foundation than the language’s age.
Where the real costs hide
Hosting is only the visible expense. Licences, conflict resolution, recovery and staff time also count. An editor unable to change a page creates a queue of small contractor tasks. Manually transferring orders consumes sales time. Architecture determines how much of that work recurs each week, even when these costs are not labelled technical.
| Cost | What to compare before and after |
|---|---|
| Infrastructure | Full monthly bill for the same workload |
| Licences | Necessary paid components and renewals |
| Maintenance | Update and conflict-resolution hours |
| Changes | Cost of a typical business capability |
| Failures | Lost operations and recovery time |
Compare equivalent service levels. A cheap virtual machine without backups or monitoring is not equivalent to supported managed hosting. Serverless costs extend beyond function calls to storage, transfer and logs. We calculate expected operating costs and sensitivity to traffic growth so you understand the proposed savings and where they may disappear.
What changes during migration
Moving to Go or Node.js lets us rebuild around required operations: retrieve a catalogue, submit an enquiry, edit content or confirm an order. Static pages can avoid contacting the application. Administration can have separate permissions and restricted exposure. This simplifies understanding, but the benefit comes from the implementation and verification rather than a language name in a contract.
We consider Go for compact deployment and controlled server logic; Node.js where a shared JavaScript environment and integrations benefit the project. Your team’s skills and maintenance matter. If only one person can operate the replacement, contractor dependence remains. Instructions, reproducible builds and source handover therefore enter the discussion from the start.
- Costs and limitations → Required function inventory
- Required function inventory → Which option pays off?
- Which option pays off? → Maintain the existing project (Upgrade)
- Which option pays off? → Go or Node.js (Migrate)
- Go or Node.js → Compare actual costs
When a rewrite is unnecessary
An understandable, maintained application meeting requirements may benefit more from ordinary improvements. Removing plugins, fixing queries or configuring caching can be enough. We compare improving the existing system with a replacement that includes data transfer. Both options need scope, timing and limitations rather than a predetermined recommendation.
For an ageing CMS, migration can reduce uncertainty. The owner receives a function inventory, dependencies and release procedure. A new team can understand the service without relying on previous contractors’ unwritten knowledge. This matters when offers, partnerships and sales channels change regularly and the website cannot be stopped for long.
A calculation without promised percentages
Imagine a business paying for catalogue maintenance and several monthly changes. Compare the same tasks on both systems. Spread migration expenditure across the chosen planning period and calculate infrastructure and maintenance separately. Then test whether the benefit survives fewer changes. If the conclusion requires optimistic sales growth, identify that assumption rather than presenting it as guaranteed language-related savings.
Management can then see which costs disappear, which arise and how sensitive the decision is to team activity. Consider exit costs too: access to code and data reduces dependence on future contractor and hosting terms.
For the business, predictable change is part of the result. A recurring editorial task should no longer depend on discovering which extension overrides another setting, and an integration should have an identifiable owner. These improvements cannot be represented by a single performance test. They should instead be checked through the typical tasks the company already pays to perform. Comparing those tasks on equivalent scope gives the owner a practical way to judge the migration after delivery.
How to assess value before ordering
Collect recent spending and identify recurring problems, then the changes the business actually needs next. We use these to assess the replacement and maintenance costs. A universal speed or savings percentage is unhelpful. One website benefits mainly from removing an unnecessary CMS; another needs database and process improvements. The proposal should identify your project’s source of value.
Migration starts at €200 for a small website without content management. Projects with a CMS, data or integrations follow other categories. Before launch, compare agreed operations and deployment conditions. After handover, verify publishing convenience, recovery and actual spending as well as page functionality. Those results show whether the old project reached its limits and whether replacement was justified.
Sources
PHP: supported versions. AWS Lambda: operational recommendations. Checked on 26 October 2026. Migration procedures, examples, prices and delivery conditions describe the project’s proposed service.
