I do not think there is a golden standard to follow, however I can share with you my experiences from the past. I have analyzed traffic patterns from web logs

I do not think there is a golden standard to follow, however I can share with you my experiences from the past. I have analyzed traffic patterns from web logs and google analytics to determine the best time of day to schedule maintenance. Problem there is no one likes deploying at 3am! I have added a feature to allow showing a notification banner on websites and mobile apps (typically via a new database entry) and used that to show the scheduled maintenance notice 1 to 2 weeks in advance. In the past on more legacy b2b systems (several hours of downtime) I would even send out email notifications. This is really important if you are going to make an IP address change as customers will likely have to update firewall rules. We would store the notification email list in an external resource / system in case of system outages. Update your SLA to include these policies, add a section that states emergency maintenance may be performed without notice. This is really about implementing SOP / policies and following them. Your long term goal should be to achieve continuous deployment after achieving continuous delivery. This will likely mean removing that 'back office architecture requires downtime' hurdle. On a modern PaaS service you typically deploy to a staging environment, validate, then swap ips (production goes to staging, staging goes to production). And if everything goes to hell swap ips again to essentially roll back. This has become much easier with newer platforms and databases.