The Invisible Connection: How Sheremetyevo Rebuilt Baggage Operations on Domestic Software

A passenger sees the baggage system only twice: when a suitcase disappears behind the check-in desk and when it arrives on the destination carousel. Between those moments, an airport must identify the route, perform security controls, cross terminal areas, absorb flight changes and deliver every item to the correct aircraft. Moving transfer-baggage control to new software is therefore not an ordinary information-system replacement. It is an intervention in a continuous production line with rigid deadlines and costly errors.

Vedomosti reported on June 16, 2026 that Sheremetyevo, Russia's largest international airport, moved control of transfer-baggage transport between terminal complexes to domestic software supplied by Reksoft. The system manages movement between the northern complex containing terminals B and C and the southern complex comprising terminals D, E and F.

Reksoft chief executive Alexander Egorov described the transition, and Dmitry Ilyin, deputy chief executive for information technology at JSC MASH, the airport's legal entity, confirmed it. The parties did not disclose the price. Expert Anastasia Bezrukova estimated that a comparable turnkey project, from research and development through industrial commissioning, could cost RUB 350–700 million. For companies in Russia, the case shows how localization of critical technology becomes a discipline of reliability, supplier governance and provable operational readiness.

A baggage system is production with a minute-by-minute takt

An airport is often understood as a service venue, but baggage handling resembles distributed manufacturing. Objects of different sizes and conditions enter, receive identifiers and routes, then pass through security, sorting, accumulation and loading. An aircraft leaves according to a schedule, so unfinished work cannot simply be moved to the next day. The production window is measured in minutes.

Transfer bags are more complex than originating items. Their routes depend on the first flight's actual arrival, connection time, the next departure terminal, passenger status and operational changes. One delay alters priorities for hundreds of objects. Software must do more than follow a prepared plan; it has to recalculate work rapidly without losing the physical actions already completed.

Management should treat baggage handling as one chain rather than a collection of conveyors and screens. A reader fault, an incomplete message from the flight system or an incorrect manual action can produce the same outcome: the suitcase does not fly. Accountability for the final result has to cross the boundaries of equipment, software and departments.

Connecting two terminal groups creates a distinct risk

The northern and southern complexes are separate operating zones. The longer the physical route, the more places an item can stop, lose identification or arrive late for the next stage. The application must know not only the destination but also confirmed location, available capacity and the time remaining before loading closes.

Continuity of custody is essential for transfers. At every segment, one system and one shift must be clearly responsible for the item. A handoff between zones cannot rely on the assumption that the next party received a message. It requires a confirmed event, a common clock and the ability to reconstruct the sequence after an outage.

Spatial complexity deserves a dedicated risk model. A short connection, an oversize suitcase, a manual inspection and a gate change can occur together. The service should raise priority before physical delivery becomes impossible. That forecast is more useful than an alert generated only after the bag misses its flight.

Domestic code does not remove architectural accountability

Software origin does not guarantee reliability. The operator needs a comprehensible architecture, controlled dependencies, reproducible build procedures, documentation and specialists able to restore the service. Localization has commercial value when it reduces the risk of unavailable updates and support, rather than merely replacing a supplier name in a contract.

The developer should disclose which components are built internally, which libraries are used and how versions are governed. Rights to repair, protected access to source and reproducible builds are especially important in a critical system. If only one team can produce a working release, concentration risk remains regardless of jurisdiction.

The airport should own the process model and configuration data. A supplier may understand implementation better, but routing rules, service levels and operational priorities remain the operator's responsibility. This boundary allows technology to change without losing operating knowledge.

Migration should begin with dual observation

Switching a critical line by turning the old system off and the new one on creates avoidable risk. Before controlling physical equipment, the replacement can receive the same events in shadow mode and calculate decisions without executing them. Teams compare routes, response times and exceptions, exposing differences before passengers are affected.

The next stage constrains scope to a time window, baggage type or transfer segment. Stop conditions must be defined in advance. Rising uncertain states, increased manual handling or delayed messages should automatically return control to the proven mode rather than trigger a long meeting while operations continue to deteriorate.

Full transition follows several load cycles, including morning and evening peaks, schedule disruption and recovery. A successful quiet shift is not evidence of readiness. The system must remain stable precisely when flights move and volumes rise at the same time.

A common event model joins digital records to physical reality

Every suitcase generates an observable sequence: check-in, acceptance, screening, scan, entry to a segment, exit, accumulation and loading. An event should contain an identifier, time, place, source and confirmation quality. A record that says sent without who sent it or where it went has little investigative value.

Physical reality sometimes moves ahead of digital records. A worker carries an item manually, a reader misses the tag, connectivity returns and messages arrive out of order. The architecture has to accept late evidence, prevent duplicated work and distinguish an inferred location from a confirmed one.

A common vocabulary reduces dependence on particular hardware. A conveyor, manual station and mobile reader report different actions in comparable formats. One scanner or segment can then be replaced without rewriting the whole application, while the end-to-end audit trail remains intact.

Routing must explain an exception

A normal algorithm chooses a path using the flight and available time. Operators, however, spend more attention on exceptions: damaged tags, rescheduled flights, closed zones, oversize objects or passengers who do not continue their journeys. The system should not merely stop an item. It should name the cause and offer an allowable next action.

Explainability does not require exposing a complex formula. Staff need facts: the destination changed, a stated number of minutes remains, the automatic route is unavailable and manual delivery is recommended. Such a message permits verification and encourages consistent behavior across shifts.

Unexplained alerts quickly lose authority. When employees repeatedly see false warnings, they learn to bypass control. Every exception should be connected to an outcome and thresholds reviewed. The purpose is not to maximize signals but to prompt timely action.

Observability must answer an operating question

A technical log can hold millions of lines and still fail the shift. Operators need to know where a queue is growing, how many items have uncertain status, which flight is approaching its deadline and which segment stopped confirming movement. The dashboard should be organized around decisions, not the internal names of software modules.

Measures need both spatial and temporal context. Daily average speed conceals a ten-minute stop in one corridor during several short connections. Teams need distributions, the longest delays and comparisons among similar load intervals.

Every alert receives an owner and response time. A red indicator without an addressee merely decorates a screen. Each level should have a predefined first check, permitted workaround and escalation point. After recovery, the service must show whether every accumulated item has again received a valid route.

Manual mode belongs to the primary system

Conveyors and applications inevitably stop. Reliability is defined not by the absence of failure but by the capacity to continue critical operations safely. Manual mode needs mobile readers, printed or offline lists, marked accumulation points and transport between zones.

A workaround must preserve traceability. Staff confirm acceptance and handoff even while the primary connection is unavailable, and events synchronize after recovery. If a manual action exists only in a shift's memory, the digital service displays the wrong location and creates duplicated work.

An exercise should use genuine constraints: some devices unavailable, connectivity absent and several flights changing at once. Observers measure decision time, identification errors and human workload. The procedure is then simplified rather than expanded with more pages of instructions.

Cybersecurity must preserve movement as well as restrict access

The baggage system interacts with flight, passenger, equipment and employee data. A compromised account or message can stop a line or route an object incorrectly. Protection begins with network separation, least privilege, verified updates and rigorous logging of administrative actions.

A security measure can itself halt production. Updates, certificate changes and the blocking of suspicious equipment should be tested in a reserve environment and have a rollback plan. The security function is responsible not only for preventing access but also for recovering capability safely.

Backups matter only after a recovery test. Teams must restore configuration, routes and logs in a clean environment, measure elapsed time and confirm integrity. For an airport, the important fact is not that an archive exists but when the line can accept real objects again.

The supplier becomes part of round-the-clock operations

A project worth hundreds of millions of rubles cannot be evaluated only through a functional checklist. Contracts need response times, specialist availability, critical-defect repair, update compatibility and knowledge transfer. Successful commissioning is the beginning of years of operation, not the end of developer accountability.

Support should see the same facts as the airport. A common incident log, agreed severity levels and access to telemetry reduce arguments about which side caused the problem. Supplier access must still be limited by time and role so diagnostic convenience does not create a permanent privileged entrance.

Knowledge should be distributed among several people. Joint duty shifts, code walkthroughs and recovery scenarios prepare the internal team. Dependence falls not when documentation is formally handed over, but when another specialist can execute a procedure without the system's original author.

Economics should be measured through avoided disruption

The RUB 350–700 million estimate describes a broad full-cycle project and is not Sheremetyevo's disclosed actual price. An investment decision needs a cost structure: development, hardware, integration, testing, training, redundancy, support and later changes. Cheap commissioning may create expensive operations if every modification requires unique work.

Returns extend beyond direct license savings. A delayed suitcase creates owner delivery, complaint processing, compensation, additional labor and reputational harm. A line failure delays a flight and consumes ground-team time. Even a modest reduction in the frequency and duration of these events can carry substantial value.

The financial model should compare scenarios rather than offer one payback date. It tests normal operations, passenger growth, a serious loss of external support and the need for a rapid process change. A local solution is valuable when it narrows the worst-outcome range at an acceptable ongoing cost.

Testing must reproduce inconvenient reality

A laboratory suitcase with a pristine tag does not represent traffic. Tests should include crumpled and partially covered labels, oversize objects, repeat scans, delayed messages, cancellations and terminal changes. The system must preserve one understandable state amid conflicting inputs.

A load test creates not only high average volume but also a sudden packet of events after delayed arrivals. The database, message queue, operator dashboard, mobile devices and support staff are tested together. If the central engine survives while notifications lag, the operation still loses control.

The airport owns the acceptance program. The supplier can help automate scenarios, but criteria must reflect the operator's risk. A defect that does not disturb a demonstration may be critical during a night shift or manual transfer.

People need to understand state, not source code

Operators do not need to study internal architecture. They need to distinguish final, pending and unconfirmed states, know the safe action and understand consequences. Training should use realistic situations rather than button sequences from an ideal journey.

Shift roles should rehearse together. Dispatch, engineering, airline representatives, security and loading see different portions of a problem. In an exercise, they build one picture around a common event number and clock. This reveals communication gaps before a real peak.

Employee feedback is production data. A repeated handwritten note or workaround indicates that the interface does not fit the process. The product team should observe work on site and remove the cause instead of treating a familiar bypass as proof that conditions are acceptable.

Metrics must connect suitcase, flight and system

Technical availability expressed as a percentage does not reveal the passenger outcome. An application can formally be running while delivering priority items too slowly. Measures should include on-time loading, missed connections, manual handling, uncertain states and full recovery time.

A daily operational-readiness dashboard

1. the share of transfer bags delivered to the correct flight before loading closes;
2. journey time between northern and southern terminal groups by percentile;
3. items without confirmed location beyond the agreed threshold;
4. manual rerouting share and leading exception causes;
5. accidental duplicates, wrong destinations and corrections after loading;
6. outage duration, detection time and time to clear accumulated flow;
7. passenger cases and subsequent delivery cost per thousand items.

Measures should be connected rather than optimized separately. Faster conveyors are pointless if incorrect routing rises. Lower manual work is dangerous if the system hides uncertainty. The common objective is delivery that is both timely and demonstrably correct.

The first hundred days determine operating quality

During the first weeks after transition, an expanded team reviews long delays and every loss of confirmed location each day. Unrelated changes are restricted, fixes are released in small batches and rollback is tested. The purpose is to learn quickly without introducing many new variables.

After one month, forecast and actual load should be compared. The constraint may prove to be a manual station, task dispatch or timetable synchronization rather than the main corridor. Resources move according to evidence even if the original project emphasized a different component.

By the end of the period, temporary workarounds are either automated or removed. Service levels are refined using actual distributions, training is updated and serious incidents become new tests. The system is mastered when the organization can change it safely, not merely keep the initial release running.

The lesson extends far beyond an airport

The baggage-control transition illustrates a general route for localizing critical technology. An organization first defines the final operating outcome, then owns the data model and acceptance tests, transfers control gradually and builds support around recovery. The sequence also applies to warehouses, ports, production lines and urban infrastructure.

The major mistake is to treat import substitution as a procurement event. Replacing a license does not create independence if architecture is opaque, knowledge belongs to one specialist and an update cannot be safely reversed. Real resilience appears in daily procedures and the ability to prove system state.

Sheremetyevo and Reksoft have taken a significant industrial step: a domestic control layer directs physical movement between remote terminal zones. The next test occurs not at a presentation but whenever a delayed arrival leaves a short connection. If software, equipment and people deliver the item on time and can explain every transition, localization becomes a measurable operating advantage.