10/04/2026
It’s time to take a breath. After a long and demanding period, we’ve reached a critical milestone in a large scale airline project. The entire migration was delivered by our Telcotrend team, going well beyond our leadership role in the end-to-end solution design.
We gained valuable experience integrating with the CAE (FlightScape) portfolio, including CAE Crew Manager, Movement Manager, and the Training & Scheduling solution.
Let’s take a look at the four main areas our team was responsible for:
— 𝐄𝐧𝐝-𝐭𝐨-𝐄𝐧𝐝 𝐒𝐨𝐥𝐮𝐭𝐢𝐨𝐧 𝐃𝐞𝐬𝐢𝐠𝐧 —
Covering all 70 integrations, we shifted the mindset from file- and table-based data transfers to an API- and messaging-driven approach. We gathered and documented all necessary details, using SAMU for architecture management.
— 𝐃𝐚𝐭𝐚 𝐌𝐢𝐠𝐫𝐚𝐭𝐢𝐨𝐧 —
Crew, flights, pairings, rosters — by now, these core airline concepts are second nature to us. The legacy and target systems take fundamentally different approaches to these objects, and we ensured accurate translation between the two worlds.
From a performance perspective, our solution can convert six months of data in just 70 minutes. Data loading into the target system is handled via APIs defined per object type. The process is implemented as an executable BPMN workflow that manages all dependencies and orchestrates up to 50 parallel threads running across multiple remote machines. It is a textbook example of a distributed system.
Along the way, we also became familiar with LIFUS, ground trainings, layover duties, training-specific flight positions, and many other intricacies while migrating data from AIMS to CAE FlightScape.
— 𝐄𝐯𝐞𝐧𝐭 𝐏𝐫𝐨𝐜𝐞𝐬𝐬𝐢𝐧𝐠 𝐚𝐧𝐝 𝐑𝐞𝐥𝐚𝐲 —
The Crew Manager module uses a specific approach for event distribution. It assumes that subscriber systems expose APIs with a defined payload, which Crew Manager invokes.
To simplify the architecture, we implemented a protocol converter system called EPR. It receives relevant events from Crew Manager, enriches messages where necessary, and distributes the resulting events via IBM MQ.
— 𝐀𝐏𝐈 𝐏𝐫𝐨𝐱𝐲 —
Certain system-specific characteristics of Crew Manager APIs required special handling. One notable example is how crew-related data is requested and returned based on the time zone of the crew’s home base.
For instance, what appears to be May 1st may actually correspond to April 30th 22:00 for a Budapest-based crew, while February 1st may map to January 31st 23:00 due to daylight saving changes.
The proxy enables third-party systems to work with intuitive dates (e.g., May 1st or February 1st) while transparently handling crew-specific time zone offsets.
If you’re facing challenges in the airline domain, feel free to reach out — we’re happy to help.