Moodle, run like a product

Most Moodle installations are improvised. Ours are not.

MIDDAG runs Moodle as a versioned product: every site is a unique project, every deployment is reproducible, every upgrade is rehearsed. Clients who come to us from other agencies typically arrive with three problems: upgrades that break in production, plugin sprawl with no audit trail, and disaster-recovery procedures that exist only as someone's memory. We fix those three things first, then everything else gets easier.

What clients get

• Upgrades that do not surprise. Every site upgrade has been exercised locally, in staging, and on a backup of production data before the production window opens.
• Plugin lineage. Every plugin we ship is versioned, signed, and traceable to a code change. No more "where did this customization come from?" three years later.
• Reproducible installations. New environments come up from scratch in minutes, not days. Staging that drifts from production is a configuration bug, not a fact of life.
• Operations as commands, not rituals. Backup, restore, rollback, log inspection — each one is a single command, scripted and run the same way by every operator.

How we get there

A Moodle site at MIDDAG is three things working together: a managed dependency tree, a pinned runtime, and a small operational command set that gives every site the same shape. The plumbing is intentionally boring; the boring plumbing is what makes the next incident solvable instead of legendary.

The result: when something does break — and at some point something will — the operator on call already knows where to look. The same is true on day one as on day one thousand.