The Apparel ERP Go-Live Checklist, Stage by Stage

It is 6:40 am on a Tuesday and the COO of a $22M contemporary brand is on a call with her 3PL, her EDI provider, and her new ERP implementer. The go-live happened on Saturday. By Monday afternoon, Shopify had oversold three SKUs by a combined 180 units because the opening balances loaded into the new system did not match what the 3PL was actually holding. A Nordstrom PO sitting in the old system never got migrated, so the ASN never went out, and the chargeback is already queued. Finance cannot close October because the inventory subledger has two sources of truth. None of this is unusual. All of it is preventable.

What is an apparel erp go-live checklist?

An apparel erp go-live checklist is the staged, sequenced set of tasks an apparel brand executes to move production, inventory, orders, warehouse, and finance from a fragmented stack (spreadsheets, Shopify, a 3PL portal, QuickBooks, a PLM tool, a wholesale tool) onto a unified system without losing operational continuity. It is not a project plan and it is not a launch-day runbook. It is the decision framework that says which workflows cut over in which order, what the exit criteria are for each stage, and what gets left running in parallel until the new system has earned trust.

The reason the 6 Breakpoints framework exists in the form it does is that nearly every go-live I have watched fail did not fail at the technology layer. It failed at the sequencing layer. Someone cut over orders before inventory truth was established. Someone migrated finance before warehouse execution was stable. Someone tried to do all of it on the same weekend. The breakpoints are not just diagnostic for whether you need a new system. They are also the right cutover order once you have chosen one.

Why do apparel ERP go-lives fail more often than other industries?

Apparel has structural complications that a generic ERP go-live playbook does not account for. You are running wholesale and DTC simultaneously on the same inventory pool. You have a 3PL (sometimes two or three) that holds physical truth, not your ERP. You have retailer EDI compliance windows that do not pause for your project plan. You have seasonal drops where a bad cutover week is also your biggest revenue week. You have returns posting back into available-to-sell on a delay that varies by channel.

What I keep hearing from customers about why they bought is rarely “we needed a new system.” It is “we cannot trust the number anymore.” By the time a $15M brand running wholesale, DTC, and a 3PL gets serious about replacement, the ops team is spending six to nine hours a week reconciling inventory across Shopify, the 3PL, and the wholesale tool, the oversell rate at peak is running two to three percent, and one full-time person is effectively doing data plumbing. The go-live is supposed to end that. It often extends it by a quarter because the cutover was treated as an IT event rather than an operations event.

Stage 1: What does data readiness actually mean before cutover?

Data readiness is the stage almost everyone underestimates and it is the one that determines whether stages 3, 4, and 5 work. The deliverable is not “we exported the data.” The deliverable is that your product, inventory, customer, and open-order data has been cleaned, mapped, and reconciled to physical reality before it is loaded into the new system.

For product data, this means every active style has a clean parent-variant structure, every variant has a single canonical SKU, and color and size codes are consistent across channels. If Shopify calls a color “Bone” and the 3PL calls it “BNE” and the wholesale tool calls it “OFF-WHITE,” you have three migration problems, not one. This is the breakpoint 1 work (product data fragmentation) and it has to be resolved before anything else moves.

For inventory, the exit criterion is a full physical count at the 3PL reconciled to the new system’s opening balance, with variances explained and signed off. Not within five percent. Reconciled. If you cannot get the 3PL to commit to a cycle count weekend, you are not ready for stage 2.

For open orders, every unshipped DTC order, every open wholesale PO, every backorder, and every pending RA needs to be classified into one of three buckets: ships from the old system, migrates and ships from the new system, or cancels. Ambiguity here is what causes the missed ASN scenario from the opening scene.

For finance, the opening balance sheet position on inventory, AR, and AP has to be locked. The accountant should be in the room for this, not consulted after the fact.

The exit criterion for stage 1 is a written sign-off from ops, warehouse, and finance that the data is loadable. If any of the three will not sign, you are not ready.

Stage 2: How do you run a sandbox parallel without doubling the team’s work?

Stage 2 is where you load the cleaned data into a sandbox environment and run a representative slice of real operations through it for two to four weeks while production still runs on the old stack. The point is not to test the software. The vendor already tested the software. The point is to test your configuration against your workflows.

The slice should include at least one full-cycle DTC order (placed, allocated, picked, shipped, returned, refunded), at least one wholesale order with EDI (PO received via 850, acknowledged, picked, ASN sent via 856, invoiced via 810), at least one production order from PO issue to receipt at the 3PL, and at least one period-end inventory valuation that ties to the GL.

If the EDI integration cannot send an 856 within two hours of pick during the sandbox, it will not do it in production either. If the wholesale order allocates against the DTC available-to-sell pool when it should allocate against a wholesale-committed pool, that is a configuration problem you find now, not the week you ship spring market orders.

The exit criterion for stage 2 is that ops can walk through every workflow on the new system without the implementer touching the keyboard. If the implementer is still driving, you are not ready for stage 3.

Stage 3: What is the right channel cutover order?

Channel cutover is where most brands try to do too much at once. The correct order, in almost every case I have seen, is wholesale first, then DTC, then marketplaces.

Wholesale first sounds counterintuitive because wholesale feels riskier (retailer chargebacks, EDI compliance, ship windows). It is exactly because of that risk that you cut it over first, while the team has full attention and while DTC is still running on the old, known stack as a safety net. Wholesale volume is also more predictable inside a given week, which makes the cutover load manageable.

DTC cuts over second, once wholesale has been stable for at least one full week including a complete order-to-cash cycle. The DTC cutover is largely a Shopify integration question: order flow, inventory sync direction, refund posting, gift card handling. Wholesale should not run through Shopify’s native flow, and if your previous setup forced it to, the cutover is also a chance to fix that architecture. Hold wholesale on a proper B2B path and let Shopify do what Shopify does.

Marketplaces and any secondary DTC channels cut over last, after both primary channels are stable for two weeks.

The exit criterion for stage 3 is one clean week per channel: every order from that channel flowed through the new system from capture to ship to invoice without manual intervention, and the oversell rate held under one percent. Anything higher and you have an inventory truth problem (breakpoint 3) that has to be resolved before the next channel cuts over.

Stage 4: How do you keep the warehouse and 3PL in sync during go-live?

Warehouse execution is the breakpoint 5 problem and it is the silent killer of go-lives. The 3PL is running their own WMS. Your new ERP is sending pick tickets, receiving shipment confirmations, and reconciling inventory positions against what the WMS reports. If those two systems disagree, the 3PL believes their numbers and you believe yours, and reconciliation calls become the new Tuesday morning ritual.

The stage 4 work is establishing the integration cadence in production. Pick tickets flowing in real time. Shipment confirmations flowing back within a defined window (one hour is reasonable, four hours is the outer edge for retailer compliance). Receiving against POs posting same-day. Cycle counts at a defined cadence, with variances investigated within 48 hours rather than batched up for a quarterly audit.

This is also where international duties and returns logic gets stress-tested. A brand like Magnolia Pearl, which runs same-day fulfillment with international customers and a meaningful return rate, cannot tolerate returns sitting in a reverse-logistics queue for two weeks before they post back to available-to-sell. Returns should post to inventory in days, not weeks, and the integration has to enforce that.

The exit criterion for stage 4 is a 14-day window where the ERP inventory position and the 3PL WMS position reconcile daily within a tight tolerance with zero manual adjustments. If you are making manual adjustments to force them to match, the integration is not working.

Stage 5: When does finance actually go live?

Finance is the last stage and this is where the breakpoint 6 issue (reporting becomes reactive and political instead of operational) either gets solved or gets entrenched for another year.

A multi-entity wholesale brand like Lufema, running multiple brand catalogs and a B2B portal, cannot close the books if the inventory subledger does not tie to the GL and if intercompany transactions between entities are not posting cleanly. The finance cutover has to wait until inventory truth is established in stage 4, because inventory valuation feeds COGS, and COGS drives gross margin, and gross margin is what the CEO and the board are going to ask about on the first month-end after go-live.

The stage 5 sequence is: lock the opening balance sheet, post one full month of operations through the new system, run a parallel close on the old and new systems for that first month, and reconcile any variance line by line. If the variance is unexplained, the close does not publish. This is also where the choice between native accounting and an integration to Xero or QuickBooks gets settled. For single-entity brands at the lower end of the ICP band, the integration path is often fine. For multi-entity brands, native accounting inside the operations platform removes an entire class of reconciliation work that the integration path will continue to generate forever.

The exit criterion for stage 5 is a clean first close on the new system, signed by the controller, with the inventory subledger tied to the GL and the prior-period comparison reconciled. After that, OTB, gross margin by channel, and sell-through reporting can come online. Run OTB weekly during selling season once the data is trustworthy. Monthly is too slow for an apparel brand with a drop cadence.

What does a realistic go-live timeline look like?

For a $15M to $25M brand replacing three to five tools plus spreadsheets, a defensible end-to-end timeline is 14 to 20 weeks: four weeks of data readiness, three to four weeks of sandbox parallel, two weeks per channel for cutover, two weeks of warehouse stabilization, and one full close cycle on finance. Brands that try to compress this into eight weeks usually spend the saved weeks on the back end fixing things in production, with more revenue exposure and more team burnout.

The brands that compress successfully are the ones that did stage 1 properly. Clean data shortens every subsequent stage. Dirty data extends every subsequent stage and is the single biggest predictor of a go-live that overruns.

What this means for an apparel operations team

The go-live is not a software event. It is an operations event with a software component. Treat it that way in the staffing model: ops leads the project, not IT, and finance is in the room from week one rather than week ten. The implementer is a partner, not a driver.

Use the 6 Breakpoints as the cutover order, not just as the diagnostic that justified the project. Product data first, then production, then inventory, then orders, then warehouse, then reporting and finance. The framework was built from the pattern of how these systems actually break in sequence, and the cutover that respects that sequence is the cutover that holds.

Most importantly, define the exit criteria for each stage before you start the stage, and refuse to advance until the criteria are met. The pressure to keep moving is enormous, especially when a board has been told the project will be done by a certain date. Moving forward on a stage that did not close is how you end up with the Tuesday 6:40 am call.