Some downtime is unavoidable and planned — a server migration, a major software upgrade, an electrical shutdown in the building. Planned downtime handled well is a non-event. Planned downtime handled badly generates more complaints than an unplanned outage of the same length, because customers feel it was done to them rather than to everyone.
The difference is almost entirely in the scheduling and the communication.
Find your genuine quiet period
The default assumption is that late nights and weekends are safest. For many Australian businesses that is wrong. A B2B services firm has almost no traffic at 2am but has an accountant on the East Coast working Sunday evening. A hospitality business is busiest exactly when the office is closed.
Do not guess. Pull twelve months of analytics and find the hour with the lowest genuine activity, then check it against your own operational calendar — end of month, end of quarter, and any period where a customer is relying on you for a deadline.
Also avoid the Friday afternoon trap. Work that finishes at 5pm Friday is work whose problems surface over a weekend when nobody is available. Tuesday and Wednesday evenings are the sensible default for anything with meaningful risk.
Tell people properly
Notification should be proportionate. A ten-minute restart needs a banner. A four-hour migration that affects customer logins needs an email a week out, a reminder the day before, and a status page during.
Say four things: what will be unavailable, exactly when in local time with the time zone stated, how long you expect it to take, and what someone should do if they need help during the window. Vague notices — “scheduled maintenance may affect some services” — generate more support contact than specific ones, because uncertainty makes people ring to check.
Build a buffer into the announced window
Announce a window longer than your estimate. If you believe the work takes ninety minutes, announce three hours. Finishing early is a positive; overrunning an announced window destroys confidence and turns a planned event into a perceived incident.
The buffer also protects your decision-making. A team working against an announced deadline that has already passed makes rushed choices.
Have a defined abort point
Before you start, decide the time at which you stop and roll back rather than push on. Write it down and give someone the authority to call it. The failure pattern here is well documented: an upgrade goes wrong, the team is nearly there, and “nearly there” consumes six hours and turns a three-hour planned window into a full-day outage.
An abort point only works if the rollback has been tested. Confirm the backup restores before you begin, not after you need it.
Watch it come back properly
The end of the work is not the end of the window. Services can return in a state that looks healthy but is not — a queue not processing, a scheduled job that did not restart, mail flowing but not being delivered.
Have your checks running through the window and for a period afterwards, and walk the critical customer path manually before declaring it complete. This is where continuous monitoring earns its keep — you get objective confirmation that things are back rather than an impression. For website work specifically, pairing the window with a tested plugin and update rollback process means an abort decision is a two-minute action rather than an improvisation.
Close it out
Tell people it is finished. A short message confirming completion costs nothing and stops the trickle of customers who saw the warning and are still unsure.
Then write down what took longer than expected and what you would do differently. Most organisations run the same categories of maintenance repeatedly, and the second migration should be easier than the first — but only if someone recorded what happened during the first one.