Migrating to Leon from another flight operations system

This article draws on several dozen migrations onto Leon, from approximately ten different flight operations platforms. The operators involved range from small AOCs with three aircraft to large operators running mixed managed, charter and ACMI fleets across multiple AOCs and operating bases. Each source system has its own data model, its own definition of what constitutes a trip, and its own accumulated set of operator-specific workarounds.

The process has five stages:

Requirements gathering and analysis of the operator's organisation
Data migration
System configuration
User training
Migration of the company onto the new system

The numbering indicates dependency rather than sequence. Stage 1 precedes the rest, since it produces the decisions the other stages implement, and stage 5 concludes the project. Stages 2, 3 and 4 run concurrently and continue to inform one another: mapping decisions in the data workstream depend on configuration objects being defined, configuration is validated against imported data, and training exposes gaps in both. Treating them as three sequential phases extends the project without reducing its risk.

Data, configuration and derived data

Most misunderstandings in a migration project trace back to treating these three categories as one. They are handled in entirely different ways.

Data is what the operator has recorded: flights and trips, positionings, duties and rosters, crew members and their ratings, passengers, aircraft, quotes and invoices, crew documents and training records. Data is imported.

Configuration is how the system behaves: privileges and roles, document and email templates, mailbox configuration, duty type definitions, report logic, checklist structure, tagging rules, FTL rule sets, per diem rules. Configuration is not imported. It is rebuilt as a set of explicit decisions.

Derived data is what the system calculates from data using configuration. FTL is derived. Currency and pilot recency are derived. Duty and flight time totals, rest calculations, certificate validity and crew availability are derived. Derived data is neither imported nor configured — it is computed, and it can be recomputed.

Consequences for troubleshooting

FTL is the clearest case. FTL values are not imported; they are calculated by Leon's FTL engine from imported flights, positionings and duties, according to the operator's configured rule set.

When an operator compares FTL figures in Leon against their legacy system after an import and the numbers differ, the first assumption is usually that the import was faulty. In our experience it rarely is. If flights, positionings and duties reconcile — and these are straightforward to verify independently — then a discrepancy in FTL is almost always a difference in FTL engine configuration: how a duty type is classified, when a duty is considered to start, how standby is treated, which rest rule applies, how a split duty is handled. The correct response is to adjust the FTL configuration and recalculate FTL against the new configuration. The same applies to currency, pilot recency, training validity and the rest of the category.

Stage 1 — Requirements and analysis of the operator's organisation

The objective of this stage is specific: establish how Leon must be configured to match how this particular operator is organised, which integrations need to be activated, and what functionality is missing and therefore requires development.

Two things have to be established here. They are related but they answer different questions.

The first is the operator's structure, because it determines the account topology and everything built on top of it. The foundational decision is whether the operation is modelled as a single operator with multiple bases, or as several operators linked to one another. That choice follows from how the business is actually constituted: the number of AOCs and legal entities, whether crew and fleet are shared between them, whether each entity has its own post-holders and its own reporting obligations, whether commercial and operational responsibility sit in the same place. It sets the scope within which privileges can be granted, the boundaries of reporting and document numbering, and how integrations are attached. Revising it later is expensive, because the rest of the configuration is built on it.

The second is how the operator works day to day, and here the objective is to map the operating reality rather than the org chart. Who raises a quote and who accepts it. Whether crew planning and OCC are the same desk at night. Whether aircraft are owner-managed and what the owner is permitted to see. Whether subcharter and ACMI are handled by the same people as own-fleet flights. Where maintenance data originates and who is responsible for entering it. Which department owns the passenger manifest.

Together these produce the user role definitions and the privilege configuration implemented in stage 3: the structure determines the scope each role can reach, the working practices determine what each role is actually permitted to do within that scope.

Three outputs matter:

A configuration blueprint — the decisions that stage 3 implements.
An integration list — what has to be activated, in which direction data flows, and which system is authoritative for each object. This covers handling agents, CAMO and maintenance systems, accounting, flight planning providers, EFB, catering and fuel vendors.
A gap list — functionality the operator requires that Leon does not currently provide, separated into what is needed before go-live and what is needed subsequently. The first group becomes development scope with a delivery commitment; the second goes onto the roadmap. Making that separation at this stage prevents late-project blockers.

One pattern recurs across operators. A significant proportion of existing procedures exist because the legacy system could not do something. Reproducing those procedures in Leon reproduces the constraint without its cause. Stage 1 is the point at which to establish, for each process, whether it reflects a genuine requirement or an adaptation to a limitation that no longer applies. Operators who make that distinction tend to finish the migration with a simpler operation than they started with.

Stage 2 — Data migration

Data migration is carried out by a dedicated migration engine rather than by one-off scripts. The engine accepts data from files — JSON, XLSX, CSV, XML and other formats — and from APIs. The source can therefore be an export supplied by the outgoing vendor, a direct read from the legacy system's API, or a combination.

2.1 Research of the source data model

This is the largest single element of the data workstream, and it is analysis rather than development. Before mapping can begin, the source system's representation of reality has to be understood:

How trip, leg and rotation relate to one another, and whether the source has a concept of a trip at all.
Timezone handling — UTC or local, field by field, and whether it is applied consistently.
How cancellations, diversions, return-to-ramp and technical stops are stored: as flags, as separate records, or as deletions.
Soft-deleted records, superseded versions, and duplicates created by earlier imports into the legacy system.
Code sets: aircraft types, airport identifiers and the handling of non-ICAO fields, crew position codes, duty codes, tags, and free-text fields that are in practice being used as structured data.

The final point warrants emphasis. Most mature operators have at least one free-text field carrying operational meaning by convention. Identifying those before the mapping is written is a substantial part of the value of this stage.

2.2 Mapping to Leon's data model

The mapping is the deliverable of this stage. Where the two models align, it is mechanical. Where they do not, operator decisions are required, and those decisions need to be recorded rather than made implicitly by whoever writes the transformation. Typical decision points: how legacy duty codes map onto Leon duty types, how positioning is distinguished from ferry, how ACMI and subcharter flights are represented, how a passenger record without a unique identifier is deduplicated, how partially completed quotes are treated.

Two scoping decisions belong here as well:

How much history to migrate. The practical answer is enough to satisfy the FTL and recency lookback windows, plus the reporting and audit horizon the operator actually requires. Requests for the complete history are common and materially increase both effort and the volume of legacy data-quality issues carried forward.
What not to migrate. Data the operator does not trust in the legacy system will not become trustworthy by being moved. In some cases the appropriate decision is to leave it behind and retain read-only access to the old system for the retention period.

2.3 Testing the import with the client in a non-production environment

Imports are tested and re-tested in a non-production environment, with the operator involved, before anything is applied to production. The process is iterative and normally takes several rounds.

The division of responsibility is important. Structural integrity can be verified on our side: record counts, referential consistency, absence of orphaned assignments, absence of impossible timestamps. Semantics can only be verified by the operator — whether a given trip in fact happened that way. The reconciliation should therefore be designed around checks the operator can perform independently:

Aggregate reconciliation: block and flight hours per aircraft per month, number of flights per aircraft per month, duty days per crew member per month.
Targeted checks on difficult cases rather than simple ones: a multi-leg trip with a technical stop, a cancelled and rebuilt trip, a diversion, a split duty, a flight that changed aircraft, a crew member who changed position mid-trip.
Derived-data checks last, interpreted as configuration findings in line with the section above.

A systematic mapping error found in this environment costs a re-run. The same error found after go-live costs an operational incident.

Stage 3 — System configuration

Configuration runs alongside the data workstream rather than after it. It implements the stage 1 blueprint and covers, as a minimum:

Privileges. Built from the organisational analysis rather than copied from legacy roles. This is also where owner and client access to managed aircraft is defined precisely.
Sales and OPS document templates. Quotations, charter agreements and invoices on the sales side; flight briefs, GENDECs, handling requests, crew briefings, loadsheets and journey log outputs on the OPS side. Templates are rebuilt in Leon's templating system; the operator's branding and legal wording carry over, the mechanics do not.
Report building in Report Wizard. Report logic is configuration and is rebuilt. When operators list the legacy reports they consider indispensable, that list typically contracts once actual usage is examined. Rebuilding the reports that are genuinely in use, correctly, is more effective than reproducing forty reports approximately.
Duty types for rostering. These underpin both the roster and the FTL calculation, and they carry a hard dependency on the data workstream: the duty type set must be defined before the duty mapping can be finalised. This is the most common coupling point between the two workstreams and is worth scheduling explicitly.
Training and certificate requirements. Requirements per crew position and aircraft type, which drive currency, recency and validity — all derived, and all only as accurate as this configuration.

Concurrency here is not unconditional. Several configuration objects — duty types, aircraft types, crew positions, tags — must exist before data can be imported against them, so the dependency runs from configuration into the import. This is one reason a migration cannot be handed to a data team in isolation, and the reason the two workstreams need a shared schedule for the specific objects that gate each other rather than simply running side by side.

Stage 4 — User training

Training runs concurrently with the data and configuration workstreams rather than waiting for them to complete. The sequencing constraint is per role, not per project: a department can be trained once its own configuration is in place and a test import has loaded data representative of its work. Sales training can therefore begin while duty type mapping is still open, and crew planning training while sales templates are still being built.

The one condition worth holding to is that training takes place on a system containing the operator's own data rather than demo data. Users learning a roster view on their own crew, their own aircraft and last month's actual trips learn faster and place more confidence in the result. This is a further argument for early test imports: they serve the data workstream and the training workstream at the same time.

Running training in parallel also produces findings that the other two stages need. Users working through their real tasks identify configuration gaps, misinterpreted mappings and missing data that structured testing does not surface, and they do so while there is still time to act on it.

Training is organised by role rather than by module — OCC, crew planning, sales, crew members using the mobile app and journey log — since each group requires a different subset and a different depth. For larger operators, training a small group of superusers who then support their own departments is more effective than training several hundred users directly, and it leaves the operator with internal expertise once the project closes.

The output that persists is the operator's own procedures documented against Leon rather than a generic manual.

Stage 5 — Migrating the company onto the new system

The cutover has two components: execution of the data migration, and the transfer of users and operations.

Executing the data migration

The import developed and tested in stage 2 is executed against production. Because the engine supports incremental loading, this is not a single event: one large initial import is followed by a series of smaller delta imports carrying whatever has changed in the legacy system in the interim.

Transferring users and operations incrementally

Switching dozens of aircraft and hundreds of users in a single night constitutes an operational risk, and we do not recommend it. The approach we recommend is incremental in two respects.

Incremental data loading. One large import, followed by many smaller delta imports of changed data. This decouples the data cutover from the operational cutover, so the operational switch does not depend on a long-running load completing successfully within a maintenance window.

Cutover by aircraft group. From a defined point in time, the operator handles all flights in Leon — but only for part of the fleet. Immediately before each group goes live, a short delta load of changed data is run for those specific aircraft. The step is repeated, group by group, until the entire fleet is operated in Leon.

The boundary is the aircraft, and it needs to be observed strictly. For a migrated aircraft, everything happens in Leon — dispatch, crew assignment, documents, journey log — across every department, with no exceptions made in the legacy system. Splitting a single aircraft between two systems during the transition is a frequent source of operational error.

This stage typically takes between two weeks and two months, depending on fleet size and on how quickly the operator can reach decisions and act on findings.

Practical considerations during the transition

FTL is crew-based while the cutover is aircraft-based. During the dual-run period crew will fly both Leon-managed and legacy-managed aircraft. Leon's FTL calculation is only correct if it has the crew member's complete duty and flight history, including duties flown on aircraft that have not yet migrated. Delta imports must therefore continue to load flights, positionings and duties for not-yet-migrated aircraft throughout the transition. This is the most frequently underestimated aspect of an incremental cutover and should be designed in from the start.
Record the authoritative system per object. For each aircraft and each data type, one system is the source of truth at any given moment. Ambiguity here is what produces contradictory handling requests.
Freeze windows for delta loads should be short, announced, and scheduled around the operation rather than the project plan.
Integrations switch with the aircraft group where possible. Establish for each integration whether it can be scoped per aircraft. Some can; those that are all-or-nothing require a separate decision on timing.
Legacy write access should be restricted as each group migrates. Removing the ability to make updates in the old system is the most reliable way of preventing them.
Order the groups by risk rather than convenience. A small, well-understood, lower-tempo sub-fleet first. The first group is where issues that the test environment did not surface will appear, and exposure should be minimal at that point.

Duration

Migration should not be treated as a race. Compressing the schedule does not reduce cost; it converts project risk into operational risk, which is an unfavourable trade for an AOC holder. Each operator should proceed at a pace it can sustain.

For the data workstream, timings are reasonably predictable:

Two to four weeks to prepare the import when migrating from a given source system for the first time. Most of that is the data model research and mapping described in stage 2 rather than transformation code.
A matter of days when the source system is already known and has been imported from before. This is where accumulated mappings in the migration engine make a measurable difference, and it is the part of the timeline that genuinely compresses.

The data migration is not the critical path. Most of the elapsed time in migrating a company is spent migrating the operation, and that pace is determined by the complexity and scale of the operation, by how quickly the operator can make and communicate decisions, by the availability of the people who know how things currently work, and by the operational calendar. An operator in peak season with a single overloaded project owner will move slowly regardless of the quality of the import.

In summary: the data workstream is predictable and comparatively fast, while the elapsed duration of a migration is set by the organisational workstream. The schedule should be planned accordingly, at a pace the operator can maintain, with safety of operations as the governing constraint.

Conditions that determine the outcome

A named owner on the operator's side with authority to make configuration decisions and sufficient time allocated to do so.
Configuration decisions made rather than deferred. Deferred decisions resurface as go-live blockers.
Willingness to change a process where the legacy process was a workaround.
A realistic history scope, agreed early.
Recognition that a derived-data discrepancy is a configuration finding rather than an import defect.
An incremental cutover, with the crew-continuity implication designed in from the outset.