The BFCM Readiness Sprint: What To Lock, And In What Order

Black Friday 2026 is Friday, November 27. From today, Wednesday, September 16, that’s 72 days, and 75 days to Cyber Monday on Monday, November 30.

The store-side audit and the twelve-week grid are in the store-side Black Friday readiness checklist. The campaign calendar, the carrier caps and the consent work are in the Black Friday email and SMS send plan. This post is the third piece: the order in which you stop changing your store.

Theme, apps, app embeds, discounts, price rules, flows, inventory settings and support macros don’t all lock on the same day. Freeze them in the wrong order and you undo work you already did, because several of them share limits with each other.

One note on sourcing. Every number here links to the vendor page it came from, and vendor claims are labeled as the vendor’s in the sentence where they appear. The dates are a different matter, and the next section deals with them directly.

Does Shopify tell merchants to freeze code before the sale? No. We checked Shopify’s own BFCM checklist and Shopify’s engineering readiness post, and neither carries a code freeze, theme freeze or app-install freeze recommendation. Shopify’s checklist, updated August 28, 2026, runs 25 steps across seven categories, and its only timeline instruction is to start preparing by early fall or the beginning of November at the latest.

Shopify’s BFCM engineering readiness post describes Shopify’s own internal practice, not merchant guidance. Shopify says it doesn’t treat BFCM as a release deadline and that its architectural changes and migrations happen months ahead of the window. That’s Shopify describing what Shopify does to Shopify.

So every date below is BLKDG’s operating recommendation. Treat it as ours, not as platform policy, and move it to fit your team. What isn’t ours is the mechanism under each rung, and the mechanisms are the reason the rungs sit in this order rather than another.

Shopify’s API versioning documentation states that “Shopify releases a new API version every three months at 5pm UTC on the first day of the quarter,” and that “Each stable version is supported for a minimum of 12 months, with at least nine months of overlap between consecutive versions.” Two dates from that schedule fall inside your BFCM runway.

The 2026-10 version releases on October 1, 2026, which is 57 days before Black Friday. On the day this publishes it’s still a release candidate, so plan against the date rather than the status.

The second date is the one that moves without asking. Version 2025-10 stops being accessible on October 16, 2026 at 15:00 UTC, 42 days before Black Friday. Shopify documents that an app calling an inaccessible version doesn’t error out: the platform falls forward and serves the oldest accessible stable version instead.

That’s a behavior change with no failure signal attached to it, landing six weeks before your busiest weekend. October is when you ask every integration owner which version they pin, and whether they plan to adopt 2026-10 before December. Apps migrate on their own schedule, and you get no merchant-side notice when they do.

Shopify’s bulk operations documentation attaches a second consequence to that answer. On API version 2026-01 and later, each app can run up to five bulk query operations per shop at the same time. On earlier versions each app gets one bulk operation of each type at a time per shop. So the version your export tooling targets decides how many exports that app can run concurrently, which is a reason to settle the version question before the export task rather than after it.

Shopify’s bulk operations page documents two constraints that turn “export everything before we freeze” into a scheduling problem. An operation has to complete within ten days or it’s stopped and marked failed, and the signed result URL expires after one week.

Here’s our arithmetic off that one-week window, not a Shopify statement. An export pulled on Friday, November 13 has a download link that stops working around Friday, November 20, a week before Black Friday. Pull it again on Monday, November 23 and the week runs out on Cyber Monday itself, November 30, so that’s the last pull that covers the whole weekend and it expires the day it stops being needed.

Query shape matters too, and it’s easier to fix in October than in a hurry. Shopify limits a bulk query to five total connections with nested connections capped at two levels, and tells developers to scale the polling interval to the expected data volume.

Shopify caps a store at 25 active automatic discounts, and its automatic discounts documentation is explicit that the ceiling includes app-based discounts. Every promo app that creates automatic discounts spends from the same 25.

That’s why this rung lands a week before the discount lock instead of after it. Count your slots, then install one more promo app, and the count you built the promo calendar on is stale. The app freeze exists to make the discount count durable for the two weeks it needs to survive.

Removals are the harder half, and they belong earlier still. Shopify’s uninstalling apps documentation says some apps add code to the online store theme that isn’t removed automatically on uninstall, and tells merchants to check with the developer for extra steps. It also notes that automations and integrations depending on the app stop working, that previous settings may not restore on reinstall, that some app data can’t be recovered afterward, and that inventory has to be moved or deleted if the app manages stock locations.

Uninstalling a paid app cancels future recurring charges, though the current billing cycle may still bill. None of that is a freeze-week cleanup task. It’s a change with a regression test attached, which is why the store-side checklist puts the cleanup in September and this ladder treats October 16 as the outside date, not the week you’re trying to hold everything still.

App embeds are the reason. A theme app extension is app code that renders inside your theme without you editing your theme, so a theme freeze leaves it entirely untouched.

Shopify’s theme app extension documentation sets enforced ceilings on those extensions: 10 MB across all files, 30 blocks, 100 locale files at 15 KB each, and 100 KB of Liquid across all files. It also publishes two suggested limits that aren’t enforced, under 100 KB of compressed CSS referenced in schemas and 10 KB of compressed JavaScript. An extension that exceeds the enforced content limits fails validation and doesn’t update.

Can you stop an app vendor from deploying during BFCM weekend? No, and it’s worth being honest that this rung has a ceiling. Shopify’s app versions documentation describes an app version as a snapshot of the app’s configuration and all its extensions, and says releasing one replaces the active version served to stores with that app installed. Shopify notes that propagation isn’t instant and can take several minutes to reach app users, and that a developer can revert to a previous version at any time.

So what you actually control is which apps are installed, which embeds are enabled, and the configuration inside them. The freeze artifact for this lane isn’t a lock, it’s a list: every app that touches checkout, cart, discounts or inventory, with a named human at the vendor and a way to reach them on a Friday. The revert path exists, and it belongs to someone else.

One more reason to settle the app roster before November. Shopify’s rate limits documentation sets the GraphQL Admin API calculated query cost at 100 points per second on standard plans, 200 on Advanced, 1,000 on Shopify Plus, and 2,000 on Shopify for enterprise, with a single query capped at 1,000 points regardless of plan. The REST Admin API rate limits run on a different scale entirely: 2 requests per second on standard plans, 4 on Advanced, 20 on Plus and 40 on enterprise, with a bucket of 40 requests per app per store on standard and 400 on Plus.

Those limits apply per app and store combination, so a second app doesn’t draw down the first one’s bucket. A mid-November swap that moves order sync from one app to another, or from GraphQL onto REST, changes your throughput ceiling on the weekend you least want it changed.

How many discount codes can a single order carry? Shopify’s discount combinations documentation sets it at 5 product or order discount codes plus 1 shipping discount code, and doesn’t support more than one shipping discount on an order. The application order is fixed as well: product discounts apply to individual items first, order discounts apply to the revised subtotal after them, and shipping discounts apply last.

Two stacked percentage order discounts each calculate on the original subtotal, so they add rather than compound. Multiple product discounts on the same line item are a Shopify Plus feature.

Codes carry their own ceilings, and both bite at BFCM scale. Shopify’s discount codes documentation limits a single discount code to 100 entitlements across specific customers, products and variants, and exceeding it produces an item-entitlements error. A store can hold 20 million unique discount codes cumulatively, at which point you have to delete codes before creating more. The bulk add mutation accepts a maximum of 250 codes per call and processes them asynchronously, returning a job you poll for created, imported and failed counts.

Shopify’s cap is on active automatic discounts, and the documentation we pulled doesn’t say whether a discount scheduled to start later counts as active before its start date. That gap matters, because start and end dates are the mechanic most BFCM calendars use to avoid a human clicking at midnight, which means your Black Friday set and your Cyber Monday replacement both exist in the admin at the same time.

Resolve it against your own store in October rather than during the weekend. Build the full set, including the Cyber Monday replacements, and read what the admin reports back while there’s still time to consolidate. If scheduled discounts do count, the binding constraint isn’t the peak day, it’s the handful of hours where both sets exist.

Shopify’s Functions input and output documentation publishes fixed limits that apply to every function: a 256 kB compiled binary, 10,000 kB of runtime linear memory, 512 kB of runtime stack memory, and logs truncated at 1 kB. Input query limits run alongside them at 3000 bytes of query size excluding comments, 100 elements on list-type arguments and variables, and a maximum query cost of 30. Metafields whose values run past 10,000 bytes aren’t returned to the function at all, which is a silent omission rather than an error.

The limits that decide your weekend are the dynamic ones. At up to 200 line items a function gets 11 million instructions, 128 kB of function input and 20 kB of function output, and beyond 200 line items those three scale proportionally with the number of cart lines.

Read that allowance against what your function actually does, and this next part is our analysis rather than Shopify’s. The budget grows in proportion to cart lines. Whether your function’s work grows in proportion to cart lines is a property of your code, and a discount function that evaluates every line against every active rule does work closer to lines multiplied by rules.

BFCM carts are the largest carts of your year, which makes the freeze window the right time to run a synthetic cart at several multiples of your biggest real order. That’s a test, not a code change, which is what makes it safe to run inside a freeze.

This is the single strongest argument in the whole ladder for a hard freeze date, and it’s documented by Klaviyo rather than inferred.

Klaviyo’s documentation on unique coupon codes for Shopify describes what happens when you change a coupon’s definition in Shopify after codes have already gone out. Klaviyo’s example is a code originally requiring a $20 minimum purchase, which the merchant later raises to $40 on the underlying Shopify price rule. The codes already sitting in customers’ inboxes are updated to the new definition, and Klaviyo’s own interface doesn’t reflect the change.

Work through the consequence. A margin decision made on Saturday afternoon rewrites the terms of an offer that went out on Friday morning, to people who already read it and decided to act on it. The shopper hits a checkout enforcing a rule their email never mentioned, and the platform you’d check first still shows the original terms.

So the promo freeze is on the Shopify price rule, not on the campaign that carried the code. Once codes are in inboxes, the price rule behind them is a published artifact. Our rule is that price rules behind any live BFCM code stop changing on November 16, and they stay frozen until every code they back has expired, which is usually later than the weekend itself.

Shopify’s theme publishing documentation describes publishing as a swap: the theme that was published moves into the Draft themes section, and theme changes aren’t lost in the move. That same page sets the library maximum at 20 themes per store with one published at a time. So getting back to your pre-BFCM theme is a publish, as long as the pre-BFCM theme still exists, and that’s the condition the freeze has to protect.

There’s a ceiling on it. Shopify’s theme duplication documentation says that at 20 themes you have to delete one before you can duplicate another, and its stated reason to duplicate before customizing is to keep a backup you can discard your changes against.

Count your library now. A store sitting at 19 or 20 themes in mid-November is a store that has to delete something before it can take a backup, and deleting under time pressure is how the rollback target disappears.

One more theme behavior belongs in the freeze conversation. Shopify documents that code changes made to a theme are removed when they’re incompatible with a theme update, so a theme update during your freeze window isn’t a neutral act on a customized theme.

Launchpad is available only on the Shopify Plus plan. Per Shopify’s Launchpad documentation, an event can:

The considerations page is where the scheduling work actually lives. You can’t run or schedule overlapping events, an event has to begin at least five minutes after the previous one ends, and no collection in an event can hold more than 1000 products.

One clause reorders the whole build. An open-ended event has to be edited to end before a new event can begin, so an open-ended Black Friday event blocks you from scheduling the Cyber Monday event behind it at all. Every event in the chain needs an end time before any of them can be laid out, and that’s a build task for the week of November 16, not something you resolve on Friday.

Three documented behaviors decide what your event actually charges. Prices revert to their pre-event value when an event ends. Adding products to a collection mid-event doesn’t apply the discount to them, and removing products doesn’t remove discounts already applied. Compare-at prices temporarily change to pre-sale regular prices during an event and restore afterward, and percentage discounts calculate on regular prices rather than compare-at prices.

Two more to design around. Discounting a gift card inside an event reduces both its price and its value. And if your store already runs a password page, activating one through Launchpad removes the store’s own page when the event begins and doesn’t restore it when the event ends, so someone has to put it back by hand.

Shopify’s Launchpad help pages still list Shopify Scripts among the things an event can schedule, including a suggestion to use a script to stop discount codes stacking on Launchpad sale prices. Shopify Scripts stopped executing on June 30, 2026, which we covered in the store-side readiness checklist. The documentation is stale, not the platform, so open any Launchpad event you reused from last year and check what its steps actually reference before you lock it.

Klaviyo documents that flow statuses can be scheduled to update at a specific date and time rather than immediately, with a date, time and timezone picker, and that a single flow can hold multiple scheduled changes. Its bulk flow status documentation also names the exception: flow status scheduling isn’t available for date-property triggered flows.

That turns the flow freeze into an artifact you build once and audit, rather than a sequence of clicks someone performs at 6am on Black Friday. Set the freeze and the thaw in the same sitting on November 16, and everything except your birthday and anniversary flows handles itself. Those are date-property triggered, so they need a human, and they’re the ones to write on a card.

What actually happens when you edit a flow mid-sale? Klaviyo’s documentation on managing messages within a flow states that “Any message in an existing flow can be edited regardless of its status, so you can make live updates without pausing sending,” and that “Updates to the sending status are effective immediately for all new individuals entering your flow.” The same page is equally clear about who the edit misses: “If you update the time delay before an email, those already scheduled in the Waiting bucket will not be rescheduled.”

So a flow fixed on Friday morning is fixed for people who enter it after Friday morning, and not for the population already moving through it. The size of that population on Black Friday is the entire reason flow states are a November 16 decision instead of a weekend one.

Klaviyo publishes three sending statuses and defines them narrowly. Draft queues no recipients. Manual queues recipients but sends nothing automatically, marking messages for review instead. Live queues recipients and sends automatically.

Klaviyo’s documentation on pausing an individual flow message puts the difference plainly: “Both statuses will pause email and SMS sending. If you don’t want contacts to be queued to receive the email or SMS, you can instead set the sending status to draft. Messages in manual will continue to queue recipients, so if you would like to later send to these contacts, we recommend setting the status to manual.” It adds that “In manual mode, recipients will continue through the flow, even if the paused message is not sent manually to them.”

Apply that to a price drop flow during a sitewide markdown. Draft it on November 16 and everyone who would have entered during the sale is gone. Set it to manual and you hold a reviewable list you can release on December 1.

The manual route isn’t free, and Klaviyo documents the cost. Per its documentation on manually sending flow messages, sending to a contact sitting in Needs Review who no longer meets the flow’s filters results in that contact being skipped. So manual preserves the audience, not a guarantee that the audience still qualifies two weeks later. Some of the December 1 release will skip, and that’s the correct behavior rather than a failure.

One related move costs more than it looks like it does. Klaviyo’s documentation on cancelling a scheduled flow email for a single recipient states that cancelling for one person removes them from the flow entirely, so they don’t progress to other steps or receive any remaining message in the sequence. A one-off cancellation during the weekend is a permanent exit from the sequence, not a skip of one send.

Klaviyo’s Smart Sending documentation sets default windows of 16 hours for email and 24 hours for both SMS and push, and states that skipped messages aren’t rescheduled automatically. Klaviyo also documents that changing a window isn’t retroactive, so profiles already under a longer timer stay there.

That makes the window a dated act with a lead time rather than a send decision. It has to be executed before the first send it governs, which puts it on this ladder instead of on the send calendar. The cadence argument itself belongs to the Black Friday send plan, and we’re not re-running it here.

Bulk data loads belong before the freeze for a capacity reason. Klaviyo’s rate limits documentation sets per-account limits across two fixed windows, a one-second burst and a one-minute steady window, running from 1 per second and 15 per minute on the XS tier up to 350 per second and 3,500 per minute on XL. Klaviyo returns a 429 with a Retry-After header on violation, recommends an exponential backoff schedule with some randomness built into it to avoid a thundering herd, and says to retry only after the seconds named in Retry-After have elapsed.

Your pre-BFCM list import and your live event stream draw on the same per-account budget. Run the import in the week of November 9 and it competes with nothing. Run it during the sale and it competes with every order and browse event you’re sending.

The recovery path from a bad send is narrower on one channel than the other, and Klaviyo documents the asymmetry. Its resend documentation states: “You can only resend emails in Klaviyo, and not SMS/MMS.”

The same page limits resends to messages marked sent or skipped, rules out resending anything currently scheduled or cancelled, and allows resending only one message at a time. So even on email, the recovery is manual and per-message rather than a bulk correction.

We freeze SMS content and SMS flow states a full business day ahead of email for that reason. Compliant SMS setup carries its own lead times, which we covered in our guide to compliant SMS for ecommerce, and none of that work gets faster in November.

One Shopify setting converts a stockout into an oversell, and it’s set one variant at a time. Shopify’s selling when out of stock documentation describes the “Continue selling when out of stock” option as a per product or per variant control in the Inventory section that requires inventory tracking to be on.

The same page documents the failure in the other direction. If a location that fulfills online orders holds zero or less, the item reads as out of stock on your online store even when another location that doesn’t fulfill online orders is holding inventory. A variant can show sold out during your biggest weekend while the stock sits somewhere you never enabled.

If the remediation is a bulk edit, Shopify’s product import documentation caps the product CSV at 15 MB, and doesn’t document a row count, image count or duration limit on that page. The deeper structural work, including multi-location routing, is in our guide to Shopify inventory management through peak.

This rung goes before the freeze rather than inside it, because a catalog-wide toggle audit is a change to product data and product data is one of the things you’re about to stop touching.

From November 16, the same Monday the store-side checklist freezes theme and code, our rule is that the only permitted changes are activation and content: turning on a discount you already built and tested, swapping banner copy and imagery, and changing product availability. That list stays open right through Cyber Monday.

Monitoring is the other thing that stays live, and it needs its own instrument rather than a vendor dashboard. Shopify Status publishes nine components, Admin, Checkout, Reports and Dashboards, Storefront, API & Mobile, Third party services, Support, Point of Sale and Oxygen, and carries a caveat in its footer.

On September 14, 2026 every one of those components read Operational with no incidents across the fifteen days shown, which is a snapshot rather than a standing condition. Read the caveat as the design requirement it is: Shopify Status is a monitoring input, not ground truth about your store, so your BFCM plan needs a checkout canary of your own running against your own storefront.

There’s one response type to rehearse before you’re relying on it. Shopify’s rate limits documentation notes that checkout creation on the Storefront API is throttled per minute, and that a client exceeding the throttle receives a 200 Throttled error response. Shopify recommends designing the app to be resilient to it and gives a request queue with exponential backoff as the example.

That’s an HTTP 200, so a client branching on status code alone reads a throttled checkout as a successful one and shows the shopper nothing. The store-side checklist covers the failure mode itself. The freeze-window job is narrower: prove your checkout client parses the response body and surfaces something to the buyer, then leave the code alone. Shopify doesn’t publish the numeric value of that throttle, so there’s no capacity model to build here, only a handling path to verify.

Neighboring response codes behave more conventionally. Throttled Admin API requests return 429 with a recommended backoff of one second, and requests Shopify reads as malicious return 430 Shopify Security Rejection. Shopify also states that “The Storefront API is designed to support businesses of all sizes, and scales to support surges in buyer traffic or your largest flash sale. Requests from real buyers aren’t subject to a fixed request-per-minute limit,” while automated traffic is rate-limited separately.

One resource throttle is worth checking against your catalog. Shopify documents that “The following GraphQL Admin API types have an additional throttle that takes effect when a store has 500,000 product variants. After this threshold is reached, no more than 10,000 new variants can be created per day,” applying to productCreate, productUpdate and productVariantCreate, and adds that “These additional limits don’t apply to stores on the Shopify Plus plan.”

We looked for vendor documentation on helpdesk-side freeze mechanics, macro locks, auto-responder windows and peak staffing, and found none. So everything in this paragraph is BLKDG operating advice rather than a sourced platform behavior, and you should weigh it accordingly.

Our practice is to lock support macros on the same day the price rules lock, on November 16, because a macro that quotes a discount’s terms is a published statement of those terms in exactly the way an emailed code is. Write the escalation path down in the same pass: who can deactivate a discount, who can reach each app vendor, and who decides when a canary failure becomes an incident.

A freeze with no scheduled end gets lifted by feel in the second week of December, in pieces, with no record of which locks came off when.

Build the thaw on November 16 in the same sitting as the freeze, because Klaviyo lets you schedule the return as easily as the pause. Set the flow statuses to revert on Tuesday, December 1, and handle the date-property triggered flows by hand since scheduling isn’t available for those. Then work the Needs Review queue for anything you set to manual, expecting some profiles to skip because they no longer meet the flow’s filters.

Two locks outlast the weekend. The price rules behind live codes stay frozen until those codes expire, because the retroactive edit behavior doesn’t care that the sale ended. And the pre-freeze export link expires a week after you pull it, so a fresh pull on November 23 is what carries you through Cyber Monday.

Everything else comes off in the order it went on, starting with the theme, because that’s the lock with the one-click rollback underneath it.

Seventy-two days to Black Friday, and the work between here and there is mostly subtraction. Confirm your API versions in October, finish app removals before anything depends on them, lock the discount architecture after the app roster is stable, freeze the price rules behind every code you’ve emailed, and schedule the flow freeze and the thaw as one dated artifact rather than two decisions made under pressure.

None of that requires a platform to tell you to do it, which is fortunate, because no platform does. What the platforms do publish is the behavior underneath each lock: the version that falls forward without telling you, the 25 slots your apps share with your promo plan, the price rule that rewrites an offer already sitting in an inbox, and the flow edit that leaves everyone already mid-flow on the old version.

If you want an outside read on which of those are currently live in your store, that’s what our free Growth Audit is. Not a sales call. Not a quote request. A clear look at what’s configured, what’s about to collide, and what’s still cheap to change.

You built something worth finding. Seventy-two days from now, make sure it holds.