Different Tools, Different Truths: How the Hawaiian/Alaska Merger Changed Data

Overnight, an entire airline vanished from the industry's digital data feeds—but the planes kept flying. When Alaska and Hawaiian Airlines announced their merger in 2023, it set the stage for one of the most complex integrations in modern aviation. That integration reached its final "digital" milestone this past April.

That digital milestone is exactly what prompted a recent flood of questions from our users: "Where did the Hawaiian flights go?"

When we explain that they are legally all ASA flights now, the response is almost always: "No—they’re still operating. I see them on FlightAware."

It's an understandable reaction. Without direct ties to the professional industry, it’s easy to be misled by what you see on a flight tracker. What looks like "Hawaiian" on a gate board is actually a marketing gap: a deliberate choice to keep a brand alive even after the operational data has moved on.

In this blog post, I’m peeling back the curtain on how we navigate this paradox. We’ll look at how this merger broke the traditional mold, why FlightAware "lies" to you, and the specific moves we’re making to the platform to ensure your VA stays technically perfect while creating a great user experience.

Back To The Beginning

On December 3rd, 2023, Alaska Air Group, Inc. and Hawaiian Holdings, Inc. announced that they entered into an agreement where Alaska Airlines would acquire Hawaiian Airlines in a $1.9 billion USD all-cash transaction.

Peter Ingram, Hawaiian Airlines President and CEO at the time said, “With the additional scale and resources that this transaction with Alaska Airlines brings, we will be able to accelerate investments in our guest experience and technology, while maintaining the Hawaiian Airlines brand.”

When this specific line, and the facts sheets were released to the press, it raised a few eyebrows in the industry. Normally under mergers, one brand comes out on top. This one broke the mold. The Hawaiian brand is one near and dear to its state, and it was there to stay.

One Certificate, Two Identities

On October 29, 2025, Alaska Airlines received a Single Operating Certificate (SOC) to operate both airlines as two separate brands. From that date, all Hawaiian flights began operating under the ASA callsign. As Alaska Airlines noted, this logically required shifting legacy Hawaiian flight numbers to avoid duplication within the unified AS schedule.

In the press release marking this event, it was noted that the HA IATA code would stick around purely to avoid confusing customers at the gate and on their boarding passes.

Then, on April 22, 2026, the "brain" of the airline moved. Hawaiian’s Passenger Service System (PSS)—the master system for customer service, booking, and schedule management—was retired. This marked the official end of the HA IATA code for the rest of the industry.

From that point forward, every seat sold, every schedule published, and every interline agreement—seats sold to you by one airline to get you on another airline to your destination—became an AS flight.

The Impact On Data Feeds

At SimVector, our infrastructure relies on several distinct data pipelines. While we are actively moving towards the ability to offer static schedules for "non-published movements" (like those found at FDX, UPS and DHL), our primary route for public airline schedules follows a familiar path:

When Hawaiian’s PSS was retired and merged into Alaska’s on April 22nd, that specific chain reported a total drop in HA inventory. To anyone not tracking the technical cutover, it appeared as if an entire airline had vanished from the map overnight. The HA code simply ceased to exist as a valid identifier in primary industry systems, forcing those flights to instantly "reappear" under their new Alaska identities.

The FlightAware Paradox (As of May 2026)

This brings us to the elephant in the room: Why does FlightAware—the industry gold standard—still show the HA code?

To make this dual-branding work, their systems rely on a standard data hierarchy that requires a "Parent" (the operating carrier) and a "Child" (the marketing brand). In their current implementation, FlightAware is explicitly keeping HAL as that "Parent" operating carrier.

This creates a severe technical contradiction. As far as the FAA and the International Air Transport Association (IATA) are concerned, HAL and HA don't legally exist anymore. For their UI to reflect the actual state of the industry, the data relationship must be reversed: the flight is legally an ASA operation using a Hawaiian marketing alias.

We know they are forcing this legacy structure because the raw ADS-B packets, captured in the screenshot below from ADS-B Exchange, shows the ASA callsign.

When you view the same flight (HA1226) on FlightAware, the data is manually "corrected" to match the passenger's expectations, reverting to the retired HAL callsign:

In another example—Alaska 809—the contradiction is even more visible. While the header correctly identifies the flight as ASA809, the system forces an "Operating as Hawaiian Airlines" tag and the map icon still attaches the legacy HAL callsign to the aircraft. This reveals a data relationship where ASA is treated as the "Child" or marketing partner, despite being the legal certificate holder.

Different Tools, Different Truths

There is no "wrong" data here; there is only data prioritized for different users.

FlightAware effectively serves two different user segments depending on the sector. For private aviation and charter operations, they provide comprehensive tools directly to the FBOs and operators who require the operational truth. But for the massive world of commercial airlines, they serve the passengers segment—and for a passenger, branding is the truth.

In 99% of cases, FlightAware can be relied upon to get the data right. This merger, however, is a unique edge case where they appear to have deliberately favored the passenger's experience over the operational reality.

For the family member waiting for their loved one in the cell phone lot, or the passenger attempting to look up the baggage carousel, branding is the reality that matters. If a traveler's ticket says "Hawaiian", the flight crews are all wearing "Hawaiian" uniforms, the gate fixtures say "Hawaiian", and the plane on the apron says “Hawaiian”, they expect to see "Hawaiian" on the screen, the tracking app, and more.

Whether this is a deliberate UX choice coordinated with Alaska Airlines to match airport signage, or simply legacy data lag, is up for debate.

Ultimately, the exact reason doesn't change that SimVector prioritizes our data to serve virtual pilots, and the realities of operations.

Navigating the New Reality

When the Passenger Service System (PSS) cutover finally occurred and customers started noticing missing Hawaiian flights, it created a scenario I wasn't fully prepared for.

Ever since the MVP, we have been improving our schedule product. While we initially accepted lower-fidelity data to serve a specific niche, the platform has evolved into an obsession with true data integrity.

Moving past 'good enough' is a requirement. Modern flight simulation users desire schedule management that is automated, accurate, and realistic to real-world operations.

I believe accurate schedule data is the foundation of a great Virtual Airline or product; it’s the reason you pay for SimVector. However, delivering strict technical accuracy becomes a double-edged sword when dealing with end-user expectations.

The disconnect exists because even the most dedicated simulator pilots are conditioned to trust consumer-facing flight trackers. We are used to that data being absolute. But this merger has created a rare fracture where the 'passenger truth' and the 'operational truth' have simply gone their separate ways.

They will see "HA801" on their favorite tracking app and wonder why it isn’t in Schedule Cloud. They aren't concerned with the nuances of a Single Operating Certificate; they just want to fly the route they saw online.

As a product owner, you eventually have to make the hard calls. For SimVector, the solution is bridging that gap. We must respect the operational reality of the data feeds while accommodating the "one airline, two brands" illusion that users expect to see.

The Implementation Plan

Because we are in such uncharted territory, I am implementing a series of stop-gap provisions within the platform. These are non-intrusive updates focused on providing flexibility without compromising operational accuracy.

The most important thing to stress is that while all flights will operationally reflect a single airline for now, these are non-destructive changes to the data behind the scenes.

While Alaska Air Group has not publicized specific flight number ranges, data-driven observation of the live feeds revealed that flights in the 800–1299 range consistently align with Hawaiian-branded operations.

For The Schedule Cloud API

For developers leveraging the Schedule Cloud API endpoints directly, new metadata fields will be present to programmatically identify a flight’s intended brand. This is handled under a new brand attribute, which returns the appropriate ICAO code for the branding.

First-Party Integrations (phpVMS Module & smartCARS Plugin)

For our smartCARS plugin, we are taking a page out of the Alaska Airlines booking engine by dynamically swapping logos based on the identified flight range. This allows users to see the accurate callsign to be flown for the flight while maintaining the visual identity of the Hawaiian brand.

This, along with a new Operator Search option, are now live.

Subfleet Assignment & Livery Mapping

For phpVMS and vAMSYS users, this merger introduces a secondary challenge: subfleet management. Many VA managers have built their systems around airline-based subfleets, separating Hawaiian-painted tails from Alaska-painted ones. When the callsigns unified under ASA, it threatened to break the logic that assigns a pilot to the correct livery. While I’m still finalizing the implementation details, I have a clear path forward.

In our recent updates to accommodate vAMSYS, we introduced the ability for users to upload their own custom datasets to use within our Transformer and Delivery infrastructure. This tool was originally designed to allow users to map their specific fleet IDs directly to aircraft ICAO codes, and I am now evaluating how to leverage this same architecture to solve the branding problem.

By configuring the transformer to recognize specific "brand" assignments on flights, we can deliver datasets that are fully pre-mapped and ready to roll, significantly reducing your manual workload.

This is a complex problem to implement, but the foundation is already there. I’ll be sharing more technical details on this specific workflow in a follow-up article.

In Conclusion

The Alaska-Hawaiian merger is a case study in the friction between legacy branding and modern data infrastructure. As the industry continues to consolidate, these edge cases will likely become a recurring challenge for anyone managing aeronautical datasets.

If you have a Virtual Airline or application and want accurate schedule data built for you, check out Schedule Cloud today and see how our solution can close the gap.