CASE STUDY: Marabu Airlines improves EFB-to-Operations and Crew Management data handling

Author: Maxim Dubovik, EFB Administrator & Manager, Marabu Airlines

Subscribe

How Marabu Airlines replaced manual post-flight data handling with a fully automated EFB-to-operations integration, without vendor dependency or implementation delays. Maxim Dubovik, EFB Manager, shares the project.

This case study describes how we at Marabu Airlines implemented an automated integration between our EFB, EFBOne by International Flight Support, and our core operations and crew management system, AIMS by AIMS INT. Our Flight Ops IT team was able to design, test, and deploy a production-ready integration without vendor development costs and within a matter of days. What is typically a complex, vendor-driven project became an internal, highly efficient solution driven by operational knowledge and EFB administrator expertise. However, before tackling the main topic, and to provide some operational context, I’ll first introduce readers to Marabu Airlines.

MARABU AIRLINES

Founded in November 2022 and based in Tallinn, Estonia, Marabu’s fleet of Airbus A320 aircraft, utilizes the latest technology for emission reduction, low fuel consumption, and minimal noise, while ensuring the highest level of passenger comfort. We focus on combining the Estonian spirit and digital knowledge with the background of the leisure travel experience to deliver unique and highly modern leisure travel across Europe.

Marabu Airlines operates a fully digital flight operations ecosystem centered around EFBOne from IFS, which we use as a digital solution for cockpit crews to deliver and collect flight data. The high-level data flow within this environment is shown in Figure 1.

Figure 1

THE CHALLENGE WE FACED

Our workflow begins with flight planning in PPS Flight Planning Software, after which flight data flows directly to EFBOne at the request of the pilots. This is one of the key issues we were trying to address because, although operational and crew management data needed to flow from EFBOne into AIMS, our core operations and crew management system, no automatic bridge for that existed so we were using manual transfers. Manual transfers caused delays, data mismatches, and repeated effort between Flight Operations and Crew Control. To address this, we initiated a project to build a direct, automated export link between EFBOne and AIMS using AIMS SOAP (Simple Object Access Protocol) web services, a messaging protocol for exchanging structured information between applications over a network. Our initial setup relied on connecting through middleware connections to AIMS, but this configuration did not meet our operational requirements. Key challenges included:

• Incomplete data export: key information such as actual flight times, fuel usage, delay codes, and crew IDs was often missing.
• Inconsistent unit handling: values were sometimes in pounds rather than kilograms, creating potential for errors in fuel and performance reporting.
• Delay time formatting errors: hours and minutes were occasionally misaligned, complicating reporting and operational analysis.
• No mechanism for multi-pilot operations: the system could not accurately handle take-off and landing combinations involving multiple pilots.

Applying EFBOne Training

Leading the Marabu Flight Operations IT team, I had previously completed the four-day EFBOne Administrator Training provided by IFS. The training gave me hands-on experience with EFBOne’s self-service admin tools, including NEO, EFBOne’s no-code configuration tool, which allows EFB administrators to configure the system to their specific needs, and the export back-office interface. Using this knowledge, I was able to add new fields and Lua conditions, a lightweight script that define rules and logic within EFBOne, with minimal support from IFS. Based on this expertise, we mapped out the steps needed to ensure data from EFBOne would flow accurately into AIMS, setting the stage for the solution approach.

A THREE STEP APPROACH

Figure 2

• The first step was configuring the EFBOne app itself, adding fields and logic to ensure the data would be interpretable and properly formatted for AIMS. We established the architecture for the systems to communicate via SOAP, exporting data from the EFBOne backend to AIMS. This required mapping the two different systems so that AIMS could correctly interpret data from EFBOne. Web service endpoints were configured for both test and production environments to enable consistent data transfer.
• Production Data Scope: We define the data exported, including actual times, delays, crew IDs, performance, and fuel from finalized reports.
• The final stage was validating the rollout plan: First testing the integration in both environments, confirming the data flow was accurate, and then promoting the export process to production.

Step 1: App Setup (NEO)

The first step involved configuring EFBOne using the built-in self-service tool, NEO. Figure 3 presents an example of the condition setup in the app.  

Figure 3

At first glance, the setup in NEO may appear complex, but the training made it easy for the team to understand and apply it effectively. Lua, a simple scripting language, in combination with training, enables non-IT specialists to implement and modify configurations with ease. We added a Lua condition to handle delay times and adapted other fields to ensure the data would be correctly interpreted by AIMS. This specific syntax was created to export delay times in a format that AIMS can understand, with the final line of the syntax converting minutes into hours.

Step 2: Integration Setup

The second part of the project focused on the export interface, as shown in figure 4.

Figure 4

The export interface connection needed to be operated within the back office; it’s a core part of the EFBOne ecosystem. In this context, the primary role was to align the data format to ensure it fully matched the requirements that would be understandable for AIMS. Each field, value, and unit were mapped to ensure compatibility, allowing AIMS to interpret the dataset without errors.

EFBOne maintains its own crew database, which must be synchronized with AIMS’ crew management system. The integration now correctly identifies take-off and landing pilots. Updates in the EFBOne app propagate to AIMS automatically. As an example, adding new crew will automatically start the transfer of crew information. By doing so, we are eliminating manual entries and reducing potential errors.

With fuel logic, fuel units were standardized, to kilograms or liters, across all reports. It’s also necessary to check that the values are actually transferring to the management system, so it’s important to set up the right units for every value. With delay and time handling, delay response and time calculations were standardized to improve accuracy with, for example, late arrival reporting; it’s not a separate part of the data. Since AIMS doesn’t understand individual parts of the data, it is necessary to create an export package with correct data mapping. Additional parameters can be added to provide a broader set of flight data as operational requirements evolve, enabling future-proof flexibility.

Figure 5

Step 3: Validation & Testing

The final step was to validate the export process before going live. The validation loop is ongoing testing in the IFS test environment using simulated flight submissions. This allowed testing that all data flowed correctly from EFBOne to AIMS, without affecting production operations. Once that testing confirmed accuracy, we implemented a two-stage rollout. The configuration ran in parallel configuration in both the Test and the Production environments, with exports initially disabled in Production until fully validated. This approach ensured that both environments behaved identically while minimizing the risk of errors, and without disrupting actual operation. Finally, the export was promoted to Production, fully deploying the tested configuration.

RESULTS

Figure 6 presents a comparison of some key operational metrics before and after the integration.

Figure 6

Before the integration, Flight record entry into AIMS, relied on a manual or middleware-based process, taking five to ten minutes per flight and carrying a high risk of errors due to manual input. After integration, the process became fully automated: pilots submit the post-flight data directly from EFBOne to AIMS with a single action. Data completeness also improved significantly. Prior to integration, only partial data was transferred, with frequent gaps caused by manual handling. Data accuracy now reaches 100 percent for actual times, crew information, delays, and fuel, with the additional benefit that new data can be added as required.

Error rates were another key area of improvement. Previously, SOAP rejections occurred frequently. SOAP will not accept partial data, only the entire dataset. Any input error would cause the export to AIMS to fail. After implementing the redesigned export logic and schema fixes, the rejection rate dropped to below one percent. Before the integration, crew details were verified through manual lookup, the system now cross-checks crew data automatically between flight planning, EFBOne, and AIMS. Operational latency was reduced from delayed OCC visibility to near real-time synchronization. Flight data is now available across departments instantly after submission.

TAKEAWAYS

As with any such project, there are always takeaways to be learned. Some of those we identified are summarized in figure 7.

Figure 7

The project highlighted the importance of thorough dual-environment testing. By validating the export in a dedicated test environment before production, the team minimized downtime and mitigated operational risk.

The EFB administration at Marabu successfully managed a complex integration that is typically handled by vendors and often requires significant airline resources and IT investments. This demonstrates the value of empowering teams through training. With hands-on training, we were able to develop and implement the solution in hours, completing the full integration within three working days with no additional cost.

Finally, the project reinforced that minor coding skills, combined with the right tools and training, can enable teams to manage integrations efficiently. This approach not only accelerates implementation but also builds operational expertise in-house.

OUTCOMES

By September 2025, we had successfully implemented, tested, and promoted the EFBOne-to-AIMS direct integration to production. Now we are fully automating the post-flight data flow from cockpit to crew management, eliminating redundant manual data entry which has ensured improved data accuracy. This positioned Marabu’s Flight Operations IT as a model for integrated airline operations within the IFS EFBOne ecosystem, demonstrating how in-house expertise can deliver fast, cost-effective operational improvements.