FIELD NOTE / 2026.09.225 MIN READ / 5 SOURCES

Hershey 1999: The Big-Bang ERP Go-Live That Disrupted Halloween Shipments

Hershey's 1999 enterprise-system cutover combined SAP, Siebel, Manugistics, EDI, warehousing, and distribution changes just as peak Halloween shipping demand arrived.

Hershey was modernizing an enterprise, not installing one package

Hershey’s enterprise-wide information program included SAP business applications, Manugistics planning and transportation software, Siebel-related customer and promotion functions, EDI links, warehouse processes, and new distribution workflows. The company implemented a first phase in January 1999 and began the second phase in July, when sales-order, billing, transportation, inventory, receivables, and promotion processes moved onto the integrated environment. [1] Each package could pass its own functional tests while the integrated order-to-cash flow still failed. The acceptance target therefore needed to be a real customer order moving through pricing, allocation, warehouse, transportation, invoice, and cash application.

The hidden assumption

Hershey’s transformation combined multiple enterprise packages with logistics processes and distribution capacity, making the integration boundary larger than any single product. The engineering implication is that season-aware cutover timing, integrated end-to-end testing, capacity validation, realistic rollback, and phased release of tightly coupled business systems cannot remain an aspiration or a postmortem recommendation; it has to be turned into measurable release criteria, ownership, and tested operating procedures.

The final phase arrived just before the confectionery peak

Hershey’s own filings describe serious difficulties after the July 1999 start-up of the final phase. The timing was especially risky because the company’s back-to-school, Halloween, and Christmas shipping season stretches through late summer and autumn. A project that had already slipped therefore entered its least forgiving business window with limited time to stabilize. [2] Schedule pressure becomes technical debt when teams respond by shortening integration tests or compressing user rehearsal. A project that is late before cutover has less buffer for exactly the problems that cutover is meant to reveal.

Where the rollout became fragile

The final phase went live after schedule pressure had already compressed the remaining test and stabilization window. The engineering implication is that season-aware cutover timing, integrated end-to-end testing, capacity validation, realistic rollback, and phased release of tightly coupled business systems cannot remain an aspiration or a postmortem recommendation; it has to be turned into measurable release criteria, ownership, and tested operating procedures.

Order fulfillment and shipping problems became visible immediately

Hershey reported reduced U.S. shipments, longer turnaround times, lost sales, higher freight and warehousing costs, larger inventories and receivables, and a significant backlog of orders. The 1999 annual report also notes that distribution-center capacity constraints exacerbated the slow, problem-ridden startup. [3] Because Hershey manufactures largely for stock, inventory could physically exist while the information system still prevented the company from promising, releasing, or shipping it correctly. Availability of goods and availability of executable orders are different system states.

Why the failure spread

The disruption hit customer service, warehousing, order fulfillment, freight, inventory, and receivables at the same time because those functions had just been connected through the new platform. The engineering implication is that season-aware cutover timing, integrated end-to-end testing, capacity validation, realistic rollback, and phased release of tightly coupled business systems cannot remain an aspiration or a postmortem recommendation; it has to be turned into measurable release criteria, ownership, and tested operating procedures.

The company spent more to solve the integration and process problems

Hershey disclosed roughly $99 million of capitalized software and hardware plus related expenses by the end of 1999 and expected total commitments around $115 million to $120 million, including incremental costs to resolve system and process problems. That figure is useful because it shows how stabilization itself becomes part of ERP cost. [4] Restoration was therefore not achieved by fixing one database. Hershey had to change processes, clear backlog, absorb extra logistics expense, and repair credibility with wholesale and retail customers that had missed seasonal selling opportunities.

What recovery really required

Recovery required both system fixes and operational changes, including restoring customer confidence and adding distribution capability. The engineering implication is that season-aware cutover timing, integrated end-to-end testing, capacity validation, realistic rollback, and phased release of tightly coupled business systems cannot remain an aspiration or a postmortem recommendation; it has to be turned into measurable release criteria, ownership, and tested operating procedures.

By 2000 Hershey said the remaining glitches had been fixed and peak shipping worked

The 2000 annual report is equally important because it prevents the case from becoming a permanent-failure myth. Hershey said it had remedied remaining system issues, restored acceptable service levels by Easter, and performed successfully through the following back-to-school, Halloween, and Christmas period. The implementation eventually became an operational platform rather than an abandoned system. [5] The case also cautions against attributing the entire revenue decline to software. Hershey’s filings discuss other business factors as well. Good failure analysis isolates what the company itself tied to the system without converting correlation into a single-cause story.

The ‘big bang’ label matters because several dependencies changed together

Moving order management, billing, transportation, warehouse communication, finished-goods inventory, receivables, and promotions together meant one defect could alter the entire order-to-cash path. A phased migration could have separated customer ordering from transportation planning or limited initial product and customer populations. A staged strategy can be slower on paper but faster in recovery because failures stay diagnosable. When everything changes at once, every team sees symptoms from other teams and the incident becomes harder to localize.

Seasonality should be treated as a hard architectural constraint

Consumer businesses cannot choose cutover dates as if every month has equal risk. The correct deployment window is shaped by demand volatility, warehouse staffing, carrier capacity, promotional calendars, and the cost of a missed order. If a schedule slips into peak season, the release plan needs permission to shrink or move. Peak-season rehearsal should include demand above forecast, delayed shipments, late orders, inventory mismatches, and carrier constraints. A system that survives normal averages may still collapse under synchronized holiday pressure.

Why Hershey 1999 belongs in software-failure history

Hershey belongs in software history because the project did eventually work, making the incident a better lesson than a simple failed-ERP story. The crisis came from integration scope, timing, distribution capacity, and inadequate stabilization before peak demand. The recovery showed that enterprise software can succeed after a disastrous launch, but only after the organization restores both technical correctness and operational trust. The enduring lesson is to treat ERP go-live as a business-season decision, not an IT calendar event. Technical readiness, warehouse capacity, training, and customer commitments should all have veto power over the cutover date.

RESEARCH / PROVENANCE

Works Cited

5 SOURCES
  1. 01
  2. 02
  3. 03
  4. 04
  5. 05

CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.

Contribute / Corrections

Improve the record.

Use this moderated submission form to suggest a correction, provide a source, challenge a priority claim or identify a missing contributor. Submissions are treated as research leads, not automatically published comments.