Replacing PHP means preserving application behaviour, not translating every line. Legacy code combines useful rules, temporary fixes and unused capabilities. We identify what matters, implement it on a new foundation and verify the result. The plan starts with contracts and data, passes through a separate test environment and ends with controlled cutover accounting for new operations.
Describe inputs and outcomes
Inventory pages, APIs, forms, schedules and external notifications. Record parameters, permissions and responses, including failures and retries. This preserves frontend and partner compatibility. Agree contract changes explicitly so technical migration does not silently alter the product for existing users.
Describe final state for complex operations. An order must create relationships, preserve its agreed amount and trigger required actions. A successful response without that result is insufficient. Define duplicate protection, asynchronous receipt confirmation and visibility of subsequent failure. These contracts can verify either language and any deployment model.
Migrate the data model
Review tables, relationships and identifiers used externally. Historical columns need not all survive, but removal needs justification. Map entities, trial-import and reconcile. Check encoding, dates, time zones and monetary values. Files need links and access rules. Data transfer is a separate acceptance stage rather than an unnoticed command between interface development and launch.
| Area | What is preserved or changed | Verification |
|---|---|---|
| API | Contracts and failures | Request scenarios |
| Data | Relationships and identifiers | Import reconciliation |
| Authentication and permissions | Roles and access | Allowed and denied actions |
| Background jobs | Schedules and repeats | Controlled execution |
Resolve authentication
Never turn passwords into plaintext for convenience. Review existing hashes and secure compatibility. If unsuitable, plan controlled access recovery. Decide on sessions and tokens too: terminating old sessions may be appropriate, with users informed. Administrative permissions need explicit review rather than copying historic excess privileges.
Design the replacement
Choose Go or Node.js for the service and maintenance team. Separate non-personalised pages from server logic where appropriate. Integrations receive explicit configuration and limited credentials; secrets stay out of source. Builds and environments must be reproducible from instructions. Small sites do not need excessive distribution; complex services may need separate processes with clear operational ownership.
Move background jobs alongside public routes. Record schedule, time zone, concurrency limits and retry behaviour for reports, email and cleanup. Verify safe repeat execution where data changes. During coexistence, prevent both implementations from running the same obligation. Every task needs a single clear owner at each cutover stage.
- Contracts and data model → Replacement implementation
- Replacement implementation → Trial import and scenarios
- Trial import and scenarios → Results match?
- Results match? → Replacement implementation (No)
- Results match? → Final synchronisation (Yes)
- Final synchronisation → Cutover and PHP retirement
Check implicit legacy behaviour
Languages handle missing values, dates and numbers differently. Currency needs agreed precision; empty is not always zero. Old code may rely on implicit conversions. Record representative inputs and expected results, especially calculations, discounts and selection rules containing important business logic.
Check sorting, case and text encoding, plus search variants. Define how event times are stored and displayed. Do not replace identifiers without checking external links. Capturing these details before rewriting is better than fixing customer complaints afterwards: old behaviour becomes explicit requirements.
Retain sample responses and control data states before work, using only necessary information under agreed access. They support later comparisons without depending on the server scheduled for retirement.
Data reconciliation should include meaningful examples, not only totals. Equal record counts cannot establish that an order still refers to the right customer or that its amount has retained the agreed precision. A trial import checks relationships and representative results before the production cutover is scheduled.
Session handling is another explicit decision. The old application’s active sessions may not be suitable for the new implementation, and administrative rights should not be carried over without review. If users must sign in again or recover access, plan the communication and procedure rather than discovering the incompatibility after launch.
For background work, establish when responsibility transfers. An old cron job and a new worker must not both process the same duty simply because the public traffic has moved. Confirm schedules, time zones and safe repeat behaviour along with the visible API.
The deliverable is a reproducible service. Another authorised team should be able to build, configure and check it from the handed-over materials without recovering undocumented manual settings from the old server.
Verify and switch over
Tests follow risk. Forms need validation and delivery; accounts need user-data separation; payments need agreed states and provider events. Performance checks use comparable conditions if in scope. Reconcile data immediately before cutover and define any write restriction. Monitor the replacement so failures follow an established process rather than relying on complaints.
Rollback must preserve completed operations. After acceptance, check service addresses and confirm old processes are stopped. Hand over source, instructions and results. Send functionality and infrastructure details for a concrete plan rather than a promise of mechanical conversion. This preserves business meaning while making implementation clearer for future maintenance.
Sources
OWASP: access control. Node.js: security recommendations. Go: vulnerability management. Checked on 26 October 2026. Migration procedures, examples, prices and delivery conditions describe the project’s proposed service.
