Website maintenance: backups and post-launch updates

After go-live, sites need care: how I structure backups, patching, and security in ongoing support, aligned with the Websites service (launch & support).

Post header
14 giorni fa
2 Minutes

A website does not end on launch day. Without ongoing care, you risk compromised installs, forms that silently break, expired certificates, and CMS or plugin stacks that fail in a chain reaction. The cost is not only technical: it is lost time, reputation, and, in serious cases, exposed data.

Under Websites, the process explicitly includes launch and support: that is where operational continuity belongs, not a handover and disappear.

What maintenance means (and how it ties to the build)

  • Backups: verified copies of the site and database (if any), stored off the primary server, with history that actually helps recovery, not only “last night’s zip”.
  • Updates: CMS core, theme, dependencies, runtime. On plugin-heavy stacks (WordPress-style), discipline is mandatory: staging, release notes, and a rollback plan before touching production when risk is high.
  • Security: HTTPS, sane permissions, 2FA on admin panels where possible, periodic review of accounts and messy shared logins.
  • Monitoring: knowing the site is down or degraded before a customer pings you.

This is not a generic checklist to “ask some vendor”: it is the care package I adapt to your stack when we define what happens after launch.

What we clarify together

When I work with a client (from a lean team to a larger organisation), I prefer to put a few things in writing (even lightly) so grey areas do not linger:

  1. How often backups run and where they live, plus how much history we keep.
  2. Who runs updates, on what cadence, and whether a staging environment exists before production.
  3. How we handle incidents (priority, windows, what the support agreement covers versus ad-hoc work).
  4. What a retainer includes compared to time and materials (restores, fixes after major upgrades, small enhancements).

The goal matches the rest of the project: predictability for you and clear ownership on my side.

What stays on your side (the minimum)

Even with active support, it helps to name one internal owner for domain, DNS, hosting billing, and primary logins, and to use named accounts instead of one immortal shared admin password. These habits speed up incidents and renewals: they do not replace my work; they make it effective.

Takeaway

Maintenance is what makes a site last. I fold it into post-launch support on Websites, because a solid build deserves continuity, not abandonment the day after publication.

If you need a tailored plan for your stack or want maintenance priced into the proposal, see Websites and get in touch.