Before peak season: a change freeze in the maintenance plan

A single freeze date for everything is the most common design - and the least practical one. Content and pricing have to stay movable in December, otherwise the shop cannot react to a short-notice offer. A theme update, by contrast, serves no purpose from mid-November onwards. The calendar therefore separates by change class, not by system. Where exactly the dates sit is answered better by last year's own revenue curve than by any industry figure. The industry supplies the order of magnitude: for November and December the German Retail Federation expected 22.2 billion euros in online retail turnover, nominally 3.3 percent more than the year before (HDE forecast, November 2025).

The table below shows a classification that has proven itself in small and mid-sized shops. More important than the exact number of classes are three fields per row: from when the class rests, who decides on an exception, and which way back was rehearsed beforehand. Without the third field the calendar is a statement of intent. Which work a running maintenance package already covers is shown in the overview of services - the change calendar belongs on the same line there as the maintenance window.

Two rows deserve a second look. The infrastructure class rests earliest because its faults surface latest: a certificate expiring in December does not report itself at deployment time, it reports itself on the expiry date. And the extensions class needs an inventory before the freeze, because it usually contains more than the shop owner keeps in mind - test systems, stale subdomains and forgotten installations all belong to the same attack surface. How that inventory is cleaned up is described in the article on forgotten test systems and stale subdomains.

The exception path is not an emergency exit, it is a second, narrower procedure. It differs from the normal route in four points: the trigger is defined more narrowly, the decision sits with a named person instead of a committee, the test run is shortened but not dropped, and the written record is more detailed than usual. Anyone who couples this path to on-call cover has built half of it already - in emergency support reachability, decision authority and record-keeping are already one process.

The trigger is what decides. Define it too broadly and every request travels down the exception path, leaving the freeze without effect. Define it too narrowly and an exploited gap stays open for three weeks. In practice a combination of two conditions works: the vulnerability is exploitable in the state actually deployed - not merely present in the product - and it affects a path the shop offers publicly. Together those two are rare enough to keep the calendar and frequent enough to catch the cases that matter.

The file belongs in the same repository as the rest of the configuration, so that every change to the calendar is a change with a history. Two fields are easy to overlook. The timezone keeps a freeze in a distributed chain from slipping by an hour, especially after the changeover at the end of October. And notify makes sure the shop owner learns about an exception before spotting it in the figures. Whether the exception worked is then shown by ongoing shop monitoring - a change without a follow-up measurement is a bet in December.

One point comes up regularly in discussion: does content really belong in the calendar if it keeps running anyway? Yes, but with a different field. For content the interesting value is not the freeze date but the way back within the session. Anyone rebuilding a category page and removing a filter changes what is delivered just as a developer does. The difference is that an editor can take that way back inside the admin interface, provided versioning is switched on. That is exactly what should be tried once before the freeze, not assumed.

The most unpleasant mistake in a change freeze is not the overly strict rule, it is the overlooked deadline. A deadline does not negotiate: it expires while the freeze is running and forces exactly the change that was meant to be avoided. The list below collects the deadlines that regularly fall into December in this environment. It is worked through in October, every item gets a date, and every date between the start and the end of the freeze is pulled forward or extended.

One deadline deserves its own line, because it is not a maintenance topic and still hangs on the technology. German VAT law permits paper for turnover in 2027 only until 31 December 2027, and only where total turnover in the preceding calendar year was no more than 800,000 euros (Section 27 (38) no. 2 of the German VAT Act). For everyone above that, the paper option ends with the turn of the year. A differing electronic format stays possible alongside it for the same period without any turnover threshold, provided the recipient consents and the invoice is transmitted via EDI (Section 27 (38) no. 3 of the German VAT Act). Anyone planning the switch for January is planning it directly behind the freeze - what the shop needs to be able to do is covered in the article on e-invoicing from 2027.

The third preparation is the least conspicuous one: headroom. In December it is not only the number of orders that rises, but also the volume of what the shop produces along the way - session data, search logs, invoice documents, images in several formats, caches. A full volume is an outage that looks like a database fault and gets hunted in the wrong place for hours. How to find that limit in advance is described in the article on load testing for peak traffic.

For practical purposes four measurements are enough, taken once in October and monitored afterwards: free space on the volume holding order data, free space on the volume holding backups, CPU utilisation in the peak hour, and memory used by the database. More important than the absolute value is the slope. A volume losing two percentage points a week is arithmetically full by the end of the freeze, even if twenty percent are still free today.

The report is deliberately boring. Its purpose is the headroom in weeks, not the percentage: only the headroom connects today's level with the date on which the freeze ends. The two alarms in this example are the normal case - in practice certificates and licenses show a preference for expiring between Christmas and New Year, because a year earlier they were set up between Christmas and New Year.

For the calendar to hold in December it belongs in the maintenance contract, not in an email. Four points are enough: the period of the freeze with its start and end, the classification of change classes with their freeze dates, the exception path with a named decision-maker and an obligation to record, and the on-call plan with its windows and alert types. How these points are usually worded and tied to response times is shown in the overview of the SLA maintenance contract.

A fifth point is often forgotten and is the only one that counts retrospectively: the record of the maintenance state before the freeze. It captures which versions were running on the cut-off date, which backups were last rehearsed and with what result, and which deadlines were deliberately extended beyond the freeze. In a dispute this record is the basis for showing that a change did not take place in December - in the normal case it is the template for next year's calendar.