Containerising a Legacy PHP Billing & Inventory System for a Coimbatore Textile Shop

Sri Anbu Textiles, a saree and dress-material shop on Cross Cut Road in Coimbatore, has billed its customers since 2013 with a PHP 5.6 application running on one Windows desktop under XAMPP. The application works — and that is precisely the problem: it is undocumented, unversioned, unbacked-up, and it dies with the desktop it lives on. When the machine's power supply failed during Deepavali season, the shop lost three days of billing and the owner discovered nobody had ever restored a backup.

This project migrates that system into a containerised, reproducible deployment — deliberately keeping the proven business logic instead of rewriting it. The work has four measured stages: audit and baseline (document the code, database and current performance on the shop's own hardware), remediation (fix PHP 8 deprecations and replace removed mysql_* calls with PDO), containerisation (a php:8.2-apache image, a MariaDB container, an automated backup sidecar and a Compose stack driven by a .env file), and verification (the identical JMeter workload replayed against old and new setups, plus a recovery-time drill).

The deliverable is not just a Dockerised app but a numbered argument: requests per second, p95 latency, error rate under load, mean time to recovery and deployment time — each measured before and after. For an Anna University MCA project (Cloud Computing MC4203, DevOps MC4009), this is an honest intermediate-level cloud/DevOps study: no invented architecture, every claim traceable to a table in the report.

Sri Anbu Textiles, a Coimbatore textile shop with two billing counters, runs its entire billing and inventory operation on a PHP 5.6 application installed on a single Windows desktop under XAMPP. The system holds eleven years of purchase and sales records, yet nothing about it is reproducible: there is no source control, no environment documentation, no automated backup, and no tested restore procedure. The application cannot be upgraded, moved or rebuilt without the one programmer who wrote it in 2013.

When the desktop failed during the Deepavali sale season, billing stopped for three days; the eventual restore from the pen-drive copy silently lost a week of stock movements. The application also runs on a PHP version that has not received security fixes since 2019, exposed on a LAN that customers' phones occasionally join.

The shop does not need new features — it needs the same system made portable, reproducible and observable: packaged so it can run on any Linux machine with identical behaviour, backed up automatically with restores that are actually rehearsed, and measured so that the current performance and the post-migration performance are known numbers, not opinions. That is a cloud/DevOps migration problem, not a rewrite problem.

Abstract

Thousands of small Indian retail businesses run daily operations on decade-old PHP applications installed on a single desktop. These systems are business-critical yet fragile: tied to one machine and PHP version, configured by hand, backed up (if at all) by copying folders to a pen drive. This project takes the billing and inventory system of Sri Anbu Textiles, Coimbatore — a real workflow, fictionalised name — and moves it into a containerised Linux deployment, measuring before and after so the migration is justified with data, not enthusiasm.

Introduction

Containerisation is usually taught on greenfield web apps, but the more common industry task is moving an inherited system into containers without changing what it does. That constraint makes this a study in migration engineering: reading unfamiliar code, quantifying the current state, remediating just enough for a modern PHP runtime, and packaging the result so the shop's "server" is any Docker machine — rebuilt in minutes from source and a dump.

Existing system

• PHP 5.6 + MySQL 5.5 on XAMPP, Windows 10, one desktop shared by two billing counters over the LAN.
• Features: tax invoice printing, saree stock with size and colour variants, supplier bills, day-end tally.
• No version control; the only backup is a monthly manual copy to a pen drive, never test-restored.
• Performance unknown; the app "feels slow" during festival sales when both counters work simultaneously.
• Limitations: the machine is a single point of failure; PHP 5.6 gets no security fixes since 2019; a post-crash reinstall took a working day and lost a week of stock entries.

Proposed system

• A documented baseline: code inventory, ER diagram of the existing schema, and a JMeter workload recorded against the untouched XAMPP setup.
• Remediation only where required: PHP 8.2 compatibility — removed mysql_* calls replaced by PDO with prepared statements, deprecated constructors fixed — with every change in a traceability table.
• A containerised stack: Compose services web (php:8.2-apache from the remediated source), db (MariaDB 10.11, schema-init mount) and backup (a sidecar running scheduled mysqldump). All configuration moves to .env environment variables.
• Verification: the identical JMeter plan replayed on the same laptop against both setups; measured throughput, p95 latency and error rate at three concurrency levels; a recovery drill (stop the db container, restore the latest dump) timed against the desktop-crash story.
• A GitHub Actions workflow builds the image and runs a smoke test on every push, so the next change is one tag away.

Feasibility study

• Technical: the legacy source (~9,000 lines, no framework) came from the shop's previous programmer; PHP 8 issues concentrate in the database layer and are fully catalogued. Docker runs on any 8 GB machine.
• Economic: ₹0 in licences; the target machine is a refurbished mini PC (₹8,000–10,000) the shop had already considered buying.
• Operational: counters keep the same screens and URLs; the only visible change is a faster invoice page and a printed A4 runbook for restoring from backup.

In scope

• The existing billing + inventory feature set, unchanged functionally: invoices, stock with size/colour variants, supplier bills, day-end tally, reports.
• One shop, two counters; users are the two billing staff and the owner.
• Migration artefacts: audit document, baseline measurements, remediation traceability table, Dockerfiles, Compose stack, backup/restore runbook, GitHub Actions workflow, final measurement report.
• Deployment target: a single Linux host (refurbished mini PC) on the shop's LAN; Docker is the only dependency.

Out of scope (v1)

• Rewriting the UI or adding new features (e-Commerce, GST-return filing, barcode billing) — the point of the study is migration without behaviour change.
• Multi-shop or cloud-hosted deployment; the LAN host is the agreed target.
• Load balancing or horizontal scaling — a single-compose-node study.
• Conversion of the legacy MySQL 5.5 data beyond a documented dump-and-restore into MariaDB 10.11, with row-count and checksum verification.

The project follows an incremental model with a measurement-first discipline: every stage that claims an improvement must first have a number for the state it is improving. The two-member team splits as Member 1 — audit, remediation and application behaviour; Member 2 — containers, database, backups and measurements — with the measurement report jointly owned.

Testing approach: a smoke suite (invoice create, stock search, tally) executed against both environments; the JMeter comparison as the acceptance gate; and the restore drill — restore the latest dump into a fresh db container, verify row counts and a checksum on the sales table, and record elapsed time. Data handling follows a simple ethics rule: the shop's real data stays on the shop's machines; all bundled data is synthetic.

The target architecture is deliberately boring — that is its selling point. Three containers on one Linux host, composed from a single file, with the shop's LAN as the only network.

1. web — the remediated PHP 8.2 application served by Apache inside the official php:8.2-apache image; the document root is the legacy source, built into the image so the running version is always a tagged artefact, never a half-updated folder.
2. db — MariaDB 10.11 with a named volume; on first start it applies the legacy schema and, if provided, the verified SQL dump through the /docker-entrypoint-initdb.d mount.
3. backup — a small Alpine sidecar running scheduled mysqldump to a second, separate volume; its logs state the last successful dump, and a manual one-command restore path is documented and rehearsed.

All settings (database host, credentials, PHP error display, timezone) arrive as environment variables from .env, so the same compose file runs unchanged on the developer laptop and the shop's mini PC. The GitHub Actions workflow builds the web image on every push, runs a smoke test against an ephemeral MariaDB service container, and pushes the image only when the smoke test passes.

flowchart LR
  C1["Counter 1 (browser)"] -->|LAN| WEB
  C2["Counter 2 (browser)"] -->|LAN| WEB["web: php 8.2-apache"]
  WEB -->|PDO| DB[("db: MariaDB 10.11")]
  DB -->|volume| V1[("dbdata volume")]
  BK["backup sidecar (cron mysqldump)"] --> DB
  BK --> V2[("backup volume")]
  GHA["GitHub Actions"] -->|build + smoke test| IMG[("image registry")]
  IMG -->|compose pull| WEB

erDiagram
  ITEM ||--o{ STOCK_MOVE : records
  SUPPLIER ||--o{ PURCHASE : supplies
  PURCHASE ||--|{ PURCHASE_LINE : contains
  ITEM ||--o{ SALE_LINE : "is sold as"
  SALE ||--|{ SALE_LINE : contains
  SALE {
    int sale_id PK
    date sale_date
    decimal taxable_total
    decimal tax_total
    decimal grand_total
    string payment_mode
  }
  ITEM {
    int item_id PK
    string name
    string size
    string colour
    decimal mrp
    decimal selling_price
    int stock_qty
  }
  SALE_LINE {
    int line_id PK
    int sale_id FK
    int item_id FK
    int qty
    decimal rate
    decimal line_total
  }

The schema is the legacy one, reverse-engineered during the audit and normalisation-checked in the report (it is close to 3NF; the two intentional denormalisations — cached stock_qty and grand_total — are documented with their update rules). Nothing about the data model changes in the migration, which is exactly what makes the before/after comparison valid.

• TLS-secured reverse proxy (Nginx/Caddy) with a shop-internal certificate, closing the plain-HTTP gap on the LAN.
• Offsite backup replication to inexpensive object storage with a monthly restore rehearsal.
• Watchtower-style image updates so the shop's next feature request ships as a tagged build.
• Read-replica reporting container for the owner's dashboards without touching the billing path.
• Migrating the UI progressively behind the same containers — one screen per release, each measured.
• A follow-on study applying the same measured-migration method to a second legacy domain (e.g. a medical shop).