Summary
- Hitit has a stronger operating record than a software-brand description suggests. Its audited accounts identify revenue from application use, infrastructure, maintenance, implementation and integration, while the company reported 68 partners in 48 countries at the end of 2025.
- Crane PSS reaches across inventory, reservations, fares, ticketing, payments, agency and GDS distribution, check-in, departure control, loyalty and accounting. That breadth makes synchronization and exception control the real product, because one inconsistent record can affect a sale, an airport interaction and the eventual revenue entry.
- Named airline transitions provide credible evidence that Hitit has executed difficult migrations. They do not publish record-level reconciliations, availability histories or long-run error rates, and the most revealing account describes missing future-booking data, a lost distribution connection, hardware timing and extended support after cutover.
- Hitit's hosting story combines SaaS, Turkish data centres, earlier European facilities, data-centre consolidation and continuing cloud migration. Public material does not provide a current partner-by-partner map of production data, backups, subprocessors or recovery responsibilities.
- The commercial case cannot be reduced to a boarded-passenger price. A buyer must include implementation, interfaces, data conversion, parallel running, support, change work, reconciliation labour and the cost of extracting a usable record set at exit.
A reservation is a promise with a departure time
The visible act of buying a flight takes minutes. The record created by that act may have to remain useful for months, survive changes, cross company boundaries and settle financially long after the aircraft has landed. A passenger chooses an itinerary; an availability result becomes a fare; a fare becomes an order or passenger name record; a payment has to match a ticket; a seat and baggage allowance have to reach the airport; a check-in event has to update departure control; a flown coupon has to reach revenue accounting. Every stage can be handled by a different channel, team or partner. The passenger nevertheless experiences one promise.
That is the right frame for assessing Hitit. The Istanbul company describes Crane Passenger Service System as a web-based suite spanning reservations, inventory and departure control, with connected booking, mobile, allotment, weight-and-balance, baggage-reconciliation and loyalty functions. Its reservation product adds fares, promotions, direct and indirect distribution, GDS and interline work, payments, group bookings and reporting. Its departure-control product takes the record into check-in, boarding, baggage and aircraft-load processes.
Its revenue-accounting product takes sales, ticket, coupon, interline and code-share data into the financial close.
This is not merely a catalogue of modules. It is a chain of dependencies. If inventory is stale, two channels may appear to sell the same scarce seat. If a payment succeeds while ticket issuance fails, the airline has a customer and cash problem at once. If a schedule change reaches the website but not an agency, airport or partner carrier, the record fragments. If the departure event does not return to accounting, flown revenue may remain in suspense. If a passenger change creates a new document without closing the old one correctly, the customer-service and financial teams inherit the mismatch.
Software can automate much of this work, but automation does not remove responsibility for the record. It concentrates it. A broad platform becomes valuable when its components share current, governed and recoverable facts. It becomes dangerous when a green status in one application conceals stale or contradictory state elsewhere. Hitit should therefore be evaluated as an operational data layer behind airline retailing, not as a collection of branded screens.
The company beneath the Crane name
There is a solid corporate base beneath the product language. Hitit's investor information places its registration in Istanbul on June 15, 1994. Its history says former airline executives founded the business and that work on the core passenger-service system began in 2000, followed by a web-based release in 2003. The company later listed shares in Istanbul. Its current shareholding page gives Pegasus Airlines 36.20 per cent of capital and 46.46 per cent of voting rights, while publicly traded shares represent 27.60 per cent of capital.
The 2025 audited financial report is more informative than a global rank or award. It says the group develops software for airlines, travel companies and airports, operates it as a service, hosts it and sells it. It identifies revenue from software packages that manage booking, ticketing, revenue accounting and frequent-flyer processes, as well as flight planning and staff and aircraft information. It also records installation, maintenance, training and other services. That is a recognisable enterprise-software business with implementation and operating obligations, not a directory entry borrowing the vocabulary of aviation.
The numbers reinforce that reading. Hitit reported 2025 revenue of TRY 1.653 billion in its audited statements. Application-use fees accounted for TRY 954.8 million; application use and development for TRY 306.9 million; infrastructure for TRY 136.2 million; maintenance for TRY 131.1 million; and implementation and integration for TRY 79.1 million. Its year-end presentation translated the mix into 68 per cent SaaS, 23 per cent software development and maintenance, and 9 per cent infrastructure-as-a-service and projects. It reported USD 41.9 million in sales revenue and a 43 per cent EBITDA margin.
Those figures do not prove that any particular customer receives a reliable service. They do show where the business has to perform. Most of the economic engine depends on continuing application use, not on selling a licence and leaving. Implementation and infrastructure remain distinct revenue lines. Maintenance and additional development remain material. The supplier is paid across the same boundaries that a buyer must manage: initial transition, ongoing transaction volume, technical operation and adaptation after go-live.
Hitit reported 68 partners in 48 countries on six continents at the end of 2025. It said 49 projects across product groups went live for 11 partners during the year, with 12 more active implementation projects at year end. These are company-reported operating counts, not an independent census. Even so, they are a more useful scale signal than a claim to be the second- or third-largest provider. They indicate repeated implementation work and a portfolio broad enough for shared platform economics to matter.
The operating surface extends far beyond shopping
Airline retailing is often presented as a better shopping experience: richer offers, personalised bundles, more ancillaries and fewer constraints inherited from old ticketing systems. Hitit's public product material supports that retailing ambition, including New Distribution Capability workflows for shopping, orders and payments. Yet the practical operating surface remains larger than the shop-order-pay sequence.
Crane PAX sits near the centre. Hitit says it manages inventory, reservations, pricing, fare construction, promotions, agency distribution, internet and mobile bookings, payments, group bookings, reporting, GDS connections, code-share and interline processes. Each capability creates or consumes shared facts. Inventory needs the latest capacity and booking state. Pricing needs fare rules, customer context and channel conditions. Ticketing needs an accepted payment and an accountable document. Interline work needs two carriers to interpret status consistently.
A refund needs the commercial rule, document state, payment path and accounting consequence to agree.
Crane DCS moves the record from retailing into the physical airport. Hitit describes check-in, passenger information, boarding, baggage acceptance, load control and aircraft checks. It says the product integrates with airline inventory and sends real-time departure-control notifications. It can operate with Crane PAX or with an external core reservation system. The standalone option is commercially useful, but technically it enlarges the integration boundary. The system must know which side owns a field, how quickly events cross the boundary, what happens during disconnection and how conflicting updates are resolved.
Crane Revenue Accounting adds another clock. Hitit says the product consolidates GDS, interline and code-share sales, loads daily industry files, prorates transactions and reports across tickets, coupons, flights, sales and agents. A booking platform can look successful at departure while accounting still carries unresolved value. Exchanges, refunds, no-shows, involuntary changes, partially used tickets, ancillary documents and partner-carrier coupons all create paths where operational truth and financial truth may separate.
The 2025 annual report describes an even wider network. It says reservations travel through Hitit's communication infrastructure to nearly 900 airports in 160 countries; border and customs exchanges cover 123 countries; infrastructure supported about USD 11.5 billion in sales volume through 91 payment systems; and more than 120 airlines were interconnected for interline ticket sales and cross-selling. These figures are not direct measurements available for reproduction here. They are useful because they show the company's claimed control surface.
The more parties and regulatory endpoints a platform touches, the less meaningful it is to judge it from a booking demonstration alone.
Scale is visible; the machinery of consistency is not
Hitit gives unusually large activity indicators. Its annual report says Crane PSS processes more than 300 billion sales-availability requests a year. Its year-end materials say passenger volume on partner airlines rose 26 per cent in 2025. Hitit Oxygen, its newer retailing platform, was presented as handling billions of offers per day. These claims suggest a system built for an enormous ratio of searches to actual passengers, a familiar feature of airline retailing where shoppers and intermediaries request many options before one sale occurs.
Scale, however, is not the same as consistency. A system can answer a large number of availability requests and still mishandle the rare sequence that matters: the final seat sold through two channels, an exchange during a schedule change, a payment timeout followed by a retry, a through-check passenger with an interline partner, or a disrupted journey whose services have partly been consumed. Aggregate volume says little about the tails of the distribution where expensive exceptions live.
The public material does not disclose the private design needed to evaluate those tails. There is no customer-level description of the database topology, replication behaviour, event delivery guarantees, conflict-resolution rules, idempotency controls, cache invalidation, write ownership or degradation mode. There is no published measure of inventory staleness, duplicate orders, payment-to-ticket mismatches, abandoned booking records, failed schedule-change notifications or accounting exceptions. That is not unusual for a commercial passenger-service platform. It is still the missing evidence at the centre of the technical question.
A buyer should convert architecture language into record-level scenarios. When an agency and the airline website request the last seat at the same time, where is authority resolved? When the payment provider returns late, does a retry create another charge or recover the original state? When an airport loses connectivity, which actions remain available and how are they reconciled? When a partner airline changes a segment, what status is authoritative? When a passenger is rebooked during disruption, can every ancillary and coupon be traced from old journey to new?
These questions are more revealing than asking whether a platform is cloud-based. Cloud infrastructure can provide capacity and operational tools. It cannot decide which record wins after two legitimate systems disagree. That rule belongs to the application, the integration contract and the airline's operating procedures. Hitit's breadth makes those rules central to its value, but the evidence for them lives inside customer design, testing and production records rather than on the public product pages.
Migration evidence reveals the real work
Passenger-service migrations are among the strongest parts of Hitit's public record. Royal Brunei Airlines was reported to have switched in March 2022 after nine months of training, testing and configuration. The announced scope covered core passenger services, booking, mobile, airport operations, loyalty and customer care. Drukair issued its own short release in 2025 announcing a completed transition to Crane PSS, with reservations, ticketing, passenger-service, accounting and cargo functions in view. Hitit has also announced transitions for Air Peace and Surinam Airways.
These examples establish that Hitit has not merely demonstrated a product at trade shows. Named airlines have entrusted it with cutovers across several geographies and business models. What the announcements do not provide is equally important. They do not give the number of records converted, the percentage reconciled before cutover, the list of open exceptions, the duration of any sales freeze, the rollback criteria, the volume of manual repair, the first-month incident count or the long-run availability record.
The most revealing migration account is Hitit's 2019 interview with the chief systems officer of Pakistan International Airlines. It is positive customer testimony hosted by the vendor, so its outcome and savings claims should not be treated as independent audit findings. But its description of the work is valuable. The executive said the project faced non-cooperation from the outgoing provider and the unavailability of future-booking data. The planned period was five months, compared with what he called an industry norm of roughly 18 months.
PIA also lost its GDS relationship shortly before cutover, had constraints on project staffing, needed border-security integrations and training, and faced delayed boarding-pass printers.
That list is the migration risk in miniature. The booking database is necessary, but it is not sufficient. Future travel records, ticket documents, loyalty balances, agency access, border messages, airport devices, staff permissions, interline connections and distribution channels all have to become usable together. A cutover can be technically complete while the airline is commercially impaired because travel agents cannot sell. It can preserve reservations but fail at the airport because printers, workstations or common-use integrations are not ready. It can move data but leave staff unable to recognise or resolve exceptions.
PIA's GDS loss led Hitit to provide Agency Portal Plus with billing-and-settlement integrations for agents at go-live. The account also says the full Hitit team stayed for an extended period after cutover to resolve issues, streamline processes and monitor progress. Those details matter more than the celebratory language. They show software adaptation and human support substituting for a broken external dependency. They also show that migration does not end when the new system begins taking transactions. Stabilisation is part of the product.
The interview reports that no flight was cancelled at cutover and describes large savings in PSS and distribution costs. Those statements are relevant customer testimony, but they lack the underlying flight log, contract, invoice set, baseline and measurement period. They should not become universal claims. The responsible conclusion is narrower: Hitit has evidence of executing a difficult national-carrier migration under severe constraints, and the same evidence demonstrates why a prospective airline must demand its own reconciliation, fallback and staffing plan.
Freshness is the product behind inventory
An airline does not need every field to update in the same millisecond. It does need each operational decision to use data fresh enough for its consequence. A shopping cache may tolerate a brief delay if the final sell request returns to authoritative inventory. A boarding decision cannot tolerate a stale no-fly or document status. A revenue report may run after departure, but it must not quietly omit an exchanged coupon. Freshness is therefore a policy attached to each record and event, not one platform-wide number.
Hitit's materials repeatedly use the language of real time. Crane DCS is said to integrate with inventory and notify departure events in real time. Crane Revenue Accounting is marketed as providing real-time revenue data while loading some industry files daily. Those statements can both be true because they refer to different processes. They also illustrate why a buyer should ask what "real time" means at every boundary: creation-to-visibility latency, expected polling interval, end-of-day file arrival, maximum tolerated lag, or simply an interface that refreshes without a batch operator.
The data-quality problem begins before migration and continues after it. Source systems may hold duplicate passengers, malformed contact details, inactive agencies, inconsistent airport codes, unclosed coupons or fare rules interpreted differently by channel. Conversion can preserve those defects perfectly. New interfaces can create fresh defects if status values or timing assumptions do not match. A platform needs validation, ownership and exception queues, while the airline needs people authorised to decide what the correct business state should be.
The useful operating measures are consequently specific. An airline should track inventory conflicts, payment authorisations without documents, documents without confirmed payments, queue age, failed schedule-change messages, unacknowledged partner events, check-in synchronization failures, baggage-status gaps, unmatched flown coupons and manual accounting adjustments. It should distinguish failures created inside the platform from failures arriving through airports, GDSs, payment providers, border systems and partner airlines. Without that separation, every incident becomes a debate about ownership while the passenger waits.
Public evidence cannot establish Hitit's performance on those measures. It supports that the relevant modules and integrations exist and that airlines have moved onto them. It does not show a production error budget, reconciliation dashboard or customer-level exception history. The absence is not a verdict that the controls are weak. It is a reason to make freshness and consistency evidence a contractual and operational requirement rather than accepting module coverage as a proxy.
Data locality needs a workload map, not a headquarters address
Hitit is a Turkish company with headquarters in Istanbul, but the location of the company is not the location of every airline record. The hosting evidence spans several periods and models. Hitit's history refers to a production centre in Amsterdam and a disaster-recovery centre in Frankfurt launched in 2019. An older Crane hosting page refers to an Istanbul Tier III facility, daily backups, 24-hour monitoring and cloud-enabled recovery. The 2025 annual report says two independent data centres in Istanbul and Ankara were set up and commissioned, and that the architecture was redesigned for a cloud-native approach.
The same annual report says data-centre consolidation was completed and that work continued with major cloud providers. It describes initiatives to move relevant services to cloud environments and says feasibility work was under way for moving the payment platform. These statements are not necessarily contradictory. A SaaS platform can use private facilities, public cloud and dedicated regional arrangements at once. The problem for a customer is that the broad corporate story does not identify the exact arrangement for its workload.
Data-sovereignty analysis must begin with classes of data. Passenger identity and contact records, travel documents, payment references, loyalty histories, border submissions, airport events, operational logs, support attachments and backups can follow different paths. Some data may need to reach a government in the destination country. Some payment data may be tokenised or processed by a third party. Some diagnostic logs may contain enough detail to become personal data even if the primary database remains elsewhere.
A serious residency schedule should list production storage, replicas, backups, logs, analytics, support tools and disaster-recovery copies. It should name the legal entity providing each service, the country and region, the transfer mechanism, the retention period and the staff groups able to access it. It should also show which choices are standard and which require a separate deployment or price. A generic statement that the service is cloud-based or hosted in secure facilities does not answer those questions.
Hitit's 2025 report says its processes align with Turkish personal-data law and relevant international rules, and it names PCI DSS, a SOC 2 Type 2 report, penetration and vulnerability checks, and tested continuity plans. Those are meaningful control signals. They do not substitute for the actual report scope, exceptions, system description, subservice organisations and customer responsibilities. Nor do they prove that every airline's regulatory obligations are identical. The public evidence supports governance activity; it does not provide a complete data-location or assurance map for a buyer.
Availability and recovery claims need present-tense evidence
The Crane hosting page makes specific claims: a 99.8 per cent service-level agreement, daily backups, continuous operation and monitoring, and disaster recovery within 30 minutes. Precision is attractive, but an older public page cannot be treated as the current contract for every Crane service. A service-level percentage needs a measurement window, scope, exclusions, maintenance policy and remedy. A recovery claim needs to say whether it refers to infrastructure restoration, application availability or complete recovery of current airline records.
At 99.8 per cent availability, the permitted interruption is materially larger than many buyers may assume for a system used around the clock. More importantly, an aggregate platform figure can hide a partial failure. Search may work while payment does not. Airport check-in may work while agency sales fail. The core application may be available while a border connection, GDS or partner feed is down. An airline needs service objectives for critical journeys and dependencies, not one percentage detached from business effect.
Backup is similarly easy to overread. A daily backup says nothing by itself about the amount of data an airline could lose, the time required to restore, the consistency of connected systems or the proof that restored records can be used. If bookings continue while a related payment or ticketing system is restored to a different point, reconciliation may be harder than recovering the servers. The decisive evidence is a recovery exercise that follows records across applications, verifies interfaces and measures the manual work left afterwards.
Hitit's 2025 report says business-continuity and disaster-recovery plans have been prepared, implemented and periodically tested. That is stronger and more current than a static backup claim. Yet the report does not publish the dates, scenarios, achieved recovery times, data loss, unresolved findings or partner participation. A buyer should ask for the latest exercise relevant to its proposed architecture, including a regional outage, database corruption, identity-provider failure and loss of a major external connection.
Recovery ownership must also be explicit. Hitit may operate the application and infrastructure, while the airline controls network links, airport devices, user administration or local interfaces. Payment processors, government endpoints and GDSs remain outside both parties' direct control. The recovery plan should define who declares an incident, who can invoke failover, who validates passenger records, how sales channels are reopened and who communicates with airports and agencies. Recovery is an operating agreement supported by technology, not a property of backup media alone.
Payments and ticketing expose the exception burden
Hitit reported about USD 11.5 billion in 2025 sales volume moving through its infrastructure and integrations with 91 payment systems. The scale is company-reported, but it places payment exceptions near the centre of commercial risk. A small mismatch rate applied to a large payment base can produce a substantial queue of charged-but-unticketed orders, duplicate attempts, expired authorisations, failed refunds, disputed transactions and accounting breaks.
The IATA ARM profile for Hitit's airline product records validated workflows for customer-card payment, settlement platforms, payment on an existing unpaid order, mixed instruments, refunds, summaries and recovery. This is credible evidence that the product can exchange the relevant standard messages and execute defined workflows. IATA's own registry warns that it does not validate product quality or endorse commercial products. A validated payment-recovery capability is not evidence of a particular recovery rate under load.
An airline should therefore follow the state transitions. What happens if the payment provider approves but the response reaches Crane after the booking expires? Can a second attempt find and reuse the original authorisation? How does the system distinguish a retry from a new purchase? If ticket issuance fails after payment, is repair automatic, queued or left to an agent? If a refund crosses currencies or payment methods, where is the outstanding liability visible? How quickly do airport and customer-service staff see the corrected state?
Revenue accounting is the final check, not merely a back-office feature. Hitit says Crane RA processes sales from GDS, interline and code-share sources and automates proration. The important outcome is not that files load. It is that the airline can explain the path from order through document and service delivery to recognised revenue, and can isolate every break. Public materials do not provide exception rates, closing times, unreconciled balances or staff effort. Those are the measures that turn automation into an economic result.
This is also where product boundaries matter. A payment provider may own the authorisation failure; a GDS may resend a message; an airline rule may be configured incorrectly; an airport agent may choose the wrong action; or the platform may mishandle the state. A mature operating model needs shared identifiers, logs, ownership rules and response times that let the parties locate the break. Without that observability, the software may reduce routine labour while making the hardest cases slower and more expensive.
Standards show reach, not the quality of an airline outcome
Hitit has a current and substantial IATA Airline Retailing Maturity presence. The registry lists Hitit as a system provider for airlines and sellers. Its airline profile, last changed in June 2026, records Crane NDC workflows across shopping, orders, payments and setup, along with message versions. It includes order creation and change, cancellation, ancillary shopping, seat availability, payment recovery, a testing environment, negative cases, bug tracking, support, onboarding, documentation and order-level permissions.
That is useful technical evidence. It shows that Hitit's retailing proposition is connected to defined industry messages rather than resting only on marketing language. It also indicates breadth across the life of an order, including changes and recovery rather than the happy path alone. For an airline trying to modernise distribution, this matters because sellers and partners need predictable exchange formats.
The registry's disclaimer is equally important. IATA says it does not validate the quality of an applicant's activities or products, compare their relative quality or endorse commercial products. A capability can be validated while a customer implementation remains incomplete, poorly configured or operationally fragile. Message conformance does not establish response time, uptime, accurate inventory, successful settlement or staff readiness.
Standards also do not remove coexistence with older records. Airlines continue to use ticketing, electronic miscellaneous documents, GDS distribution, interline agreements, airport systems and government messages while the industry moves toward offers and orders. Hitit itself markets both modern NDC functions and traditional network-carrier capabilities. The operational challenge is translation without losing meaning. A new order and an older ticket representation must not drift into two versions of the passenger's entitlement.
The commercial promise of modern retailing is flexibility. The operational obligation is stricter record control across the transition. A buyer should inspect actual partner certification, end-to-end scenarios and exception handling for the versions it will deploy. The registry is the beginning of that examination, not the conclusion.
Local support is part of the technical system
Enterprise software is often described as if the customer buys capability and labour disappears. Hitit's own migration evidence points in the opposite direction. PIA's transition required staff training, airport hardware coordination, border integrations, an alternative sales channel and an extended period of on-site support. That labour was not evidence that the software had failed. It was part of making a complex system usable under real constraints.
Hitit's annual report gives a specific local-support example. It describes a Karachi office with three Pakistani staff, four Hitit employees working remotely in Pakistan, five employees dedicated to supporting PIA at the airline's headquarters and two employees attached to a wholly owned software-development subsidiary. It also describes an Amsterdam branch focused on international industry work. The audited financial notes report 427 group personnel at the end of 2025, while broader company narrative uses a rounded figure of approximately 500 professionals.
The Pakistan detail matters because local support is more than a sales office. A team at an airline headquarters can understand local agency practices, regulatory messages, staff routines, language, escalation paths and the practical consequences of a change. It can shorten the distance between an operational symptom and a product or configuration decision. For a platform touching airports and government systems, time zone and context are part of response quality.
Local presence is not automatically sufficient. Five dedicated people may be a strong arrangement for one partner and irrelevant to another. Buyers need to know named roles, coverage hours, seniority, language, escalation authority and access to engineering. They should distinguish relationship managers from people able to inspect logs, correct configuration, coordinate a recovery or approve a release. They should also understand what happens when several partners experience disruption at once.
Labour economics should include the airline's side. A new platform may reduce infrastructure administration, routine accounting or manual distribution work, but migration creates data cleansing, mapping, training and parallel-run tasks. After go-live, somebody must own fare rules, agency access, queues, schedule changes, payment exceptions, airport configuration and reconciliation. A claim of lower staffing has meaning only if it counts the work transferred to central teams, local stations, vendors and external integrators.
Hitit's long operating history and repeated implementations suggest accumulated expertise. Its public record does not show support-ticket response by severity, time to resolution, backlog, first-contact resolution, partner satisfaction or the proportion of incidents requiring engineering. Those are not reasons to dismiss the support model. They are the evidence needed to price it. In this category, knowledgeable people are not an accessory to the platform; they are part of its control system.
The commercial test is total operating cost and reversibility
Hitit's reservation product page says pricing is based on boarded passengers. Its investor presentation says passenger numbers form the basis of SaaS revenue. This aligns supplier income with an airline's traffic more closely than a large fixed licence might. It may lower initial infrastructure ownership and allow a smaller carrier to consume a broad suite. It also means cost grows with the operating measure specified in the contract, so definitions and tiers matter.
A boarded-passenger price is only one line in the economic model. The audited report separates application use, development, infrastructure, maintenance, implementation and integration. That separation reflects the real work. A buyer may pay for interfaces, data conversion, airline-specific changes, testing, training, travel, on-site support, environments, security review and new industry messages. Internal teams spend time on mapping, acceptance, station readiness and exception cleanup. The previous provider may charge for data extraction or cooperation. Parallel running can duplicate costs before it reduces risk.
Hitit's PIA interview reports very large savings in PSS and distribution costs. It is a notable customer statement, but there is not enough public information to reproduce the calculation. The baseline supplier scope, passenger volume, distribution mix, implementation cost, currency, support model and comparison period are absent. Another airline should not import that percentage into its business case. It should build a workload and contract model from its own transaction volumes and operating design.
Compute and storage economics remain partly hidden by SaaS packaging. A boarded-passenger charge may include routine hosting, but the contract still needs to address unusually high shopping traffic, logs, retention, test environments, analytics, file transfers, backups, bespoke integrations and peak capacity. Hitit's claim of hundreds of billions of availability requests illustrates why look-to-book traffic can matter even when revenue follows boarded passengers. The supplier has to fund that demand somewhere, whether through shared economics, tiers, protections or separate services.
Lock-in is both technical and operational. The data includes future bookings, tickets, ancillary documents, payments, loyalty records, agency profiles, fare configuration, interline status, airport settings and accounting history. Interfaces and business rules accumulate around the platform. Staff learn its queues and vocabulary. An airline can retain legal ownership of its data and still face a difficult exit if the export lacks relationships, history or usable documentation.
The PIA account shows the risk from the other side: non-cooperation by the previous provider and unavailable future-booking data made migration harder. That should influence every Hitit contract. The airline needs recurring exports before termination, not merely a final extract after relations deteriorate. It needs formats, identifiers, field definitions, attachment handling, historical depth and reconciliation reports. It needs a test showing that exported bookings, documents and balances can be interpreted outside the platform. It also needs transition assistance with clear rates, staffing and deadlines.
The economic question is therefore not whether Hitit costs less than the current stack in year one. It is whether the combined platform, infrastructure, implementation and labour cost produces better control over the airline's records through growth, disruption and eventual exit. A lower unit fee can be consumed by manual exceptions. A higher fee can be justified if it removes interfaces and reconciliation work. Only a complete operating model can tell the difference.
What a buyer should ask to see
The public evidence is sufficient to justify serious diligence. It is not sufficient to complete it. Hitit can point to an audited recurring software business, named airline migrations, broad product coverage, a current IATA capability record, security and continuity activity, and local support in at least one major market. A buyer should now ask for evidence at the level where those claims become an airline outcome.
First, the buyer needs a current service boundary. It should list every selected module, external dependency, operating party and authoritative record. It should show where inventory, orders or passenger name records, tickets, payments, airport events, loyalty entries and accounting records are created and reconciled. For each interface, it should define normal latency, timeout behaviour, retries, duplicate control, alerting and manual fallback.
Second, the migration plan should start from data rather than dates. The airline should receive field mappings, conversion rules, trial-load results, exception counts and reconciliation thresholds. Future bookings, partially used documents, refunds, group records, loyalty balances and agency access deserve their own scenarios. Cutover criteria should say what must be complete, what can remain in a controlled queue, who can accept residual risk and what conditions trigger rollback.
Third, the airline should run end-to-end operational exercises. These should include a normal sale, payment timeout, duplicate submission, exchange, refund, schedule change, interline journey, disrupted flight, airport disconnection, border-message failure, baggage event, flown-coupon return and accounting close. The result should be measured across channels and records, not declared successful because one interface returned the expected screen.
Fourth, hosting and recovery evidence should match the proposed deployment. The buyer needs the current regions, facilities, cloud services, subprocessors, backup locations, retention, encryption ownership and privileged-access process. It should see service reports and a recent recovery exercise with achieved times and unresolved findings. The contract should separate core availability from critical external integrations and define reporting and remedies.
Fifth, the support design should name people and authority. The airline needs coverage by severity and time zone, escalation to engineering, on-site expectations during cutover, response and resolution measures, change windows, release controls and surge arrangements during widespread disruption. It should price its own local super-users, reconciliation analysts and station support instead of assuming the vendor absorbs all operating work.
Finally, the exit plan should be tested while the relationship is healthy. The airline should obtain representative exports, documentation and a reconciliation method before go-live. It should preserve the right and practical ability to extract future travel, document history, financial balances, configurations and audit records on a recurring basis. Reversibility is not pessimism. In a mission-critical data platform, it is part of continuity.
The evidence supports a platform, not a blank cheque
Hitit Bilgisayar Hizmetleri Anonim Sirketi is not a thin company name wrapped around generic cloud language. Its accounts, product documentation, standards record and customer transitions support the existence of a substantial airline software and services business. The breadth of Crane is commercially significant: a carrier can place reservation, distribution, airport, loyalty and accounting functions with one provider, while Hitit's SaaS model and repeated implementations offer a plausible route away from fragmented legacy systems.
That breadth also concentrates consequence. The platform sits where an availability answer becomes a paid promise, where that promise becomes an airport action and where the action becomes recognised revenue. The decisive capability is not any one module. It is the ability to keep the records coherent, explain exceptions and recover them when infrastructure or a partner fails.
Public evidence gives encouraging but incomplete answers. Named airlines have cut over. Hitit reports large operating scale, current standards capabilities, security work, continuity exercises, data-centre investment and local support. Yet customer-level freshness, availability, recovery, residency, exception rates and total cost remain outside the public record. Older hosting claims also need to be reconciled with the company's current hybrid and cloud-transition story for each workload.
The appropriate verdict is neither a brand endorsement nor a dismissal. Hitit has earned a place in a serious airline technology evaluation. It has not made the detailed operational case on a public page, and no responsible buyer should expect it to. The next step is to turn broad capability into record-level evidence: migrated bookings reconciled, payment exceptions controlled, airport events synchronized, backups restored, locations documented, support staffed and exports proven usable. That is where an airline discovers whether the software is merely comprehensive or genuinely dependable.