Hertz v. Accenture: Anatomy of a $32M+ IT Disaster

In April 2019, The Hertz Corporation filed suit against Accenture in the U.S. District Court for the Southern District of New York. The subject was a project most people would call routine: a redesigned customer-facing website and mobile apps. The reported facts of how it went wrong are anything but routine, and they make the case a useful study in how a “simple” rebuild becomes a multimillion-dollar dispute.

What follows is drawn from the complaint as reported and contemporaneous press coverage. It is a description of a reported legal matter, not a finding of fault and not legal advice — the allegations were Hertz’s, Accenture denied them, and the case was resolved without a public liability judgment.

What the project was supposed to be

Hertz engaged Accenture to build a new digital storefront — a website and companion mobile apps — intended to serve its family of brands, including Hertz, Dollar, and Thrifty, from a common core. The work was scheduled to go live in December 2017. As a customer-facing e-commerce platform for a global rental business, it was the kind of system where a bad launch is immediately, publicly visible.

What reportedly went wrong

According to Hertz’s complaint as reported, the project never reached a usable state:

• The date slipped, repeatedly. The December 2017 launch was missed; the schedule reportedly moved into January and then April 2018, and the product was never delivered in finished form. Hertz terminated the engagement in 2018.
• It allegedly lacked responsive design. Hertz claimed the site did not properly adapt across screen sizes — a baseline expectation for a modern consumer site — and that adapting it carried additional cost.
• It was reportedly single-brand. Hertz alleged the code was built for the Hertz North America brand and could not be extended to the Dollar and Thrifty brands or the global footprint as intended — defeating the “common core” premise.
• It allegedly carried security and quality defects. The complaint described code that was poorly written, with security vulnerabilities and performance problems.

Accenture, for its part, stated publicly that it believed the allegations were without merit and that it would defend its position. Reporting noted Accenture had sought additional fees to complete elements of the work — a reminder that, as in most of these matters, each side told a different story.

The reported timeline

The sequence is what makes the case legible. Dates and figures below are as reported in press coverage and Hertz’s complaint, not as established by a court.

When	What reportedly happened
2016	Hertz engages Accenture to build a unified website and mobile apps across the Hertz, Dollar, and Thrifty brands.
December 2017	Original go-live date. Missed.
Early 2018	Schedule reportedly slips to January, then April 2018. The product is never delivered in finished form.
2018	Hertz terminates the engagement.
April 2019	Hertz files suit in the S.D.N.Y., alleging breach and seeking the ~$32M paid plus remediation costs and fees.
Later	Matter resolved and dismissed with prejudice. Settlement terms not disclosed.

Notice how much of the budget and calendar was spent before the disputes about responsive design, brand reuse, and code quality were even testable. Nothing shipped, so nothing could be judged against reality until the end.

The numbers, stated conservatively

Hertz reported paying Accenture approximately $32 million and sued to recover that amount plus additional damages, including the cost of remediating the work and attorneys’ fees — a demand commonly reported as “$32 million-plus.” Those are the figures Hertz claimed; they were not established by a public judgment. The matter was later resolved and the case dismissed with prejudice, and the settlement terms were not made public. We won’t attach a settlement number to it, because none was publicly confirmed.

The delivery lesson

Strip away the specifics and the structure is familiar. A single large deliverable, due all at once, slipping past its date, with the gap between “what we built” and “what was needed” only becoming undeniable near the end. By the time the disputes about responsive design, brand reuse, and code quality surfaced, the project had already consumed its budget and its timeline. There was no partial, working system to fall back on — only a binary question of whether the whole thing was fit for purpose.

That binary is exactly what a different delivery model avoids. We’ve written more broadly about why software rewrites fail; this case is a concrete instance.

What would have surfaced the problem sooner

Read the reported allegations as a checklist of things nobody could confirm until it was too late: whether the code was responsive, whether it generalized across brands, whether it was secure and performant. Each of those is an acceptance test. In a big-bang program they all come due at once, at the end. Structured differently, each becomes a gate the work has to pass before more money and time flow into it.

If you are scoping a fixed-price rebuild with an integrator right now, these are the terms that convert “trust us, it’s on track” into something you can verify:

• Tie payment to working software, not to phases. Milestone payments should release against a demonstrable, deployed increment — a real page serving real traffic in staging — not against a document, a design phase, or a percentage-complete estimate. If the only thing that has shipped is a plan, no milestone has been met.
• Make the hard requirements acceptance criteria, not assumptions. Responsive behavior across the devices you actually support, and reuse across every brand in scope, belong in the acceptance test for the first shippable slice — proven early on a small surface, not discovered at the end across the whole product.
• Require a running system at every checkpoint. A demo of clickable mockups is not a running system. Insist on something you can point live traffic at, even a thin slice, from the first milestone. A project that cannot show working software after a quarter is telling you something.
• Keep the old system serving until the new one is proven. The most expensive words in the Hertz story are “never delivered in usable form.” If the incumbent site keeps running while the replacement is proven slice by slice, a stalled rebuild is a disappointment, not an outage and a lawsuit.
• Own the exit. Contract for source, documentation, and the right to walk with a working partial system. The projects that end in court are the ones where terminating the vendor also means throwing away everything paid for.

None of these require a different vendor. They require a different shape of deliverable — small, running, and tested against reality on a cadence — so the gap between “what we built” and “what was needed” shows up in week six, not month eighteen.

How we’d shape a rebuild like this

A customer-facing rebuild can be delivered without betting the launch on one date. We move one slice at a time behind a strangler facade, so the existing site keeps serving customers while pieces of the new one go live behind it. Before any slice carries live traffic, we prove it behaves identically to what it replaces — across devices, brands, and edge cases — and traffic shifts only on green, with rollback a flag away. Cross-brand reuse and responsive behavior become acceptance criteria proven per slice, not assumptions discovered at the end.

The contrast with the big-bang model is the whole point, and we lay it out in big-bang vs. incremental. Where the concern is the exposure an at-risk system or stalled project already carries, a legacy system liability assessment names it before someone else does.

What we’re not claiming

We are not claiming Accenture was at fault — there was no public liability finding, and large integrators deliver successful programs every day. Nor are we claiming any involvement in this matter; we had none. The case is useful only as a public, well-documented example of how big-bang delivery concentrates risk. A discovery call to scope a reversible, parity-proven rebuild is at /meet, and the team is reachable at sales@modernlift.ai.

This guide summarizes a reported legal matter for illustration. It is not legal advice, and any judgment about the parties’ conduct belongs to the courts and counsel.