A performing-arts academy's WordPress site stopped being a slow-motion emergency

Representative examplesEvery case study in this library is an illustrative composite of the kind of engagement we deliver — written to show our method and standards, not to name clients.

Where they started

Music, dance, and drama instruction for several hundred students is what this academy sells, with a founder, a small teaching faculty, and an office manager who handles enrollment, scheduling, and anything resembling IT. The website carries class schedules, term dates, tuition, and recital information — the operational heart of the academy, not a brochure. Updates had depended on one former board member who held the admin password and helped informally. That arrangement eroded quietly until the site was two years stale and nobody dared touch it.

What it was costing

The academy's site had not been updated in two years; a defunct plugin broke the class-schedule page two weeks before recital season, backups ran to an unreachable disk, and every change — even a tuition figure — required the one person who remembered the admin password.

What they could see

• The class-schedule page broke two weeks before recital season when a defunct plugin failed, and bookings moved to phone calls.
• Tuition changes and term dates sat unpublished for weeks because only one person could make them.
• Backups ran nightly to an office disk that had been retired in a move — nobody had checked in over a year.
• The admin password belonged to a former board member who helped when available and couldn't always be reached.
• Nobody could say whether the site had been compromised or simply neglected — there was no way to tell.

The constraints we worked inside

• No redesign in scope: the site's look and content stay as they are; the work is stability, safety, and maintainability.
• Recital season is immovable; risky work is scheduled around the calendar, not against it.
• The academy has no IT staff; everything handed over must be operable by the office manager.

What had been tried before

The password-holder ran manual updates on the live site whenever available, working through the backlog in single sessions.

Two years of drift made each update a leap between plugin versions too far apart to apply safely; the broken schedule plugin arrived inside exactly one such leap.

A backup plugin had been configured years earlier to write nightly archives to an office network disk.

The disk was retired in an office move and the job was never re-pointed — backups ran faithfully every night into a destination that no longer existed.

A student intern was assigned to make content changes so the password-holder wouldn't be the bottleneck.

Without credentials or documentation the intern couldn't publish either; the bottleneck was a single password, not the volume of work waiting behind it.

What we proposed

We proposed stabilization before anything else: core, theme, and plugins updated on a staging copy, the defunct schedule plugin replaced with a maintained equivalent, and the page restored — all scheduled around the immovable recital calendar. Backups move off-site with a documented, timed restore test, because a backup you haven't restored is a rumor. Then a maintenance rhythm the office can see: monthly update windows, uptime monitoring with email alerts, and a one-page runbook written to be operable by the office manager alone — no redesign, no migration, no new platform.

Just as important is what we ruled out, and why:

• A full redesign alongside the stabilization — Explicitly out of scope and calendar-hostile: recital season was weeks away, and redesign risk would have contaminated the stability work the academy actually needed.
• Moving to managed WordPress hosting — The site's problems were neglect, not infrastructure; a new vendor adds monthly cost without fixing update discipline, the dead backup target, or the single-credential bottleneck.
• Turning on automatic updates for everything — Untested auto-updates are how the schedule page broke in the first place; staged monthly windows with verification match the calendar and the office's tolerance for surprises.

How the work ran

Delivered by the systems pod — engineer over an ongoing 3-month initial phase, with working increments reviewed with the client every week.

The stack, and the reasoning

WordPress

No redesign, no migration — the academy's budget and the immovable recital calendar favor stabilizing the known install over gambling on a rebuild.

Managed updates

A monthly staged-update window ends two-year update leaps; small verified steps are safe, and annual ones are the gambles that broke the schedule page.

Off-site backups

Monthly update windows are safe against the recital calendar only because the restore has actually run — a bad update rolls back to the morning's site, and recital season never learns there was a problem.

Uptime monitoring

Email alerts name the failing page and reach the office manager directly, replacing a parent noticing first during enrollment week.

Maintenance runbook

One page, written in the office manager's own words, tells them what runs when and whom to call — no ticket portal between a question and an answer.

What went wrong

How we worked together

Cadence

A standing Wednesday morning call with the office manager before the studio opened, plus a monthly written report she could file with the board without editing.

Client side

The office manager was the single client-side owner — priorities, testing, acceptance; the founder joined once per phase to approve the calendar around recitals.

Decisions

Work around recital season was planned on a printed academic-year calendar together; anything risky waited for the windows they marked in pencil and kept.

They provided

The admin credentials and hosting account, contact with the former board member for institutional memory, and the office manager's mornings for training.

What changed

The headline: site current on a monthly cadence with verified restorable backups before recital season — Two years adrift → maintained baseline, read from Restore test report. A second check: single points of failure for content changes at 1 → 0.

The office manager answers schedule questions with a link instead of a phone call to the studio. Tuition and term changes go live the week they're decided, which quietly ended the contradictions with the printed brochure. The former board member's informal role ended gracefully, replaced by a rhythm nobody has to remember. The academy stopped planning its communications around what the website couldn't do, and recital season came and went without a single emergency.

The result was read from Restore test report against the pre-engagement baseline over the stated window, with a guardrail check on single points of failure for content changes. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

• The one-page maintenance runbook rewritten in the office manager's own words.
• Monthly update windows marked on the academic-year calendar, with staging steps printed.
• Verified off-site backups with a scheduled, timed restore test the office can run itself.
• Uptime monitoring with email alerts configured to reach the office directly.
• A plugin inventory with owners and purposes, so nothing becomes a mystery again.