How to Scale Brewery Operations Across Multiple Sites

The jump from one brewhouse to two isn't a doubling. It's a re-architecture. Everything that used to live in someone's head — which yeast pitch goes where, whose call it is to release a batch, what the exact recipe is for your flagship IPA — suddenly has to survive being copied, shipped, and re-run by people who weren't in the room when you figured it out the first time.

Most breweries scale by accident. They open a second location or bring on a co-pack partner, then spend the next 18 months discovering all the coordination problems nobody planned for. The recipes drift. Lot codes stop matching. A recall drill reveals that Site B can't tell you which retailers got a specific batch. None of this is exotic — it's the predictable result of scaling a system that was never designed to be scaled.

This piece covers the three scaling models breweries actually use, the master-data work that has to happen before any of them function properly, the inter-site transfer SOPs that keep product moving cleanly, and the recall and traceability governance that keeps a two-site operation from becoming a legal liability.

The three scaling models, compared

Before you argue about software or org charts, you need to decide how your sites relate to each other. There are basically three patterns, and picking the wrong one causes more damage than any tooling decision.

Hub-and-spoke means one primary site owns brewing, recipes, and QC standards. Satellite sites package, condition, or serve — but they don't originate product decisions. Think of a production brewery feeding a couple of taproom-only or packaging-only locations.

Mirrored means each site is a near-identical full brewery. Same equipment classes, same recipes, same SOPs, capable of producing the same SKUs independently. This is what regional breweries build when they want geographic redundancy — West Coast site and Midwest site both brewing the flagship.

Hybrid is the messy real world: a main production hub, one mirrored full-production site, and a couple of spokes doing packaging or taproom service. Most breweries end up here whether they planned to or not.

The pattern worth noticing: hub-and-spoke fails from congestion, mirrored fails from divergence, and hybrid fails from ambiguity. Each model has a signature way of breaking, and if you know yours going in, you can build the guardrails before it bites.

When each model actually makes sense

Hub-and-spoke makes sense when your bottleneck is reach, not production. You've got a beer people want and you need it closer to more markets, or you want more taproom revenue without duplicating an expensive brewhouse. A brewery doing around 12,000 bbl a year that wants two more taprooms in nearby metros doesn't need three brewhouses. It needs one strong hub and clean logistics.

Mirrored makes sense when freight is eating you alive or when a single-site failure would be existential. If you're shipping heavy liquid across half the country, standing up a second full brewery closer to those customers can pay for itself on logistics alone. But you only earn that payoff if the beer is genuinely identical — and that's harder than it sounds.

Hybrid makes sense for almost everyone growing organically, because you rarely add capacity in clean, symmetrical increments. You add a taproom here, take on a co-packer there, then finally build a second real brewhouse. The danger isn't the hybrid shape itself. It's pretending you have a clean hub-and-spoke when you're actually running a hybrid nobody has mapped.

Who should NOT run a mirrored model

If your recipes still live partly in a head brewer's intuition — the "I just know when it's ready" school — do not go mirrored. You will spend a fortune building an identical brewhouse and then produce two different beers. Mirrored only works after you've made your process boringly explicit: documented pitch rates, defined fermentation curves, hard QC release specs. If you can't hand your flagship recipe to a stranger and get the same beer back, you're not ready to duplicate it.

Master data: the thing that breaks first

The uncomfortable truth about multi-site brewery operations is that recipes and equipment are the easy part. The thing that quietly wrecks the whole effort is master data. At one site, inconsistent naming, duplicate SKUs, and improvised lot codes don't hurt you — everyone knows what everyone means. Add a second site and those informal shortcuts turn into real errors.

A typical example: the original site calls the flagship "IPA-16oz-4pk." The new site's ordering person enters it as "Flagship IPA 4-pack 16." Now inventory won't reconcile, forecasting double-counts, and a transfer order between sites throws an error nobody can explain for two days. Multiply that across 40 SKUs, three package formats, raw materials, and tank IDs, and you've built a coordination tax that compounds every single week.

Before you copy anything to a second site, clean and freeze the master data. That's the whole game. A solid minimal data model that turns scattered records into reliable operations is the foundation — if your single-site records are already messy, do not scale them. You'll just be scaling the mess.

Master-data migration checklist

1. 1
   SKU catalog — one canonical name and code per product/format. Kill duplicates. Decide who can create a new SKU (spoiler: exactly one role).
2. 2
   Raw materials master — malts, hops, yeast strains, adjuncts, packaging. Standardize units. A pound is a pound at both sites; don't let one site track hops in kg.
3. 3
   Recipe/spec sheets — locked versions with version numbers. Not "the current one on the shared drive."
4. 4
   Tank and vessel registry — unique IDs across all sites. Never let both sites have a "FV3." Prefix by site: A-FV3, B-FV3.
5. 5
   Lot/batch code structure — a single scheme that encodes site, date, and batch. Non-negotiable for recall purposes.
6. 6
   Customer and account master — so distribution and returns reconcile across sites.
7. 7
   Vendor master — same supplier, same record, even if each site orders separately.
8. 8
   QC specs and release criteria — identical thresholds, or explicitly documented site variances.
9. 9
   Unit-of-measure conventions — barrels vs. gallons vs. hectoliters, decided once.
10. 10
    Cost standards — so per-SKU costing stays comparable between sites.

The mistake almost everyone makes is treating migration as a one-time copy. It isn't. It's a cutover with a validation step. Copy the frozen master data, then run a reconciliation: does Site B's SKU list exactly match the golden source? Do lot codes generate in the right format? Do transfer orders between sites resolve cleanly on a test transaction? Only after that passes do you let real production start.

“

Lock SKU creation to a single role and run quick batch reconciliations after initial cutover to catch formatting mismatches early.

The lot code decision that saves you later

Spend real time on your lot code scheme, because you'll live with it for years and it's brutal to change once product is in the field. A workable structure encodes four things: site, product, brew/pack date, and a sequence. Something like B-IPA-20250612-02 reads instantly as "Site B, IPA, June 12 2025, second batch of the day."

The decision rule: a lot code must be reconstructable from the physical package and traceable to a single site. If you can't stand in a distributor's warehouse, read a can, and know which brewhouse made it, your recall process is already broken.

Inter-site transfer SOPs

Once product and materials move between sites, you've created a new category of risk that single-site breweries never deal with: the handoff. Bright beer transferred for packaging, yeast shared between sites, finished goods rebalanced from a site with surplus to one with a shortage, kegs cycling through multiple locations — each transfer is a moment where inventory, quality status, and ownership can all get lost at once.

The core problem is that a transfer is really two transactions — a shipment out and a receipt in — and breweries constantly treat it as one. Site A ships 40 kegs. Site B receives 38 and two are "we'll sort it later." Nobody sorts it later. Six weeks on, your keg count is off, your beer inventory is off, and you're arguing about who lost what. This is the same dynamic that makes container tracking so painful — the lifecycle economics of kegs and deposit policies get exponentially harder the moment kegs move across sites instead of just out and back from one.

A clean inter-site transfer workflow

Transfer order created → QC status attached → Physical count at load-out → In-transit state active → Count at arrival → Variance check → Transfer closes (or escalates)

1. 1
   Originating site creates a transfer order with SKU/lot, quantity, and quality status. Nothing leaves without one.
2. 2
   QC status travels with the product. A bright beer transfer includes its release status — released, hold, or pending. The receiving site must not package a batch that's on hold, and they can only know that if the status moved with it.
3. 3
   Physical count at load-out, signed. Not "about 40." An actual number.
4. 4
   In-transit inventory exists as its own state. Product that has left Site A but not arrived at Site B is neither site's floor inventory — it's in transit, visible to both.
5. 5
   Receiving site counts at arrival and reconciles against the transfer order before accepting. Discrepancies get logged immediately, not "later."
6. 6
   Variance over threshold triggers escalation. Under roughly 2% and it's noted. Over 2% and someone with authority reviews before the transfer closes.
7. 7
   Transfer closes only when both counts reconcile or the variance is formally accepted.

The single most valuable rule in that list is number four. Breweries that don't model in-transit inventory end up with product that's simultaneously counted at both sites or neither. An in-transit state — even just a status flag — eliminates an entire class of reconciliation disputes.

Here's a simple visual to keep on the wall when you're training receiving teams.

Decision rules for transfers

1. 1
   Never transfer product on QC hold unless it's explicitly moving to be destroyed or reworked, and that's recorded as the reason.
2. 2
   Yeast transfers carry generation count and viability data. A site shouldn't accept mystery yeast — over-pitched tired yeast produces off-flavors that show up as a "site difference" you'll chase for weeks.
3. 3
   Finished-goods rebalancing between sites uses the older lot first. Otherwise you strand old inventory at one site while the other packages fresh.
4. 4
   Any cross-site transfer of a SKU that Site B also produces gets a lot-code audit — so you never end up with two different beers under codes that look interchangeable.

These aren't complicated rules. The problem is that without a formal transfer process, they just don't get followed consistently enough to matter.

Recall and traceability governance across sites

This is where multi-site breweries get genuinely exposed, and it's the part most likely to get skipped until an actual scare forces the issue. A recall is a coordination problem, and coordination is exactly what multiplies in difficulty when you add sites. In a single-site recall, one person can trace a lot from grain to distributor because they were there for all of it. Across sites, that continuity is gone — unless you engineered it in.

The governance question underneath all of this is ownership. Who declares a recall? Who has authority to pull product across all sites at once, or hold a single site? Who talks to the FDA and distributors? If those answers differ by location, or if they're genuinely undecided, you'll lose the first critical hours arguing about roles while affected product keeps moving.

The governance template that actually holds up

1. 1
   Recall decision authority — a single named role (usually QC lead or a designated exec) who can declare across all sites. One decision-maker, not a committee, not "whoever's around."
2. 2
   Site recall coordinators — one per site, responsible for executing the pull locally and reporting counts back to the central authority.
3. 3
   Traceability owner — the person who can produce, within a target window, the full one-up/one-down chain for any lot at any site.
4. 4
   Communication tree — who contacts distributors, retailers, regulators, and in what order.
5. 5
   Mock recall cadence — how often you drill, and the required trace-completion time.
6. 6
   Cross-site lot mapping — the master list that ties every lot code to its origin site, ingredients, and shipment records.

A recall trace has to work in both directions

The traceability standard is one-up, one-down: for any lot you must know where every input came from (one back) and where every unit went (one forward). Across sites, the trap is that the chain breaks at the handoff. Bright beer brewed at Site A and packaged at Site B has to trace across that boundary cleanly — the finished cans at Site B must point back to the fermentation lot at Site A, and that lot must point back to the specific malt and hop lots.

The decision rule that keeps this honest: you should be able to pick any random finished unit at any site and trace it fully backward and forward within your target window — typically a few hours, not days. If a mock drill takes two days, you don't have a traceability system. You have a research project.

Example mock-recall SOP

1. 1
   Central authority selects a random lot from any site and declares a mock recall at a specific timestamp.
2. 2
   Traceability owner produces the backward trace — every raw material lot in that batch — and logs the time to complete.
3. 3
   Traceability owner produces the forward trace — every customer, distributor, and unit count that received product from that lot, across all sites it touched.
4. 4
   Site coordinators confirm they could physically locate and hold the identified product.
5. 5
   Reconcile the numbers

   units produced should equal units shipped + units on hand + documented losses. A gap here is a real finding.

6. 6
   Debrief and log the trace time, gaps, and corrective actions with owners and due dates.

The number that matters most from that drill is the reconciliation gap in step five. If you brewed a batch that yielded roughly 5,200 units and you can only account for around 4,900 across shipments, taproom, and inventory, that 300-unit hole is exactly what would sink you in a real recall. Better to find it in a drill than on a phone call from a regulator.

A real scenario

A regional brewery producing somewhere around 9,000 bbl a year opened a second full-production site to cut freight into a neighboring region — a mirrored model, on paper. The flagship pale ale sold well at both. Within about four months, distributor complaints started coming in that the beer "tasted different depending on where they bought it."

The root cause wasn't the water or the equipment, which everyone assumed first. It was master data and process drift. Site B had been entered with slightly different hop-addition timing in its recipe sheet — a change someone made locally to match a tank quirk and never pushed back to the golden recipe. Two SKUs for the same beer had also crept into the system, so nobody's reports even showed the two sites' outputs side by side clearly. And because there was no cross-site lot mapping, a distributor question about a specific batch took nearly two days to answer.

The fix was unglamorous. They froze one canonical recipe with a version number, re-migrated Site B's master data against it, collapsed the duplicate SKUs, and stood up a single lot-code scheme across both sites. Quarterly mock recalls followed. The taste complaints faded over the next couple of production cycles as Site B came back onto spec, and their mock-recall trace time dropped from roughly two days to under three hours. Nothing exotic — just the governance work they'd skipped when they thought duplicating a brewhouse was the hard part.

Where software earns its place

None of this requires software to be true — but it becomes very hard to hold together manually once you're multi-site. The governance rules, the frozen master data, the transfer workflow, the recall chain: these are all information problems, and information problems get expensive when they're managed across spreadsheets that each site edits independently.

The practical value of an operational platform here isn't magic — it's a single source of truth that all sites read from and write to. One SKU catalog everyone shares. Transfer orders that create real in-transit states both sites can see. Lot codes generated to one scheme automatically, so nobody hand-types B-IPA-20250612-02 and fat-fingers the date. And a traceability chain that actually spans sites, so a mock recall is a few clicks instead of a two-day fire drill.

AI-assisted checks quietly help catch drift — flagging a recipe version that diverged, a transfer that closed with an unresolved variance, a lot code that doesn't match the standard — before those small gaps become the thing a distributor or regulator finds first. That kind of passive monitoring is where AI-powered operational software earns its keep in multi-site environments, not because it does anything dramatic, but because it catches the slow erosion that manual processes miss.

The point isn't the tooling. It's that at two-plus sites, the coordination load exceeds what informal systems can carry, and the failures show up as taste complaints, inventory disputes, and recall exposure rather than as an obvious "our data is bad" alarm.

Bringing it together

Scaling a brewery across sites is mostly a discipline problem wearing a capital-expenditure costume. The brewhouse and the tanks feel like the big decisions, but the things that determine whether multi-site actually works are quieter: which scaling model fits your real growth pattern, whether your master data is clean enough to copy, whether your transfers reconcile, and whether you can trace any unit in either direction fast enough to survive a recall.

Pick the model that matches your real bottleneck — reach, freight, or organic growth — and be honest about which failure mode you're signing up for. Freeze and validate your master data before you copy it anywhere. Treat every inter-site transfer as two transactions with an in-transit state in between. Build your recall governance now, while it's a drill, not later when it's a phone call from a distributor.

Do that work first and the equipment decisions get easier, because you'll finally be duplicating a system — not just a building full of tanks.

Do that work first and the equipment decisions get easier, because you'll finally be duplicating a system — not just a building full of tanks.