A store survives peak season when the structural work lands in the quiet months, non-essential changes stop before the rush, and every remaining risk has a named owner. This post sets out the pre-peak checklist we work from, who owns each item, and what a change freeze should and should not stop.
Why peak season changes the rules
Most of the year, a slow page or a late integration costs a little and gets fixed next sprint. In the weeks around a major sale, traffic, campaign volume and the number of site changes all rise together, while the time available to catch a mistake shrinks to hours.
Every marketing decision for peak creates a development requirement. A discount needs pricing logic, a campaign needs a landing page that holds under load, and a new offer needs tracking that records it. When marketing and development plan separately, the gap between them is where peak revenue goes missing.
What has to land before the freeze
Peak trading freezes are not negotiable. A replatform, a migration or a significant template change cannot land in the run-up to your biggest revenue window, so that one constraint shapes the whole year: everything structural moves into the quieter months.
- 01Quiet monthsReplatforms, migrations and template changes land here
- 02Flag ceilingsScaling risk raised months ahead, not sale week
- 03Launch earlyRoom to find breaks while traffic is ordinary
- 04Name ownersEvery checklist item given one of four roles
- 05FreezeTheme changes, new apps, plugins and features stop
- 06Trade in slotsBanners, offers and copy change without a release
- 07Exception routeLive defects fixed, with approver and rollback named
- After peakSupplier changes, with the other structural work
Platforms with a known scaling ceiling are the other early item. We recommend flagging that risk months ahead, not in the week before the sale, because a migration planned under peak pressure is how a bad migration happens.
If you are unsure whether your platform is the real limit, our post on when to migrate your ecommerce platform sets out the test. The answer can point to your setup just as easily as to the platform.
Launch timing matters too. Our applicable development work includes 30 days of corrective maintenance after production launch, and those 30 days cover when a defect is reported, not how fast it is fixed. A release that goes live just before peak leaves little room to find what it broke while the traffic is still ordinary.
The pre-peak checklist, and who owns each item
Before work starts on any engagement we name four roles: the client’s commercial owner, the delivery or specialist owner, a communication coordinator and an escalation contact. One person can hold more than one. The checklist assigns every item to one of them.
| Item | What “done” means | Owner |
|---|---|---|
| Campaign and promotion list | Every promotion listed with its dates, its pricing rule and its landing page | Commercial owner |
| Checkout load test | The real path tested under load: catalogue filters, cart and payment, not a synthetic homepage benchmark | Delivery owner |
| Promotion logic | Each discount, bundle and threshold tried on a staging copy and signed off | Delivery owner builds; commercial owner signs off |
| Landing-page caching | Caching and CDN rules warmed for the specific pages the campaigns will send traffic to | Delivery owner |
| Tracking | Add-to-cart and purchase events checked on every campaign page against real test orders | Specialist owner (analytics) |
| Paid media pacing | Budget pacing and bid strategy planned for the peak days, with stock-aware pausing and daily monitoring | Specialist owner (paid media) |
| Freeze notice | Start and end dates, what is frozen, and who approves an exception | Delivery owner issues; commercial owner approves exceptions |
| Rollback plan | Agreed in writing before the event, not improvised at two in the morning | Delivery owner and commercial owner |
| Escalation path | One contact per side for the event days, with a route for out-of-hours problems | Escalation contact; coordinator keeps the list current |
| Operations | Stock, shipping cut-off dates, returns wording and support cover confirmed | Commercial owner |
The checkout row is the one most often done badly. The pages that break under real traffic are catalogue filters, cart and payment, and those are not the pages most load tests hit.
What a change freeze should and should not stop
A freeze stops non-essential deploys: theme changes, new apps, plugin updates and new features. It should not stop the business from trading. Banners, offers and campaign copy change constantly at peak, so plan them into slots built and tested before the freeze, where they can change without a code release.
A live defect still gets fixed during the freeze, through the exception route named in the notice. Write that route down in advance, with the approver and the rollback step. A freeze with no exception route gets broken informally on the first bad day, which is worse than no freeze at all.
When a new partner before peak is the wrong answer
If your marketing and development suppliers are separate but already share one calendar, one promotion list and one escalation path, keep them through peak. Changing suppliers in the run-up adds exactly the kind of risk a freeze exists to prevent.
Consolidating makes sense when the same failures repeat: campaigns waiting on development work that is not ready, tracking that breaks with each new landing page, and nobody owning the journey from ad to order. Those are ownership failures, not skill failures.
Even then, make the change after peak, in the quiet months, alongside the other structural work. Our eCommerce engagements and performance optimisation work are planned around that calendar.
