Going Live With Apparel ERP: The 90-Day Operational Readiness Checklist

After enough apparel ERP implementations, the pattern becomes visible. The brands that go live cleanly spent most of the effort in the 90 days before cutover and the 30 days after. The brands that struggle spent most of the effort on the cutover week itself and improvised everything else. Both started from roughly the same configuration at the vendor's side; the difference was operational readiness.

This post is the 90-day readiness checklist that predicts clean go-lives. It is written from the customer success side, which means everything here is about what the brand's team has to own — not what the vendor does. The vendor's job is to configure, integrate, and support; the brand's job is the operational work below.

The three phases

A 90-day readiness plan splits into three phases. Each has different owners, different deliverables, and a different failure mode if skipped.

• Days 1–30: Foundation. Data cleanup, integration scoping, team role assignment, workflow mapping.
• Days 31–60: Rehearsal. Migration dry run, integration test volume, UAT against real scenarios, training rollout.
• Days 61–90: Cutover readiness. Final data sync, cutover plan and rollback trigger, communication plan, first-week operating model.

Days 1–30: Foundation

Product master cleanup

The single largest predictor of clean migration is product master hygiene. Before the new ERP ingests anything, the brand's product data has to be cleaned: duplicate SKUs deduplicated, dead styles archived, colour and size taxonomies rationalised, image URLs validated, BOMs verified. This work is not the vendor's job; nobody knows which SKUs are actually dead except the brand's team.

Brands that skip this import their existing mess into the new system and spend the first month after go-live untangling it. Brands that do it land with a clean master on day one.

Integration inventory

List every system that needs to connect to the new ERP with concrete specifics: which Shopify store (or stores), which marketplace accounts (Amazon, Zalando, Mirakl), which 3PL connectors, which EDI retailers, which accounting system, which shipping carriers via ShipStation or Shippo. For each, confirm credentials, API access, and the integration scope with the vendor. Vague "Shopify integration" becomes specific "Shopify Plus USD storefront with 1.3M monthly orders, webhook-based real-time inventory, orders post-back to Uphance, fulfilment status flows back."

Role assignment

For each team, name the person who owns the workflow inside the new system: wholesale ops, DTC ops, warehouse lead, production, merchandising, finance controller. Each owner walks their workflow end-to-end with the vendor's CS team during rehearsal (days 31–60). Owners are not "involved" — they are accountable for their workflow going live correctly.

Workflow mapping

Document how the operation works today, in bullet points, per team. Where does a wholesale order start, what systems does it touch, how is it picked and shipped, how does it close in accounting? Mapping the current-state before mapping the target-state surfaces the workflows the new system has to cover — and the workflows that will simply go away (usually the reconciliation ones).

Days 31–60: Rehearsal

Migration dry run

Week 5 or 6, run a full migration dry run into a sandbox of the new system using a real snapshot of production data. Every team reviews their data once it lands: does the product master look right, does customer data include the pricing terms that matter, does inventory reflect reality. The first dry run always surfaces issues — mapping gaps, taxonomy mismatches, fields that didn't make it across. That's the point. Better to find them in week 6 than in week 13.

Integration test volume

Integrations that work in a five-order test often fail at production volume. Run test loads against each integration that approximate real volume: 500 DTC orders through Shopify in an hour, a large wholesale EDI PO through the retailer's test environment, a pallet's worth of ASN through the 3PL connector. The rehearsal catches rate limits, webhook timing issues, and mapping edge cases before they're production problems.

UAT against real scenarios

User acceptance testing fails when it's done as a feature checklist. It works when each role owner walks three real scenarios they face weekly, end-to-end, in the new system, with data that looks like theirs. A wholesale ops manager tests a real pre-book allocation scenario, not a generic "create an order" task. A warehouse lead tests a split shipment against two 3PL locations, not a basic pick-and-pack. If a scenario breaks or is awkward in UAT, the same scenario will break in production at 10x the pressure.

Training rollout

Training in week 7 or 8, not week 13. The difference is whether the team goes live comfortable or anxious. Role-specific training — not a generic system walkthrough — in the sessions the team actually joins. Every role owner gets certified on their own workflows before cutover.

Days 61–90: Cutover readiness

The cutover plan

Cutover is a written plan, not a meeting. The plan covers the 72 hours before go-live, the go-live day itself, and the 72 hours after. It names every task, every owner, every gate. Sample items:

• T-72h: final data migration from legacy system, full snapshot
• T-48h: reconciliation of migrated data against legacy (variance report, sign-off by each role owner)
• T-24h: freeze on legacy system writes (no new orders, no stock adjustments)
• T-12h: final incremental sync
• T-0: cutover; integrations go live
• T+2h: first live transaction gate (a real order, a real pick, a real invoice)
• T+24h: first-day review with every role owner
• T+72h: rollback decision point

The rollback trigger

Every cutover plan has an explicit rollback trigger: a specific threshold of operational failure at which the team reverts to the legacy system. Example: "If by T+72h, oversell rate exceeds 2% on Shopify or wholesale order pick accuracy drops below 98%, we rollback." Having the trigger written in advance, agreed by operations and leadership, removes the week-of-launch debate about whether to abort.

Good implementations never hit the trigger. But having it means the team can commit to the go-live without fear, because the off-ramp is explicit.

Communication plan

Wholesale customers, especially large retailers, should know cutover is happening. Not as a marketing announcement — as an operational heads-up. A 1-paragraph email to the key contact: "Between [date] and [date+3], we are migrating our operational system. Your orders and shipments will be handled without interruption. If anything feels wrong, call us directly." This handles the handful of issues that do surface without escalating them into relationship damage.

First-week operating model

The week after go-live is scheduled as daily 20-minute stand-ups with every role owner, the vendor's CS contact, and the brand's implementation lead. Each owner reports: what went well, what's broken, what's blocked. Issues get logged, prioritised, and worked. Most get resolved within the week. The daily cadence drops to weekly after day 30 and monthly after day 60.

Skip this and issues pile up silently until the first monthly review, by which point the frustration has turned into "the system doesn't work." With it, issues surface when they're small and get resolved.

Days 90+: Stabilisation and adoption

Day 90 is not the end of the implementation; it's the end of the go-live. The next 90 days are about adoption depth: teams moving from "we use the system" to "we run the business on the system." Reports that weren't prioritised for go-live get built. Integrations that were out-of-scope at cutover get added. The wholesale and DTC teams stop running parallel spreadsheets because the system has proven it can be trusted.

The operational signal that adoption has landed is subtle: people stop talking about the system. Once the ERP is the invisible backbone instead of the thing everyone is discussing, the implementation has succeeded.

What goes wrong when the checklist is skipped

Three patterns, in order of frequency:

• Team reverts to spreadsheets for the wholesale workflow. Symptom: ops manager maintains a parallel pre-book sheet three weeks in. Cause: training and workflow mapping skipped for the wholesale role.
• Oversells spike in week 2–3. Symptom: Shopify and marketplace listings oversell a style by meaningful quantities. Cause: integration test volume was too low; the allocation behaviour that worked in a sandbox fails at real demand.
• Finance cannot close the first month cleanly. Symptom: month-end reconciliation takes three weeks instead of three days. Cause: data migration rehearsal skipped the invoice and payment history validation.

All three are foreseeable and fixable in the 90 days before cutover. None are fixable in the week of.

Related reading: What Uphance apparel ERP covers, Single source of truth in apparel, How to assess fit before starting. To walk through what readiness looks like for your specific operation before committing to an implementation, start with a discovery conversation.