Update Tuesday
Every Tuesday a developer works through the maintenance list. She logs into the management dashboard, sees dozens of pending updates across client sites, and applies them in batches. She checks a few homepages afterwards. Most are fine.
On Thursday a client emails to say their booking form has stopped working. A plugin update changed a field. Another client's product filter broke after a page builder update, and nobody noticed until a customer complained. The developer spends Thursday and Friday fixing things, and the Tuesday routine starts to feel like a gamble.
Why updates are risky at scale
- Every site has a different mix of plugins, versions and custom code.
- Updates are applied straight to live sites because staging copies are not kept current.
- Checking is a quick look at the homepage, while breakages hide on forms, checkouts and filtered pages.
- Updates are batched to save time, so when something breaks it is not obvious which update caused it.
- Some sites are skipped because they are "fragile", and fall further behind.
The agency faces two bad choices: update and risk breakage, or skip updates and risk security issues. It needs a routine that makes updating safe.
What the current routine costs
Developer time goes on updates and then again on fixing what broke. Clients find problems before the agency does, which undermines the whole point of the maintenance plan. Sites that are skipped build up a backlog of old plugins that become harder to update over time. Maintenance plans that were meant to be profitable become a source of stress.
The update routine we build
- Each site has a list of key pages and journeys: homepage, contact form, booking form, checkout, search, and anything the client depends on.
- Before any update, a fresh backup is taken and confirmed complete.
- Updates are applied to a staging copy of the site first, created from the current live site.
- Key pages on staging are screenshotted before and after the update and compared automatically. Forms can be test-submitted to a safe address.
- Sites where nothing changed unexpectedly are updated on live, and the live pages are checked again.
- Sites with visual differences or failed checks are held, with the screenshots and the list of updates, for a developer to review.
- Every update, check and result is logged per site, ready for the client maintenance report.
| Step | Automated | Needs a person |
|---|---|---|
| Backup before update | Yes | Only if the backup fails |
| Updates on staging | Yes | No |
| Visual comparison of key pages | Yes | When differences are found |
| Form test submissions | Yes | When a test fails |
| Updates on live | Yes, for clean sites | Held sites only |
If you use a management tool such as ManageWP or MainWP, we build around it and add the staging, visual checks and routing it does not cover, rather than replacing it.
Tuesday with the routine
The update run goes through overnight. In the morning the developer has a short list of sites held for review, each with before and after screenshots showing exactly what changed. One page builder update has moved a button on a client's homepage. She fixes the styling on staging, approves the update, and moves on. Most sites were updated without her touching them, and none of the clients find a broken form on Thursday.
Does updating feel like a gamble?
- Plugin updates are applied straight to live client sites.
- Clients have reported broken forms or checkouts after updates.
- Checks after updating are a glance at the homepage.
- Some sites are skipped because updates tend to break them.
- Maintenance time is taken up fixing update breakages.