Post-acquisition technical integration · non-confidential overview
Engineering-side requirements definition, architecture selection and delivery coordination to integrate Kopter’s flight-test data analysis environment into Leonardo’s corporate IT ecosystem — without pausing flight testing.
01 — Context and trigger
Following Leonardo’s acquisition of Kopter, corporate IT launched a global initiative to rationalise IT services, laptops, datacenters and infrastructure across business units—primarily to eliminate duplicate systems and decommission the existing Swiss datacenter infrastructure. The project was driven by post-acquisition corporate integration and cost efficiency, rather than by any cybersecurity shortcoming on the Kopter side.
The Flight Test Data Analysis (FTDA) environment, however, operated under constraints fundamentally different from standard office IT: supporting flight-test campaigns required local administrative autonomy, custom Python processing pipelines, automated task scheduling, and rapid delivery of flight data to engineering teams.
As the designated IT focal point for the FTDA team, I represented flight-test engineering from the early scoping phase. The baseline objective was clear: preserve and improve all operational capabilities required for flight test within the Leonardo corporate environment, with zero operational interruption.
This was a sustained multi-year effort rather than a single migration event: scoping began in late 2023, the first requirement drafts and the consultant interviews ran through the first half of 2024, technical implementation started around June 2024, and architecture, migration and delivery work continued through 2025 and 2026. The environment is in operational use, with a number of integration items still being closed out.
02 — Operational constraints
Directly migrating FTDA systems into standard corporate IT was unworkable. FTDA required remote server access, flexible Python software and package installation, scheduled task automation, administrative privileges for data ingestion, certificate management for internal dashboards, and tight connectivity with Flight Test Instrumentation (FTI).
Standard corporate policies strictly forbid local administrative privileges on managed workstations. Routing routine engineering scripts and scheduled tasks through corporate IT helpdesk tickets was considered, but a ticket-based model was incompatible with the volume and pace of day-to-day engineering scripting and tooling that flight-test operations depend on.
Furthermore, during aircraft development campaigns, data had to reach Leonardo engineering within approximately 2 hours of landing to support go/no-go decisions for subsequent flights. The core challenge was therefore to find an architectural and operational model that satisfied strict corporate cybersecurity rules without choking engineering agility.
03 — Architecture trade-offs
Fully managed corporate environment. Provided corporate service integration, but restricted the administrative privileges required for FTDA automation, including scheduled tasks, custom Python tooling and agile script development.
Isolated engineering network physically and logically detached from corporate systems. Preserved full operational autonomy, but created an isolated island with no direct connection to Leonardo services, severely impeding data distribution and remote collaboration.
The selected target architecture. An established Leonardo model providing a segregated engineering zone with local administrative autonomy, connected to corporate services through strictly governed firewalls and monitored pathways.
The Leonardo Business Network (LBN) was an established corporate architecture. Based on FTDA’s operational requirements, I evaluated the three options and selected LBN as the solution for flight-test engineering. Specialist Leonardo teams owned and implemented the corporate network, routing, virtual desktops and firewall policies, while I owned engineering-side requirements, technical acceptance and local FTDA firewall mapping.
Selected operating model
The selected LBN model keeps specialised flight-test engineering capabilities in a segregated environment and connects them to Leonardo corporate services through governed interfaces. Antoine owned the engineering-side requirements, selection, acceptance and coordination; Leonardo specialist teams owned corporate infrastructure implementation.
LBN
Leonardo
Approved flight-test outputs
04 — Role evolution and ownership
External consultants were initially engaged to collect requirements and explore potential solutions. Their engagement later ended. After their departure, no formal project or programme manager was appointed to lead the FTDA workstream. Without holding a formal PM title, I progressively took on de facto delivery coordination—defining operational milestones, managing a Jira epic and tasks, following up blockers across matrixed teams, escalating bottlenecks, conducting technical acceptance and leading user cutover.
05 — Delivery and dependency management
After the consultants left, I structured the engineering workstream around a single operating question: “What must work for us to operate as before?”
Delivery progressed through functional capabilities rather than a rigid linear schedule, using focused coordination, Jira tracking and escalation without hierarchical authority to clear dependencies across corporate IT, network, cybersecurity, cloud and engineering teams.
Formalised FTDA and FTI workflows into clear technical criteria for administrative autonomy, storage, remote access and data turnaround.
Assessed three network models against operational needs and selected LBN as the viable balance between security and autonomy.
Integrated local hardware and configured the FTDA firewall for IP address mapping into the Leonardo corporate network.
Validated and rolled out Virtual Desktop Infrastructure to restore secure remote engineer access to internal processing machines.
Specified ~100 TB of cloud storage capacity and pushed the target deployment past temporary workarounds through escalation.
Coordinated the engineering-side migration of the central DIAdem data-access service to a new server in a corporate datacenter, re-establishing access, connection instructions and licences for ~50 downstream engineers.
Retained legacy access until workflows were verified against the acceptance checklist, authored user documentation and transitioned users with zero downtime.
Retained ongoing engineering ownership for environment evolutions, new user setups, hardware refreshes and residual troubleshooting.
06A — Blocker resolution
Context: routine approval for an essential code-management and analytics network exposure was frozen for weeks when an approver in the chain left without a designated handover.
Action: mapped the multi-stage approval chain across cybersecurity and IT, tracked down the orphaned request in the queue, re-engaged the relevant department leads and escalated until the approval process resumed.
Outcome: unblocked the stalled approval process and enabled the requested network exposure to proceed through the corporate governance workflow.
06B — Blocker resolution
Context: a temporary file-transfer workaround kept daily operations moving, which caused corporate teams to deprioritise the permanent cloud storage deployment.
Action: demonstrated the operational limitations and long-term unsuitability of the temporary workaround, maintained steady technical pressure and escalated the bottleneck to CIO level.
Outcome: re-established priority for deployment of the permanent ~100 TB cloud storage solution.
07 — Operational continuity
Flight-test campaigns could not be paused for corporate IT integration. Maintaining uninterrupted operational continuity was a non-negotiable requirement.
Rather than executing a high-risk cutover, legacy laptops and network paths were maintained in parallel alongside newly issued corporate hardware.
While dual-hardware operation added temporary administrative overhead, it provided a guaranteed operational fallback. Legacy access was retained until the required FTDA workflows had been verified against the acceptance checklist. The migration was achieved with zero operational interruption to flight testing.
08 — Controlled data delivery
Segregating the engineering environment from the standard office network meant that legacy direct-file-share access had to be replaced by a compliant, automated delivery path.
I contributed to defining the secure data distribution workflow that moves approved flight datasets from local LBN processing hosts to corporate cloud storage and downstream engineering users.
Flight-test data is ingested and processed in the LBN zone, where administrative autonomy and specialised Python tools are preserved.
Processed flight-test datasets are automatically uploaded through secure outbound pathways to the corporate cloud environment.
Uploaded packages traverse corporate security validation and access controls before publication to authorised consumer tiers.
Approved flight-test data is served to ~50 DIAdem engineering specialists, and distributed reports reach up to ~200 wider recipients.
The workflow is intentionally non-confidential; internal addresses, firewall configurations, cloud tenant names, credentials and security products are omitted.
09 — Scope and scale
These user counts represent distinct groups at different interaction tiers and must not be aggregated into an artificial total; they are also a different population from the engineering data consumers cited on the flight-test data operations case study. In-scope hardware (~15 servers and workstations, alongside multiple storage platforms) was integrated and reconfigured in place rather than physically replaced. The architecture preserved the operational capability required to make flight-test data available to engineering within approximately two hours of landing.
10A — Post-delivery ownership
I remain the primary engineering focal point for the LBN environment—qualifying needs, coordinating hardware refreshes, managing storage and firewall requests, and troubleshooting cross-domain dependencies such as share authentication in mixed-domain setups.
10B — Architecture reuse
The integration approach established during the main migration was subsequently reused for a portable offsite LBN, replicating the core architecture to support an extended flight-test campaign away from the main site.
11 — What the integration required
The work turned specialised operational requirements into an architecture decision that specialist teams could implement, then kept that decision moving through corporate governance: capability-led milestones, persistent follow-up on blockers, escalation when approval chains stalled, technical acceptance against operational criteria, and a cutover that kept flight testing running throughout.
The engineering-side scope was mine; the corporate network, virtual desktop and cloud implementation belonged to the Leonardo specialist teams. What remains with me afterwards is the environment itself: its evolutions, its new users and its residual troubleshooting.