A web service does more than deliver pages: it checks permissions, changes data, calculates prices and communicates with other systems. Replacing PHP must preserve those decisions and the expectations of client applications. Language selection is only part of the task. We establish API contracts, operational rules and availability requirements before choosing Go or Node.js and deployment suited to actual demand.
Start with the service boundaries
Inventory incoming requests and outgoing events. For each scenario, establish the caller, supplied data and expected response. Record errors, rate limits and repeat-request behaviour separately. These rules may exist only in legacy code. Making them explicit prevents a new implementation from silently changing partner integrations.
Creating an order, for example, requires more than a successful response and database row. Preserve pricing, customer links and state transitions. A retry after a network failure should not unexpectedly create another order. Notifications and external synchronisation need their own controls. We describe the entire business scenario, rather than just its route handler, to verify completeness.
When we choose Go
We consider Go for clear server logic, concurrent request handling and controlled deployment. Modules, database interaction and error handling are defined beforehand. Building an executable can simplify delivery, but configuration and infrastructure remain necessary. A representative scenario and workload measurements validate the choice, especially when replacing several existing processes with one service.
When we choose Node.js
Node.js can suit projects benefiting from server-side JavaScript, external APIs and an existing JavaScript team. Handlers must manage asynchronous work correctly and isolate expensive computation. We select a supported release line and pin dependencies. A large package ecosystem helps integration but requires selection discipline: a library for one small operation is not always worth its maintenance cost.
| Criterion | Go | Node.js |
|---|---|---|
| Team skills | Go maintenance capability required | Familiar to JavaScript teams |
| Delivery | Compiled application | Runtime and dependencies |
| Integrations | Verify required SDKs | Verify required SDKs |
| Deployment | VPS, containers or functions | VPS, containers or functions |
Where to deploy
A VPS/VDS provides a defined persistent resource and environment control. Containers improve delivery reproducibility when images and configuration are prepared. Serverless can suit event-driven or variable workloads with appropriate operation duration. Databases, networking, secrets and monitoring remain in every model. We calculate the full scenario, including storage, transfer and peaks, rather than selecting the cheapest advertised invocation.
Background jobs matter as much as the public API. Reports, newsletters and synchronisation can run on schedules unseen during demonstrations. We inventory them, define retries and record execution results. Operations with side effects require duplicate-processing protection, particularly when queues or functions may deliver events repeatedly.
- Contracts and business rules → Choose Go or Node.js
- Choose Go or Node.js → Verify API and data
- Verify API and data → Move traffic route by route
- Move traffic route by route → Operations confirmed?
- Operations confirmed? → Retire the old backend (Yes)
- Operations confirmed? → Verify API and data (No)
Preserve existing agreements during transition
Complex services can move gradually behind a common entry point, provided operation ownership and write rules are explicit. Two implementations must not independently alter the same entity without coordination. We migrate a limited scenario first, compare results and then expand traffic. This exposes incompatibilities before they affect the whole product.
Acceptance includes successful and failed requests. We check ordinary users, administrators and unauthorised access to another person’s data. Final states matter as well as HTTP codes. Payments use the provider’s test environment and an agreed launch check. Logs should locate failed operations without unnecessary personal data exposure. These results support cutover and eventual PHP retirement.
One owner for each operation
During gradual migration, identify which system may change an order or balance. Sharing a database is not enough: implementations can interpret states differently and repeat side effects. We assign write ownership at each stage and document its transfer. Read operations may move before writes, but this must fit the data model.
External clients retain a stable entry point or receive an agreed contract change. Maintenance behaviour is defined without exposing internal failures as user responses. Temporary API compatibility has a deadline and completion conditions. You should see which components still depend on PHP and why, preventing two competing backends from becoming permanent.
Choose transition metrics beforehand: successful operations, errors and response times. Compare equivalent workloads before and after so the measurements support a meaningful decision about further traffic movement.
Gradual replacement needs a clear end as well as a safe beginning. A route temporarily remaining on PHP is not a defect if that stage was agreed, but its purpose and owner must remain visible. Before retirement, verify the public API, scheduled operations and external notifications together. This prevents a service that appears fully migrated from depending on an old worker for reports, order updates or another operation that only runs outside the demonstration period.
The same principle applies to costs. A deployment estimate should account for the components the service actually uses, rather than only the server process. A small runtime bill is not the entire operating cost if data storage, networking and monitoring remain elsewhere.
What the customer receives
The result is a service with documented contracts, migrated data and a reproducible release process. You receive code and instructions, understand backup rules and know who owns infrastructure. New integrations fit clear module boundaries. Send your APIs, external links and workload requirements: we will prepare an architecture, cost estimate and timeline reflecting the service’s actual complexity.
Sources
Node.js: releases and support. Go: vulnerability management. AWS Lambda: operational recommendations. Checked on 26 October 2026. Migration procedures, examples, prices and delivery conditions describe the project’s proposed service.
