Modernizing an Aeronautical Data Pipeline Without a Maintenance Window

There is a category of system for which the phrase "maintenance window" is a polite fiction. Aeronautical data pipelines sit squarely in it. The National Airspace System does not pause for your cutover. NOTAMs keep arriving, airspace schedules keep changing, and the downstream systems consuming your data include some that people are actively flying against. On the FAA programs we support, the availability record we are held to is five nines.

So how do you replace the engine while the aircraft is in flight? The honest answer is that you don't. You build a second engine alongside the first, route a little air through it, watch it very closely, and only when it has earned your trust do you let it carry load. The software industry calls this the strangler pattern, after the fig that grows around a host tree until it can stand on its own. It is the only migration approach we recommend for systems with no acceptable downtime, and after multiple modernizations of operational NAS systems, including moving national aeronautical datasets to AWS GovCloud and re-architecting a monolithic altitude reservation system into microservices, we have learned that its success is decided somewhere unglamorous: in the quality of your test data.

The pattern is the easy part

The mechanics of a strangler migration are well documented and, frankly, not that hard to design. You place a routing layer in front of the legacy system. You carve off one capability at a time, rebuild it on the modern stack, and shift traffic to it incrementally while the old implementation stays warm behind you. Every step is reversible. If the new component misbehaves, you route back and nobody downstream ever knows.

On paper, this eliminates the maintenance window entirely. In practice, the pattern only removes the scheduled outage. It replaces it with a subtler risk: the new component that behaves almost exactly like the old one. Almost is the operative word. A rebuilt service that returns the same answers as the legacy system for 99.7 percent of inputs is not 99.7 percent done. It is a production incident with a delivery date you have not learned yet, because the remaining 0.3 percent is never uniformly distributed. It concentrates in the strange cases, and aviation data is a museum of strange cases.

Where the strangeness lives

Aeronautical datasets accumulate oddities the way old houses accumulate wiring decisions. Airspace boundaries defined by arcs around center points that no simple polygon library reproduces exactly. Facilities in territories where longitude conventions have historically been mishandled. Records that reference each other across datasets that update on different cycles, so a perfectly valid input on Tuesday becomes an orphan on Thursday. Fields whose format was constrained by a teletype standard older than most of the engineers now migrating them.

The legacy system handles all of this, not because its designers were prophets, but because it has been patched every time reality disagreed with it, in some cases for decades. Those patches are the system's real specification. The documented requirements describe what the system was supposed to do; the accumulated fixes describe what the world actually required of it. A strangler migration that tests the new component against the documented requirements is testing against the wrong document.

What the test data has to be

This is the demand the pattern places on you, and it is steep. Your test data cannot be synthetic, representative, or curated. It has to be the real thing, at production shape and production volume, replayed through both implementations with the outputs compared field by field.

Three practices make this workable.

Parallel-run comparison as the primary gate. Before any capability takes live traffic, both implementations process the same production stream and a comparison harness diffs every output. Not spot checks. Every record, every field, every cycle. The diff report becomes the true migration backlog: each discrepancy is either a defect in the new system, an undocumented behavior worth preserving, or a legacy bug you are about to fix on purpose, and it deserves to be classified as one of the three before cutover, not after. On our programs, this discipline runs in the FAA's test environments against replayed production loads before a release ever sees a readiness review. The same principle scales up to entire workflows. When NAV CANADA took our altitude reservation management capability into production in October 2024, it ran in parallel with the legacy manual process for months before exclusive cutover, so trust in the new path was earned on live operations while the proven one stayed in place. During development of that capability we also mined the archive of historical mission messages to enumerate the real universe of formats, abbreviations, and edge cases, and every parsing change since is regression-tested against that archive. The archive is the specification.

Replay across cycle boundaries, not just within them. Aeronautical data moves on 28-day and 56-day publication rhythms, and the hard defects hide at the seams: the correction that lands two days after a cycle, the record that changes identity between loads, the consumer that ingests on a lag. A test corpus that covers one clean cycle proves very little. You want the messy cycles, the ones your operations staff still remember by name.

Test doubles for the partners you cannot schedule. No operational data pipeline exists alone. It talks to external systems owned by other organizations with their own release calendars, and you cannot make your regression testing hostage to their availability. On one of our airspace programs, the team built a full test double of an external subscription client precisely so migration testing could proceed without waiting on another contractor's integration schedule. The double paid for itself within months. Every serious strangler effort ends up building several of these, and the earlier you accept that, the smoother the middle of the migration goes.

The payoff for the discipline

Run this way, a migration stops being an event and becomes a routine. Each cutover is small, rehearsed against real data, and reversible. The deployment guide has been dry-run with the operations team before production sees it. The smoke tests after each shift are confirming what the parallel run already proved. Our teams have taken releases into operational NAS systems for years on this discipline, through cloud migrations and re-architectures and the availability numbers stayed where the mission requires them.

The strangler pattern gets the credit in the retrospectives, and it deserves some. But the pattern is just choreography. What actually protects the mission is the unglamorous decision, made early, to treat production-fidelity test data as a first-class deliverable of the migration rather than a nice-to-have of the test team. Systems with no maintenance window grant no grace period for learning their edge cases in production. You either bring the edge cases into the lab, or the lab results are a rumor.

Jason Cunha is Vice President, Aerospace at Concept Solutions, where he oversees the company's FAA and adjacent services portfolio following program management roles within the FAA's NextGen and Air Traffic Organization.