Legacy CMS Modernization

"Rondom het Stroomkanaal" has been running a regional billiards competition for over a decade. The site had been live on GetSimple, a flat-file CMS, for seven-plus years before this work started. It worked, in the sense that it stayed online. But weekly operations were brittle.

The club secretary, who did not work with HTML, was responsible for updating the competition schedule and results every week. In practice that meant opening the CMS page editor, finding the right place in a wall of HTML, and copy-pasting new fixture rows into <pre> tags or hand-assembled HTML tables. Results for each round meant updating multiple pages manually. One wrong tag, one missed column, one paste in the wrong place, and the public page broke or showed wrong data.

This happened regularly. The errors were not catastrophic and no data was permanently lost, but they required a developer to diagnose and fix, which brought the same dependency problem back through the correction loop.

Replacing the CMS entirely was off the table. The site had ten years of operational history, a hosting setup that assumed flat files, and no appetite for a full migration. The constraint was explicit: make it safe to operate without touching the underlying system.

Four custom admin pages were added to the existing CMS, sitting alongside the standard GetSimple admin without replacing or modifying it. The CMS core is unchanged. The deployment model (FTP, flat files, no server-side tooling) is unchanged. What changed is how competition data moves through the system.

Competition data now lives in typed JSON files, not in page content. When the club secretary saves a round of results through the weekly entry form, two public pages are regenerated automatically from that JSON. The operator submits a form; the site updates. There is no HTML to edit, no table structure to maintain, no page to find in the CMS editor.

Season rollover accepts pasted Excel fixture data, validates team names against the active snapshot, shows a full preview, and on confirmation archives the previous season to a frozen JSON file and creates a new active one. What was previously a developer task, including manually copying pages, renaming files, and resetting data, became an operator action taking a few minutes.

Team management, archive browsing, and result entry all follow the same pattern: form in, structured data written, page content regenerated. The operator never touches the output. Every write is backed up before it happens.

Three years of the extended CMS running in production surfaced the limits of the flat-file model clearly enough to make a full rebuild worth scoping. BiljartV2, a Laravel 12 rebuild of the same competition's platform, replaced this system with a typed import pipeline, a Filament admin, a relational data model, and a full audit trail. The constraint that shaped this project ("no database, no migration") was the reason the rebuild was eventually possible: by the time it happened, there was a working system to replace, not a broken one.