OPERATIONS · PERFORMANCE · SHOPIFY PLUS · 2 JUNE 2026 · 6 MIN READ
Peak planning starts in May
Not because the work takes six months. Because anything structural needs a full trading cycle in production to prove, and there is no staging environment that generates your November.
In May, for the structural work — and if you are reading this in early June you are close enough. The reason is not that a replatform or an integration rebuild takes six months of effort. It is that a change of any size needs a full trading cycle running in production before you can believe it, and the only place to get that cycle is the quiet summer you are currently in. Ship something risky in June and a fault surfaces in July, costing you an ordinary Tuesday. Ship the same thing in October and the fault surfaces in November, costing you the quarter. Everything that arrives later than August should be small, reversible and boring.
IN SHORT
- The constraint on peak work is not effort, it is evidence: a change needs weeks of real orders and real traffic before anyone can say it holds.
- The lead times that actually bind are the ones with a counterparty — 3PL onboarding, carrier rate negotiations, stock, seasonal hiring and your customer's security review — and none of them compress because you asked nicely.
- Shopify "releases a new API version every three months at 5pm UTC on the first day of the quarter", so the October version lands exactly when you least want to be touching an integration.
- Each stable API version is "supported for a minimum of 12 months, with at least nine months of overlap between consecutive versions" — enough runway to do an upgrade in summer rather than in a panic.
- If an app targets an inaccessible version, "Shopify falls forward and responds using the oldest accessible stable version" — a silent behaviour change is a worse peak incident than a hard failure.
- Cancelling a project costs almost nothing in May and costs the season in October, so May is when the decision to not do something is cheapest.
- By October the work is a readiness checklist, not a roadmap; if it is already autumn, plan for the freeze rather than for the build.
Duration is not the reason
The usual argument for starting early is that the work is big. That argument is weak, and everyone knows it, which is why it loses to whatever is urgent in June. Most peak projects are genuinely a few weeks of build. You could start a checkout revision in September and have it finished by the middle of October.
The real argument is different: you would have no idea whether it worked. A new fulfilment integration looks fine on the day it ships and reveals itself three weeks later, when a specific combination of a partial refund, a split shipment and an exchange puts a row through in the wrong order. A theme change passes review and then turns out to break for customers on one browser version you do not test. These are not bugs you find by testing harder. They are bugs you find by trading.
So the thing you are buying by starting in May is not build time. It is *observation* time — a stretch of real orders, at real volume, with real customers doing the things nobody thought of, followed by enough weeks to fix what surfaces and observe again. Two cycles of that is a summer. One cycle is a gamble. Zero cycles is what most stores actually do, and it is why the same conversation happens every December.
The lead times you do not control
Your own engineering calendar is flexible. The people you depend on are not, and their constraints do not appear on your project plan until they bite.
- Third-party logistics. Onboarding a new 3PL is a contract, an integration, a stock transfer and a period of running both. Warehouses also stop accepting new clients before peak, which is a constraint you discover by asking in September and being told no.
- Carrier rates and capacity. Negotiated for the season, well before the season, by people whose calendar fills up.
- Stock. Orders placed now arrive for peak; orders placed in September arrive for the January sale, at which point they are markdown.
- Seasonal hiring. Customer service headcount for November is recruited and trained months before November, and the training is the part that gets cut.
- Procurement and security review. If you sell B2B, or you are buying software that touches customer data, somebody else's legal and security process sets your timeline. Six weeks is not unusual and you cannot escalate it.
The platform has a calendar too
Shopify's own release rhythm is public and it is worth planning against rather than reacting to. The documentation states that Shopify "releases a new API version every three months at 5pm UTC on the first day of the quarter". That puts a release on the first of October — the precise week most merchants have decided to stop changing things.
The good news is that the support window is generous enough to make this a planning problem rather than an emergency. Each stable version is "supported for a minimum of 12 months, with at least nine months of overlap between consecutive versions", and deprecations follow the same pattern: something deprecated in one release "might be removed" a release or two later. You are not being rushed. You are being given a window, and summer is the comfortable end of it.
The failure mode to avoid is drifting past the window. Shopify documents that if an app targets an inaccessible version, "Shopify falls forward and responds using the oldest accessible stable version". Read that carefully: an integration left on a dead version does not stop with an obvious error. It keeps working, against a different version, with fields that may behave differently — which is exactly the kind of quiet wrongness that takes three days to diagnose while orders queue. Check what version every integration pins, in June, when finding out is free.
The same applies to the platform features you are counting on. Shopify announces substantial changes on its own schedule, and the summer announcements are your first real look at what will and will not be available for the season. Reading that release and deciding what to act on is a June activity; discovering in October that the thing you assumed was coming has not shipped is a planning failure dressed up as bad luck.
What belongs in which month
A rough backward plan. The point is not the exact months — your peak may be in May if you sell garden furniture — but the sequence and the shrinking size of the allowed change.
- May to June: decide and start the structural work. Replatforming, a theme rebuild, an ERP or WMS integration, a checkout change, a new 3PL. Anything that cannot be reverted in an afternoon starts here or does not happen this year.
- June to July: ship it and trade on it. This is the cycle you started early to buy. Resist the urge to immediately start the next thing; the value is in watching this one.
- July to August: fix what the trading found, and confirm the lead-time items. Carrier rates, stock, hiring, 3PL capacity. Also: audit the API versions every integration pins, and upgrade anything close to its window.
- September: performance, apps and instrumentation. Removing apps, image and script work, checking what is actually on the page, and making sure your monitoring will tell you something useful at 2am. Changes here should be subtractive.
- October: readiness, not building. The freeze, the runbook, the oversell policy, the incident roles, the rehearsal. If you are considering a structural change now, the advice is not to.
- November to December: trade, and write down what broke. The list you make in December is the input to next May, and it is worth more than any planning session, because it is the only one based on evidence.
The decision that is only cheap in May
The most valuable output of starting early is not a finished project. It is the ability to cancel one.
In May, deciding not to do the replatform costs a few days of scoping and a slightly awkward conversation. In August it costs a half-built thing and a sunk budget. In October it costs the season, because by then the alternative plan needed to have started in May. The option to say no has an expiry date, and it expires quietly.
This is why we push clients to make the big decision first and the detailed plan second, rather than the other way round. A team that spends May and June scoping, and commits in July, has converted its cheapest cancellation window into a document. The decision is the thing that has to happen in May; the scoping can happen after it, under a commitment, with a deadline that means something.
It is also why the honest recommendation in most Mays is to do less than the list suggests. A store that ships one structural change, trades on it for two months, fixes what surfaces and then spends September removing apps will go into peak in better shape than one that attempted four things and is still testing the third in October. Peak does not reward ambition. It rewards a store where everything on it has already survived a quiet week.
If it is already August
Then this post is a note for next year, and the useful move now is to change what you are optimising for. Stop asking what you can build and start asking what you can remove, measure and rehearse — all three of which are fast, reversible and reliably worth more than a feature.
Pick the one structural thing that genuinely cannot wait, if there is one, and ship it by the end of the month so it gets September as its trading cycle. Put everything else on the January list. Then move to the readiness work: the code freeze, the runbook, the decisions about what you will do when something fails, and the rehearsal of who does what. That work has a much better return per hour in the autumn than anything you could build, and it is the subject of its own post.
Questions this raises
When should I start planning for peak season?
Structural decisions in May, structural work shipped by the end of July, performance and app removal in September, and readiness — freeze, runbook, rehearsal — in October. The driver is not effort but evidence: a change needs a full trading cycle in production before you can trust it, and summer is where that cycle lives.
Is it too late to replatform before Black Friday if I start in August?
Almost certainly, and the reason is not the build. A replatform that launches in September has no quiet period to trade through, so every fault it contains will be found by real customers during your highest-revenue weeks. Launch in January instead and use the autumn for performance work and readiness.
What can I safely still change in October?
Content, merchandising, copy and campaign pages — things that revert in minutes. Not checkout, not fulfilment integrations, not the theme's architecture, not a new app that injects scripts into the storefront. The test is whether one person can undo it in an afternoon without a deployment.
Does Shopify's API release schedule matter for peak planning?
Yes. Shopify releases a new API version every three months on the first day of the quarter, which puts one on 1 October. Each version is supported for at least 12 months with at least nine months of overlap, so integration upgrades are comfortably a summer job. Leave it and an app on an inaccessible version will not fail loudly — Shopify falls forward to the oldest accessible stable version, and you get subtly different behaviour instead of an error.
What should I do first in May?
Read December's incident notes, list every integration and the API version it pins, ask your 3PL and carriers what their cut-off dates are this year, and decide the one structural change you will make. Four things, a week of work, and they determine most of what the rest of the year can contain.
How much of peak planning is technical?
Less than half. The items with the longest lead times are commercial and operational — stock, carrier capacity, warehouse onboarding, seasonal hiring and training. Engineering work can be compressed in an emergency; a warehouse that has stopped taking new clients in September cannot be.
NEXT STEP
Free store audit
A senior Shopify engineer reviews your storefront, theme performance and checkout, then sends a prioritised list of fixes.