Why ANA's Domestic Renewal Turned to Chaos: The Changes and Causes Explained

ANA (All Nippon Airways) renewed its domestic flight services on May 19, 2026, and the customer-facing touchpoints—booking, purchasing, check-in—have been hit by widespread problems. On June 11, ANA posted an apology on its website, and its inquiry desks reportedly have phone lines that are hard to reach, with email replies said to take "two weeks to two months."

This article breaks down what is happening from a technical angle. The renewal is, at its core, a major migration: ANA replaced the in-house booking system it had used for roughly 50 years with the same global-standard platform it uses for international flights. We dig into why booking and check-in went wrong, what changed for users, and whether it "could have been prevented" or stems from "the underlying architecture"—separating confirmed facts from what has not been disclosed.

The short version: this did not go wrong because the new system's foundation was weak. Migrating to a platform used by 200-plus airlines worldwide was a sound plan, but the operational design—rolling out several changes on the same day—and the readiness of customer touchpoints had gaps. It is a recurring failure pattern shared with past large-scale migrations.

What changed, and how

The center of this overhaul is the replacement of ANA's domestic "Passenger Service System" (PSS)—the core system behind ticket booking, issuance and boarding. Until now ANA used its in-house "able-D." able-D was built by Japan Unisys (now BIPROGY), and in 2013 it broke away from 34 years on a mainframe to become the world's first "open system" PSS for a major network carrier—a technically notable system in its own right.

ANA retired able-D and consolidated onto "Altéa," the cloud system from Spain's Amadeus that it already uses for international flights. Altéa is an industry standard adopted by 200-plus airlines worldwide, and JAL has used it since 2017. ANA announced the plan in February 2023, framing it as "domestic-international unification" on a single platform. According to ANA Holdings' press release, the goals were to turn fixed in-house costs into variable outsourced costs, link domestic and international customer data, and speed up service improvements by adopting a global standard.

For users, the biggest change is the consolidation of domestic fares into three types from May 19, 2026 boarding: the previous fine-grained fare structure was reorganized into "Simple," "Standard" and "Flex," and booking/boarding rules were unified with international flights. In other words, the system swap, the fare rebuild, and the rule unification all landed on the same day. That "many changes at once" became the trigger for the chaos described below.

What users are experiencing now

Since the migration began on May 19, users have reported a range of problems. Pulling together reporting and user voices, the main symptoms are:

On top of these, there are feature restrictions specific to the migration window. Per ANA's official notice, the website temporarily cannot book award tickets for a child traveling alone, and the service restrictions during migration include being unable to change flights booked through May 18 to flights on or after May 19. From May 19 into early June, airport facilities and back-ends are switched over in stages—an unstable period where old and new systems coexist.

On social media, critics called the response slow and the service "too careless for a major company," with some comparing ANA to low-cost carriers. It is a reminder that a booking system most people never think about translates directly into airport wait times and disrupted plans the moment it falters.

Migration timeline

This renewal did not start out of nowhere; it is the final phase of a three-year project. Here is the flow from announcement to chaos.

← swipe to move

Key changes from the user's side

Separate from the glitches, aligning with the same setup as international flights also changed the rules of use. Beyond the officially announced three-tier fares, explainer sites and user reports point to the following changes as well (note these are "spec changes," not bugs).

The three-tier fare change was officially announced by ANA, but the other rule changes include items reported in explainer-site analysis. All of them follow from this renewal's policy of "unifying with international rules." The system feeling heavier is also attributed to the international-grade complex fare calculations and alliance integrations now running constantly in the back-end. For exact conditions, check ANA's official site before booking.

Why it stumbled at the customer touchpoint (the author's analysis)

From here, this is analysis including the author's view rather than a recital of facts. The chaos looks less like "the system didn't run" and more like "load concentrated at the user-facing points (booking screens, inquiry desks) until they couldn't cope." Drawing on the framing in an analysis of this very point, here are three factors.

First, too many changes packed into one day. May 19 brought the system migration, the fare rebuild, and the rule unification at once. From the user's side, questions pile up simultaneously, so inquiry volume grows not by addition but by multiplication. Each change may be rational, yet doing them together makes load spike multiplicatively—a textbook case.

Second, thin readiness for the surge in inquiries. A flood of inquiries right after a big renewal is highly foreseeable in this industry. Yet phone lines were hard to reach and email replies stretched to weeks or months. This is less a technical problem than an operational sizing problem: the "hypercare" staffing meant to be heavy right after launch was set too small.

Third, the gap between a global standard and Japanese users' expectations. Altéa is a standard system used by airlines worldwide, with different conventions from able-D, which was honed for Japan's domestic flights. Changes that are routine globally but jarring for domestic users—name unification in Roman letters, a piece-based baggage rule—all surfaced at once. Standardization may be right in the long run, but the moment of migration generates friction.

Could it have been predicted or avoided?

In fairness, ANA's technical migration plan was by no means sloppy. ANA chose a staged migration running old able-D and new Altéa in parallel for about a year: records for flights through May 18 made on the old system, those from May 19 on the new one. It avoided the risk of a "big-bang" cutover—if anything, a cautious approach.

That the customer touchpoints still buckled suggests, in the author's view, that part of it was avoidable. Since the inquiry surge was foreseeable, ANA could have reinforced support staffing, staggered the changes so users saw them in phases, and put "can the customer touchpoints cope?" into the Go/No-Go criteria for proceeding. Effort went into the technical migration design, but the capacity design of the "desk where people ask questions" at its exit was thin. That is the lesson here.

Is it really an architecture problem?

"Wouldn't a solid foundation (architecture) have prevented this?" is a natural question. In short, the author does not believe an architecture flaw caused this. The target, Altéa, is a proven platform used by 200-plus airlines for years, and JAL has run it in production since 2017. This is not a story of a fragile foundation.

JAL makes an instructive contrast. JAL cut over to the same Altéa in a single night on November 16, 2017 (internally the "SAKURA Project," said to involve JAL, Amadeus, JAL Infotec and Mitsubishi Electric Information Systems). Same platform, different approaches: JAL a big-bang cutover, ANA a year of parallel running. That the same foundation yields different outcomes is the flip side of the point that the stumble lies not in the "foundation" but in "how the migration is run" and "the design of operations and customer touchpoints."

Put another way, even a passing-grade architecture will collapse at the customer touchpoint without matching migration and operational design. It is like building a fine building (the platform): if the moving plan (migration) and the day-after building management (operations) are weak, residents get confused.

What we know—and don't—about the build

On the questions engineers care about—who built it, what it cost, how long it took—public information is uneven. To avoid wrong guesses, here is what is confirmed versus undisclosed.

That the new core is Amadeus's SaaS, and that Japan Unisys (now BIPROGY) built the old able-D, are confirmable from public sources. On the other hand, the integration partner (SIer) that supported ANA's migration on the implementation side, and the development cost, have not been disclosed. For reference, JAL's comparable project was reported to cost several tens of billions of yen and to involve JAL Infotec and Mitsubishi Electric Information Systems, but no equivalent information exists for ANA. Some articles state these definitively; this article treats what cannot be confirmed as "not disclosed."

What we can learn from this case (the author's view)

ANA's chaos is not one company's failure but the latest example of a pattern that recurs in large-scale system migrations. We previously laid out five patterns of why IT migrations fail in Japan, and ANA overlaps with the "customer touchpoints fall over on renewal day" type. It is structurally similar to how Hello Work's site became slow after its renewal.

Here are three takeaways for engineers and the ordering side.

1. Ship changes in pieces. Stacking system migration, pricing changes and rule changes on the same day multiplies user confusion and inquiries. What can be done technically at once and what should be shown to users at once are different questions.

2. Put customer-touchpoint capacity into Go/No-Go. Criteria for proceeding should include not only whether the technical cutover succeeds but "can inquiries be handled?" and "can support cope?" Hypercare right after launch is often best sized several times above expectations.

3. Translate the friction of standardization in advance. Unifying onto a global standard may be right long term, but differences in convention create friction for domestic users. Not sparing the effort to explain, in plain terms before migration, what changes and how—this ultimately reduces inquiries. As with large migrations like the full overhaul of the Zengin payment system, this "design of the exit" decides success or failure.

Frequently asked questions

Sources

• ▸ANA - Feature restrictions in the website renewal
• ▸ANA - Service restrictions during system migration
• ▸ANA Holdings - Integration of domestic and international PSS (Feb 14, 2023)
• ▸Travel Voice - ANA moves domestic system to Amadeus, from in-house to outsourced
• ▸Aviation Wire - ANA's domestic PSS also moves to Amadeus, from in-house "able"
• ▸Nikkei xTECH - ANA's new domestic PSS goes live, one year to full migration
• ▸Infoseek News (ORICON NEWS) - ANA apologizes for renewal chaos
• ▸JAL migrates to Amadeus "Altéa" (Nov 16, 2017)
• ▸note (Bucho) - Learning from ANA's renewal chaos: why big-company overhauls stumble at the customer touchpoint
• ▸dangan-lucky - ANA's domestic system moves to Amadeus: changes and why it feels heavy