- 24
- July
On 24 February 2026, Tennant Company (NYSE: TNC), a global maker of floor-cleaning equipment, disclosed that a new ERP go-live in North America left it unable to process orders and ship products for roughly 3 weeks, costing an estimated $30 million in lost sales and wiping about 23% off its share price in a single day. The key lesson: the failure was not the software itself, but the cutover plan, the missing end-to-end order-to-cash testing, and the lack of a rollback plan — all things any organization can control with a disciplined implementation process
In one line: ERP projects rarely fail because the software is bad — they fail from going live without end-to-end order-to-cash testing, a rehearsed cutover plan, or a way to roll back. Tennant paid for that lesson with $30M in sales and 23% of its market value in a single day.
What happened at Tennant: the timeline of 3 weeks with no shipping
Tennant Company is a publicly traded company on the New York Stock Exchange (NYSE: TNC) that manufactures and sells commercial and industrial floor-cleaning equipment worldwide. It decided to move to a new ERP system in North America — its core market — and chose a "big-bang" go-live, switching on all major functions at once.
The problems appeared immediately after cutover. On 24 February 2026 the company publicly disclosed that the new ERP go-live had left it unable to process and ship customer orders, with three critical functions failing simultaneously: order entry, product shipment, and customer service. These three are the heart of the revenue pipeline. When they went dark together, the factory could still make products, but goods could not leave the warehouse to reach customers.
Note: The issue was not "the program doesn't work" — the system was running, but the end-to-end business process from order intake to shipment (order-to-cash) could not complete. That is the distinction people overlook: an ERP that "boots up" is not the same as an ERP that "runs the business."
The impact on the business and investors was fast and severe. The figures reported by the company and financial media are summarized below.
| Item | Reported figure |
|---|---|
| Date of disclosure | 24 February 2026 |
| Duration unable to ship | approximately 3 weeks |
| Lost sales from the disruption | approximately $30 million |
| Share price on disclosure day | fell from $82.30 to $63.02 (-$19.28/share, ~23%) |
| 2026 remediation cost (estimated) | expected to exceed $20 million vs. an original ~$5 million plan |
| Functions that failed together | order entry, product shipment, customer service |
Sources: reporting by ERP Today (8 Apr 2026) and Tennant Company's Q1 2026 earnings release (see the References section below).
Note that the expected remediation cost of over $20 million is roughly four times the ~$5 million the company had originally budgeted. And in July 2026, a law firm was still investigating the company's disclosures to investors. In other words, the true cost did not stop at lost sales — it spread to reputation, investor confidence, and legal risk.
Why ERP go-lives fail: big-bang vs. phased
Research and industry experience agree that most ERP project failures stem not from the product, but from how it is implemented — especially the "cutover" phase that moves from the old system to the new. The Tennant case clearly illustrates the risk of a big-bang go-live strategy.
| Aspect | Big-bang (everything at once) | Phased (module by module) |
|---|---|---|
| Blast radius when something breaks | the whole organization/region stops at once | limited to the module or unit just launched |
| Difficulty of rollback | hard to reverse — data is fully entangled | easier to reverse — narrow impact |
| Total project duration | shorter | longer, but controllable |
| Chance of catching real-process bugs | all discovered live, at once | discovered piece by piece, fixed before scaling |
| Revenue impact if it fails | very high (entire revenue pipeline dark) | limited and estimable |
Big-bang is not always wrong, and many organizations pull it off. But it is a strategy with "no room to miss" — if any single core process stumbles, the impact hits everything at once with no cushion. A phased go-live, by contrast, trades a longer timeline to buy "safety" for the business. If you are weighing this decision, it helps to read up on preparing your organization before an ERP implementation and the principles of project risk management together.
Danger signal: If the project team cannot answer "if cutover day goes wrong, how many hours to roll back to the old system, and who makes that call?", you are about to go live without a safety net.
The missing heart: end-to-end order-to-cash testing
The order-to-cash (O2C) process is the path from a customer placing an order to the company receiving payment. It has many steps that must connect seamlessly: order intake → credit/price check → stock allocation → warehouse picking → shipping documents → shipment → invoicing → payment. If any one step stalls, the whole chain stops.
A common ERP testing mistake is testing in isolation (unit testing) — confirming each screen works — without testing the "whole path" with real data at real volume. What you need is End-to-End testing and UAT (User Acceptance Testing) that simulate a real working day across every scenario, including edge cases such as discounted orders, multi-warehouse items, customers at their credit limit, or cancellations and returns.
| Test type | Answers the question | Would it prevent a Tennant-style failure? |
|---|---|---|
| Unit test | Does each function work correctly? | Not enough — passes screen by screen, full path can still break |
| Integration test | Do the modules talk to each other? | Helps partly |
| End-to-end (O2C) test | Can you complete order to shipment for real? | Yes — catches revenue-pipeline problems directly |
| UAT (real users test) | Can frontline staff do their daily work? | Yes — catches gaps the technical team can't see |
| Load/volume test | Can it handle real volume? | Yes — catches bottlenecks under real load |
The lesson: if you have never seen the new system "close an order and ship goods out of the warehouse for real," end to end, with real data, before go-live day, you are betting the entire company's revenue.
Go / No-Go checklist: are you really ready to go live?
Organizations that implement with discipline put a "go/no-go gate" before cutover day, and refuse to let deadline pressure force a go-live before they are ready. The table below is the minimum bar that should be cleared before a green light.
| Criterion | Question you must answer "yes" to | If you can't |
|---|---|---|
| End-to-end O2C | Have you tested order → ship → invoice across the full path? | No-Go |
| UAT signed off by real users | Have frontline staff signed off that it works? | No-Go |
| Data migration | Do stock/AR/AP balances match the old system? | No-Go |
| Rollback plan | If it breaks, how many hours to reverse, and who calls it? | No-Go |
| Cutover-day support | Is there a war-room team watching and fixing live? | No-Go |
| Customer/partner communication | If delayed, who do you tell and how? | High risk |
Good practice: A smooth go-live day is usually boring, because everything was rehearsed beforehand. Running a mock cutover / dry-run at least once or twice with real data is what separates the projects that survive from the ones that become news.
The cost of downtime: why "rushing to go live" is more expensive than it looks
Many organizations see extending the project to test thoroughly as an "added cost." But the Tennant case shows that the cost of rushing an unready go-live is far higher — and it doesn't stop at money.
| Cost dimension | Actual impact on Tennant |
|---|---|
| Immediate lost revenue | ~$30M in sales from ~3 weeks unable to ship |
| Remediation cost | expected to exceed $20M (~4× the original ~$5M budget) |
| Market value | share price fell ~23% in a single day |
| Reputation/confidence | customers waiting for goods may switch to competitors |
| Legal risk | investigation into disclosures to investors (Jul 2026) |
Compare the two: a few more weeks to test O2C thoroughly and rehearse the cutover costs only a fraction of the tens of millions of dollars in damage that followed. That is why testing discipline is not an "extra expense" but "revenue insurance."
How a disciplined implementation prevents this
A Tennant-style failure is prevented by a systematic process, not luck. The key components are:
- Auditable process standards — working to a framework such as ISO/IEC 29110 forces clear requirement documents, test plans, and traceability, rather than relying on one person's memory.
- UAT signed off by real users — don't let the technical team decide "it's ready"; have frontline staff test daily work until confident.
- A written cutover plan, rehearsed for real — specifying task order, timing, owners, and go/no-go points, with a dry-run before the real thing.
- Phased go-live by module — roll out piece by piece instead of everything at once, keeping risk within a controllable scope.
- Backup and recovery plan — a tested rollback path, aligned with the Disaster Recovery principles every organization should have.
Saeree ERP structures its implementation process around the ISO/IEC 29110 framework the company has been certified against continuously, covering requirement gathering, UAT, and a written cutover plan, and it supports phased go-live by module rather than switching on everything at once — reducing the kind of risk seen in the case above. To be transparent: no system can guarantee zero problems, but discipline and a tested rollback plan are what keep problems small and manageable instead of escalating into a crisis. (Regarding the in-system AI assistant, it is currently under development and is not yet counted as a fully usable feature.) If your organization is planning a system change, it's worth studying how to choose an ERP and an implementation partner alongside this.
Conclusion
The Tennant 2026 case is an expensive lesson confirming an old principle: ERP success is not measured by "the system boots up" but by "the business keeps running on cutover day." End-to-end order-to-cash testing, cutover rehearsals, rollback plans, and phased go-lives are not steps you can cut to save time — they are the most expensive part if you skip them. Organizations that invest in this discipline are the ones whose go-live day is boring, not front-page news.
"A smooth go-live is usually boring, because everything was rehearsed first — the price of skipping the testing steps can be many times the cost of the whole project."
- Lessons from the Tennant Company case, 2026
References
- ERP Today — Tennant ERP rollout disruption triggers $30M sales hit and investor scrutiny (8 Apr 2026)
- Tennant Company — Q1 2026 Earnings Release (Investor Relations, 4 May 2026)
Plan a disciplined ERP go-live — don't become the next headline
Saeree ERP implements to the ISO/IEC 29110 framework, with UAT, a written cutover plan, and support for phased go-live by module. Talk to our team to assess your organization's readiness.
Get advice / request a quoteTel 02-347-7730 | sale@grandlinux.com
