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

Black Friday 2026 is Friday, November 27. Counted from 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. The third piece is 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.

Does Shopify tell merchants to freeze code before the sale? No. Shopify’s own BFCM checklist runs 25 steps across seven categories, and none of them recommends a code freeze, theme freeze or app-install freeze. Its only timeline instruction is to start preparing by early fall or the beginning of November at the latest.

What Shopify has published about its own BFCM engineering readiness (opens in new tab) is 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.

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 releases a new API version every three months (opens in new tab) at 5pm UTC on the first day of the quarter. 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 was released on October 1, 2026, which is 57 days before Black Friday.

The access cutoff for version 2025-10 is October 16, 2026 at 15:00 UTC, 42 days before Black Friday. 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.

On API version 2026-01 and later, each app can run up to five bulk query operations per shop (opens in new tab) 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 carry 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 the ceiling includes app-based discounts (opens in new tab). 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. Some apps add code to the online store theme that isn’t removed automatically on uninstall (opens in new tab), and Shopify tells merchants to check with the developer for extra steps. Automations and integrations depending on the app stop working, previous settings may not restore on reinstall, some app data can’t be recovered afterward, and 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 sets enforced ceilings on those extensions (opens in new tab): 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 this rung has a ceiling. An app version (opens in new tab) is a snapshot of the app’s configuration and all its extensions, and releasing one replaces the active version served to stores with that app installed. Propagation isn’t instant and can take several minutes to reach app users, and 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.

Shopify limits the GraphQL Admin API’s calculated query cost (opens in new tab) to 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 (opens in new tab) 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 sets it at 5 product or order discount codes plus 1 shipping discount code (opens in new tab), 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 limits a single discount code to 100 entitlements (opens in new tab) 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 (opens in new tab) 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, so check whether a discount scheduled to start later counts as active before its start date. It matters, because start and end dates are the mechanic that saves 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 Functions carry fixed limits that apply to every function (opens in new tab): 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.

Change a coupon’s definition in Shopify after Klaviyo’s unique coupon codes (opens in new tab) have already gone out, and the change reaches the codes already sent. Take 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.

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.

Publishing a Shopify theme (opens in new tab) is a swap: the theme that was published moves into the Draft themes section, and theme changes aren’t lost in the move. The library maximum is 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. At 20 themes you have to delete one before you can duplicate another (opens in new tab), and Shopify’s 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.

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. A Launchpad event (opens in new tab) can:

You can’t run or schedule overlapping events (opens in new tab), 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.

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.

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.

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.

Launchpad events built for earlier sales can include steps that enable Shopify Scripts. Shopify Scripts stopped executing on June 30, 2026, which we covered in the store-side readiness checklist. Open any Launchpad event you reused from last year and check what its steps actually reference before you lock it.

Klaviyo flow statuses can be scheduled to update at a specific date and time rather than immediately, with a date, time and timezone picker, and a single flow can hold multiple scheduled changes. There’s one exception: flow status scheduling isn’t available for date-property triggered flows (opens in new tab).

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? In Klaviyo, any message in an existing flow can be edited (opens in new tab) regardless of its status, so you can make live updates without pausing sending. Updates to the sending status are effective immediately for all new individuals entering your flow. The edit misses people already waiting: if you update the time delay before an email, those already scheduled in the Waiting bucket won’t 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 has three sending statuses. Draft queues no recipients. Manual queues recipients but sends nothing automatically, marking messages for review instead. Live queues recipients and sends automatically.

Both manual and draft pause email and SMS sending (opens in new tab). 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 continue to queue recipients, so Klaviyo recommends manual if you’d like to send to those contacts later. In manual mode, recipients continue through the flow, even if the paused message isn’t 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. Sending to a contact sitting in Needs Review (opens in new tab) 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.

Cancelling a scheduled flow email for a single recipient (opens in new tab) 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 (opens in new tab) defaults to windows of 16 hours for email and 24 hours for both SMS and push, and skipped messages aren’t rescheduled automatically. 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 is in the Black Friday send plan.

Bulk data loads belong before the freeze for a capacity reason. Klaviyo sets per-account rate limits (opens in new tab) 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. You can only resend emails in Klaviyo (opens in new tab), and not SMS/MMS.

Resends are limited to messages marked sent or skipped, anything currently scheduled or cancelled can’t be resent, and only one message can be resent 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. The “Continue selling when out of stock” (opens in new tab) option is a per product or per variant control in the Inventory section that requires inventory tracking to be on.

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, the product CSV is capped at 15 MB (opens in new tab). 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.

Read the caveat as the design requirement it is: Shopify Status (opens in new tab) 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.

Checkout creation on the Storefront API is throttled per minute, and 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 says 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. When a store has 500,000 product variants, an additional GraphQL Admin API throttle takes effect on productCreate, productUpdate and productVariantCreate: after that threshold is reached, no more than 10,000 new variants can be created per day. These additional limits don’t apply to stores on the Shopify Plus plan.

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.

The work between here and Black Friday 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. 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. A clear look at what’s configured, what’s about to collide, and what’s still cheap to change.

You built something worth finding. On November 27, make sure it holds.