Case study
Modernising a US subscription platform
An existing subscription business needed a supported PHP version while continuing to serve paying customers. A compatibility layer made the upgrade possible without rewriting the application.
This case study describes the documented stage of the work, rather than the system's current state. The client is anonymised.
- Work covered
- Audit, modernisation, admin tools, video delivery
- Technology
- PHP 8.4, MySQL, Docker
- Key decision
- A compatibility layer for the old database calls
- Continuity
- The platform continued to serve subscribers
The starting point
The US platform sold subscriptions to a video catalogue, with recurring payments, an affiliate programme and access controlled by membership level.
The application had accumulated years of procedural PHP. Its database calls depended on functions removed from PHP in version 7.0. Payments still ran through Perl CGI scripts. There was no local development environment, so production was the only place available to check changes.
My work covered taking over the existing system, assessing its risks, modernising the runtime, building administration tools and improving access control and media delivery.
Audit before committing to a rewrite
The audit separated urgent risks from older components that could continue working. It identified an unsupported PHP version, gaps in access control and infrastructure costs as priorities.
That gave us a basis for choosing the work. The decision was to preserve the application's existing behaviour while replacing the parts preventing a supported runtime.
The decision: preserve the calls, replace the database layer
The target was PHP 8.4. The obstacle was 46 files calling database functions that no longer existed in the language.
I implemented a compatibility layer using PDO. It recreated eight removed functions with typed signatures and the behaviour expected by the existing code. The application moved to PHP 8.4 without changing those 46 files.
The work also included updating dependencies, adding static analysis and automated formatting, and building a containerised local environment. Changes could then be checked locally before deployment.
A bot responsible for about a quarter of requests
During the period analysed, the server handled roughly 90,000–95,000 requests a day. One bot accounted for about 24,400 daily requests, approximately 26% of the total. It pretended to arrive from Google by forging the Referer header.
Its repeated query-string signature made a targeted filter possible. I monitored the filter for two days and found no cases of legitimate users being blocked during that observation period. Aggressive commercial crawlers scanning the catalogue were blocked separately.
A visitor-log table had also grown to 2.1 GB and become corrupted. It was rebuilt using a transactional storage engine. The bot's share describes requests, not a measured reduction in CPU use or total hosting cost.
Moving video delivery off the application server
The video migration covered 1,148 items and approximately 143 GB of source files. Playback and downloads moved to a specialist CDN using cryptographically signed URLs. The work also addressed premium files being directly accessible outside the subscription checks.
Estimated CDN video-hosting costs were USD 12–20 per month. The existing application-and-file server cost USD 400 per month, but moving to a smaller application server remained a separate planned step at the end of this stage.
Overall savings could only be confirmed once both the replacement application-server cost and actual CDN charges were known.
Security and administration
The audit and implementation uncovered several concrete access and security problems:
- SQL injection in a public page.
- Scheduled and hidden material appearing before its publication date.
- Development and configuration files returning HTTP 200 in production.
- An administration interface without two-factor authentication.
The issues listed here were fixed and the changes deployed. Scattered administration scripts were also replaced with one interface for content, members, subscription promotion, an administrative event log, resumable video uploads and two-factor authentication.
What the business had at the end of this stage
The platform ran on PHP 8.4, with a local development environment, regression tests and a consolidated administration interface. A targeted filter blocked the bot previously responsible for approximately 26% of requests. Video delivery had moved to the CDN.
The compatibility layer allowed the business to keep developing the existing application. Infrastructure savings still depended on completing the separate application-server change.