Apparel OS vs PLM and spreadsheets: the stack most brands actually run

Why almost nobody runs PLM alone

The composite is not a failure of discipline. It is what you get when a brand solves the loudest problem first. Product development is where the pain announces itself early — version confusion on specs, tech packs scattered across drives, a costing nobody can source — so PLM gets bought, the project succeeds, and the product record gets clean. The commercial workflow was never in scope, so it stayed where it already was: in the workbooks the planning team had been running the season on all along. Nothing then forces a second decision. The PLM does what it promised, the spreadsheets keep bending to whatever the team needs, and the seam between them is bridged by people who are good at their jobs. Brands do not drift into this stack; they arrive at it deliberately, one sensible purchase at a time.

Five transfers, and what breaks at each one

A season built on PLM and spreadsheets is not one workflow. It is a sequence of artifacts, each fed by hand from the one before it — and then, after all of it is committed, development changes something and there is no path back. Every one of those transfers is a place where the season can quietly stop agreeing with itself, and each one fails in its own specific way.

Why the composite stack hides its own cost

The reason this stack survives scrutiny is that no part of it fails an audit. Ask the product team whether PLM is working and the answer is yes, with evidence: specs are versioned, costs are sourced, the line is approved on time. Ask planning whether the workbooks tie out and the answer is also yes — they reconcile at close, because someone spent a day making them reconcile. The cost of the composite is paid in two currencies that never appear as a line item: reconciliation labor, and late discovery. Reconciliation labor looks like normal work, so it is budgeted as headcount rather than counted as waste. Late discovery — a size run that broke, a delivery that slipped, an overbuy nobody caught — is absorbed as the ordinary variance of a seasonal business. Neither ever gets attributed to the transfer that caused it, which is why brands can run this way for years and still describe the stack as fine.

What stays current without someone maintaining it

Not a feature list. Each row asks whether the answer stays correct on its own, or only for as long as a person keeps it correct by hand.

Rows describe whether the answer stays correct without a person maintaining it, not which system originates the data. Both tables on this page compare categories rather than named products: PLM deployments and spreadsheet setups differ, and a specific implementation — or a heavily automated workbook — may do better on individual rows than the category does. Last reviewed: August 2026.

Replacing the transfers, not the tools

The alternative to a chain of artifacts is not a bigger artifact. It is a shared model where the plan, the assortment, the buy, the size curve, and the PO are views of one record rather than five files that have to be told about each other. Product data arrives from PLM instead of being retyped, the buy is sized against an open-to-buy that is live rather than remembered, and a cost or delivery change after commitment updates the margin and the plan that depended on it. The PLM stays; the transfers go. A brand that keeps both tools and closes the space between them gets more out of the PLM it already paid for, because the product record finally reaches the decisions it was supposed to inform.

Definition — Apparel operating system

An apparel operating system (Apparel OS) is the connected system of record for an apparel brand’s commercial workflow — line planning, open-to-buy, assortment planning, buy planning, sizing, purchase orders, production tracking, and allocation — kept on one shared version so a decision in one stage updates the rest without re-keying.

Used by: Merchandising, planning, buying, sourcing, production, and allocation teams

Related: PLM, spreadsheets, ERP, merchandise planning software

Where to go deeper on each half

Apparel OS vs PLM covers what PLM owns and where product data stops, and Apparel OS vs spreadsheets covers where spreadsheets break function by function. If your product system is an ERP rather than a PLM, the same argument in that shape is why ERP and Excel still leave apparel margins exposed. For how these categories sit together, see the modern apparel software stack and the apparel software buyer’s guide.

Start with one transfer, not the whole stack

Nothing here argues for replacing the stack in one move. The transfers fail independently, so they can be closed independently. To find which one is costing you most, score the seams with the operating model assessment. To sequence the work once you have picked one, follow the implementation playbook for connected planning, which sets out the phases, the owner for each, and what done looks like.

How RetailNorthstar fits

RetailNorthstar runs the commercial layer that sits downstream of a PLM — the connected line-plan-to-allocation workflow on one shared model, with AI-assisted planning working on that record rather than a copy of it. Product data comes in from the system that already governs it, and the workbooks in between stop being load-bearing. Read the full Apparel OS overview for what the connected layer covers end to end.

• ✓The real apparel stack is PLM and spreadsheets together — one system for the product record, a chain of files for every commercial decision after it.
• ✓It forms deliberately: PLM solves the loudest problem, the commercial workflow was never in scope, and nothing afterwards forces a second decision.
• ✓The cost lives in five transfers — PLM export to workbook, workbook to assortment, assortment to buy, buy to PO, and the change that arrives after commitment.
• ✓It stays invisible because it is paid in reconciliation labor and late discovery, neither of which ever gets attributed to the transfer that caused it.
• ✓The move is to replace the transfers rather than the tools: keep the PLM, close the highest-cost seam first, and put the commercial workflow on one shared record.

• Compare the Apparel OS with PLM on its own →
• Compare the Apparel OS with spreadsheets on their own →
• Why ERP and Excel still leave apparel margins exposed →
• Follow the implementation playbook for connected planning →
• See the connected apparel workflow map →

Frequently asked questions

What is wrong with running PLM and spreadsheets together?

Nothing is wrong with either half on its own terms. PLM governs the product record well, and spreadsheets model whatever you need without a project. The problem is the transfers between them: every commercial decision after product development lives in a file fed by hand from the file before it, and nothing propagates backward when something changes. The cost is not in the tools; it is in the five handoffs holding them together.

Do I need to replace PLM to move off spreadsheets?

No, and most brands should not. PLM is doing the job it was bought for, and ripping it out to solve a planning problem replaces one working system to fix a different one. The more common pattern is to keep the PLM as the product system of record and add the connected commercial layer downstream of it, so product data feeds planning, assortment, the buy, and the PO directly rather than being exported and retyped.

Which transfer should a brand connect first?

The one that costs the most, which is usually not the one that gets complained about the most. Two candidates dominate: the product-into-plan transfer, if your team rebuilds the style list every time development moves, and the assortment-into-buy transfer, if size curves are defaulted and the buy is sized against a plan it cannot see. Pick by where the rework and the late surprises actually land, connect that one seam, and prove it on a real decision before extending to the next.

Can we just build better integrations between PLM and our spreadsheets?

You can automate the export, and it helps at the first transfer. What it does not fix is that a spreadsheet has no shared state: the assortment sheet still cannot see the plan, the buy sheet still cannot see live OTB, and a change after commitment still has no path back upstream. Automating a handoff makes the copy faster; it does not make the artifacts agree. That is a different problem, and it is the one the connected layer solves.

Does an Apparel OS duplicate what our PLM already does?

It should not. An apparel operating system owns the commercial workflow — line planning, open-to-buy, assortment, buy planning, size curves, purchase orders, production visibility, and allocation — and reads the product record rather than recreating it. The overlap is deliberate and thin: it needs styles, colorways, size ranges, and costs, and it takes them from PLM instead of asking a planner to retype them. If a vendor proposes rebuilding your tech packs, that is a PLM replacement conversation, not a connected-planning one.