TLE Catalog Numbers Have Run Out: Migrate Your Orbit-Data Pipeline

The failure mode is no longer theoretical. CelesTrak’s live GP-format notice records exhaustion of five-digit catalog numbers on July 11, 2026 and states that newly cataloged objects numbered 100000 and above do not have General Perturbations (GP) data available in CelesTrak’s TLE format. The alternative OMM-oriented formats are not a new 2026 product: CelesTrak introduced them in May 2020.

What changed in 2026 is the operational boundary your software can no longer postpone. The CelesTrak GP data format guidance, published May 27, 2020 and updated June 23, 2026, documents that provider history.

For satellite-operations teams, flight-dynamics engineers, ground-segment developers and data-pipeline owners, the decision is therefore not “TLE or OMM?” in the abstract. It is whether every interface from provider query to database join can preserve a catalog identity wider than five characters, retain the orbital-data semantics that SGP4 expects, and prove what data was actually used downstream.

This runbook treats TLE to OMM migration as a data-integrity change. It follows a record through acquisition, parsing, canonical identity, storage, propagation input, caching, freshness, observability and recovery. It deliberately stops before maneuver planning, conjunction triage or operational authority. A parser that accepts a six-digit satellite catalog ID is only the beginning; the migration is complete when the ground system can demonstrate lossless identity, source-aware semantics, controlled freshness and a reversible software cutover without deleting the objects the change was meant to support.

Define the failure caused by the five-digit boundary

The dated trigger is catalog-number exhaustion, not the invention of the Orbit Mean-Elements Message (OMM) or JSON. CelesTrak says its CATNR query accepts one to nine digits, but the legacy TLE format cannot represent objects above 99999; its live notice says objects at 100000 and above are now outside that TLE delivery path. CelesTrak also changed the default GP query output to CSV on May 9, 2026, so a client that omits FORMAT can experience a serialization change even before its parser encounters a wider identifier.

A missing row in a TLE response is not evidence that the spacecraft or debris object disappeared. It can be an interface limitation. That distinction belongs in ground-control operating responsibilities: the data-pipeline owner must distinguish provider coverage from physical status before an operations consumer acts on an absence.

The cutover gate is simple: no downstream consumer should receive the new feed until absence, truncation and serialization mismatch are separately observable. A six-digit identifier that becomes five characters is a quarantine condition, not a warning.

Inventory every place that assumes a TLE identifier

Start with an interface inventory, not a parser rewrite. Five-digit assumptions often survive in places that never parse a TLE: ORM models, message buses, CSV exports, filenames, monitoring labels, database indexes, join keys, dashboards, test factories and integer format strings. Search for widths and semantics together: CHAR(5), VARCHAR(5), \d{5}, %05d, substring slices, zero-padding, “NORAD number” aliases and schemas that conflate catalog number with object name.

Keep three identities separate. NORAD_CAT_ID is the catalog identifier used by the GP/OMM data path. OBJECT_ID is the international designator. OBJECT_NAME is a human-readable name and can be missing. The CCSDS Orbit Data Messages standard, Issue 3 (April 2023), defines these as distinct OMM concepts, while CelesTrak notes that names and international designators can be unavailable for some objects.

This is also where satellite design and operations ownership matters: widening a data key is a software/data change, while deciding whether an orbit record is acceptable for a flight use remains an operations and flight-dynamics responsibility.

Prevent duplicate identities during transition. Do not create one row keyed by legacy text 01234 and another keyed by canonical 1234 unless the provider contract says those are distinct. Preserve the raw provider token for audit, but normalize a separate canonical key under an explicit rule. The inventory is complete only when every producer, store and consumer has an owner and a test artifact proving wider-ID behavior.

Choose a provider-specific format contract

Do not migrate to “OMM” as if it were one wire format. The CCSDS Orbit Data Messages standard defines OMM content and both Keyword Value Notation (KVN) and XML representations; the CCSDS XML Specification for Navigation Data Messages, CCSDS 505.0-B-3 (May 2023), defines the XML message structure. CelesTrak additionally offers JSON and CSV using OMM field names and definitions.

CelesTrak documents that null, blank or redundant fields may be omitted from those convenience formats. Those JSON/CSV responses are therefore not byte-for-byte full OMM KVN or XML messages.

Pin the contract at four levels: provider, endpoint/query, serialization, and parser/library revision. For CelesTrak GP ingestion, always set FORMAT explicitly because the omitted default became CSV on May 9, 2026. Record the expected content type and reject a payload whose structure does not match the selected format.

There is a version detail worth making visible. Current CCSDS 502.0-B-3, published April 2023, defines OMM 3.0 as the Blue Book version while retaining OMM 2.0 as a previously supported version; its examples use CCSDS_OMM_VERS = 3.0. CelesTrak’s documentation still recommends XML OMM Version 2.0, and its live KVN example at the research cutoff reports version 2.0. Treat that as a provider/version contract difference, not something to “correct” in transit.

Legacy TLE and Alpha-5 compatibility boundaries

Alpha-5 is a compatibility mechanism in some parsers and data ecosystems, not a universal solution to provider coverage. The python-sgp4 maintainer documentation, accessed September 15, 2026, records Alpha-5 and OMM support in its December 16, 2020 changelog and shows an Alpha-5 parsing example. That proves a library capability for its supported range; it does not prove that CelesTrak will encode today’s 100000+ GP objects as Alpha-5 TLEs.

Operational rule: keep Alpha-5 behind an explicit provider-plus-parser contract. Never synthesize an Alpha-5 or numeric TLE solely to give a high-numbered OMM record a “legacy baseline.” That fabricates compatibility evidence the provider did not supply.

OMM-keyed JSON and CSV versus full messages

CelesTrak documents CENTER_NAME=EARTH, REF_FRAME=TEME, TIME_SYSTEM=UTC and MEAN_ELEMENT_THEORY=SGP4 as examples of redundant fields omitted from its JSON/CSV. A current CCSDS OMM 3.0 example uses MEAN_ELEMENT_THEORY = SGP/SGP4, illustrating why a local adapter should not apply a generic “OMM default” without naming its source contract.

For CelesTrak JSON/CSV, a controlled adapter may inject only documented provider defaults, and it should record which values were inferred rather than transmitted. Data from another provider must be validated against that provider’s own contract. “OMM-keyed” is not permission to assume identical omissions, versions or metadata.

Preserve catalog identity through storage and joins

A safe satellite identifier migration uses a canonical representation that is wider than today’s known boundary and does not depend on arithmetic. CelesTrak accepts CATNR values from one to nine digits, and CCSDS OMM defines NORAD_CAT_ID as an integer field used with SGP/SGP4 mean elements. Store the canonical identity as a decimal string large enough for the provider contract, while retaining the raw provider value separately. That avoids integer overflow surprises, preserves audit evidence and prevents display formatting from becoming identity logic.

A proposed local schema is below. Field sizes are engineering choices, not provider requirements.

The canonicalization rule should be boring and reversible. For a decimal provider catalog number, validate digits, remove only semantically insignificant leading zero padding for the canonical key, and preserve the raw token. Do not coerce an Alpha-5 token through this decimal rule. If a provider changes identifier syntax, that is a contract revision requiring a new parser path.

The schema migration needs dual-read or dual-write only where it helps verify compatibility. Do not leave two authorities indefinitely. Before production widening, prove these acceptance conditions:

• A supported six-digit and a proposed nine-digit fixture survive API, parser, database, queue, export and UI round trips unchanged.

• Legacy records join to the same domain objects before and after canonicalization.

• No join falls back from catalog ID to OBJECT_NAME merely because the wider key is unfamiliar.

• Database indexes, uniqueness constraints and foreign keys are rebuilt or widened consistently.

• Backups and restore tooling preserve the wider schema and rows.

A principal-engineer cutover should fail closed if any downstream system truncates the key. It is safer to quarantine a record than to create a plausible-but-wrong identity that later joins orbital elements to the wrong operational object.

Validate epoch, units and propagation semantics

Changing serialization must not silently change orbital semantics. CelesTrak describes GP data as Brouwer mean elements fitted for propagation with Simplified General Perturbations 4 (SGP4). Skyfield’s Earth Satellites documentation, accessed September 15, 2026, explicitly warns that the familiar element names in a TLE are not simply generic Keplerian osculating elements. Treat OMM as a way to carry mean-element data and metadata, not as evidence of a higher-accuracy orbit or a reason to switch propagators.

CCSDS OMM defines mean motion in revolutions per day, angular elements in degrees, and BSTAR in inverse Earth radii for the SGP/SGP4 parameter set. It also carries the epoch and metadata such as reference frame, time system and mean-element theory. Validate these before constructing a propagation object.

Pin the propagation implementation as part of the test configuration. The current python-sgp4 package documentation says it propagates SGP4/SDP4 and returns TEME position in kilometers and velocity in kilometers per second; its OMM initializer uses WGS72 by default, while versions since 2.25 allow an explicit gravity-constant argument. The package version shown at the cutoff is 2.27, released July 3, 2026.

Do not infer arbitrary identifier-width support from OMM or Alpha-5 support. The python-sgp4 2.22 changelog says the library checks that satnum is never greater than 339999. A data layer can therefore preserve a provider’s wider identifier even when this particular propagation path cannot initialize it. In that case, retain the record, mark propagation as unsupported for that interface, and do not remap the identity to make the library accept it.

That does not mean WGS72 is universally the right mission setting; it means the differential test must hold the chosen setting constant. Record library version, gravity constants, time conversion path and error-code handling. If TLE and OMM paths produce different outputs, first ask whether the input values or configuration differ before calling the serialization “more accurate.”

Build a differential parser fixture corpus

A migration needs two kinds of evidence: differential fixtures for objects representable in both paths, and independent fixtures for identifiers that the legacy path cannot represent. Keep the fixture corpus under source control with provenance, generator version, expected parser status and expected semantic status. Archive public samples only where your use policy permits; use clearly marked synthetic data for boundary conditions.

Separate three verdicts. Parse validity asks whether the bytes conform to the expected serialization. Semantic validity asks whether identity, epoch, units and mean-element theory are understood. Operational suitability asks whether the accepted record meets a named consumer’s freshness and quality policy. Passing one does not imply the next.

Objects representable in both the old and new formats

Define a synthetic fixture LEGACY-COMPAT-A with catalog ID 54321, an explicit epoch, mean elements and SGP4 parameters. Generate both its legacy TLE representation and its supported-format representation from the same canonical synthetic source. Do not copy a live object and relabel it synthetic. The expected propagation-result fields should remain “not run” until the test harness actually executes.

Compare in this order: canonical catalog identity; epoch after time parsing; each mean-element value after unit interpretation; SGP4 parameters; then propagated state using the same library and configuration. Fixed-width TLE rendering can quantize values, so tolerances must be derived from the source representation and reviewed by flight dynamics. Do not publish a universal position tolerance as if it were an SGP4 accuracy guarantee.

A useful acceptance record contains expected_identity=54321, per-field numeric tolerances, propagation epochs, pinned library/configuration, expected error code, and actual result fields. Until executed, those actual fields remain blank or explicitly NOT_RUN.

Six-digit objects with no legacy-format baseline

Define WIDE-ID-B with synthetic catalog ID 100123, explicitly noted as a test identifier not asserted to correspond to any live catalog object. Supply it only in a supported wider-ID format. Its primary acceptance test is exact identity preservation through parse, storage, serialization and joins.

Add negative variants: missing OBJECT_NAME where allowed, malformed EPOCH, nonnumeric catalog ID for a decimal-only contract, missing provenance, unknown fields, and a payload whose declared/observed format conflicts with the request. For CelesTrak JSON/CSV, test documented omitted metadata through the provider adapter; for a generic OMM source, do not reuse those CelesTrak defaults automatically. This fixture proves support for the new contract without inventing a TLE that never existed.

Reproduce the broken-cache migration scenario

Consider a fictional mission-support application called OrbitDesk. It has three defects: a database column catalog_id CHAR(5), a fixed-width TLE parser, and an HTTP cache keyed only by the downloaded filename. Every CelesTrak GP query ends in gp.php, so two distinct query URLs can map to the same basename. Skyfield’s documentation specifically warns that naïvely saving such URLs can overwrite one dataset with another and recommends choosing distinct local filenames.

The fixtures are synthetic. LEGACY-COMPAT-A uses ID 54321 and paired TLE/OMM representations. WIDE-ID-B uses ID 100123 and only a supported OMM-keyed representation. No live catalog position or customer incident is being claimed.

The first repair is not “change CHAR(5) to CHAR(6).” Six is merely today’s visible threshold. Choose a field width and contract that accommodates the provider’s documented one-to-nine-digit query space, then test nine digits even if the live operational set you consume is currently smaller.

The second repair is cache identity. A cache key should be derived from a normalized request identity, including provider, endpoint, query selector and explicit FORMAT; the stored batch should separately carry its content hash. Filename is presentation, not provenance.

The third repair is recovery. If WIDE-ID-B is truncated anywhere, quarantine that record and stop promotion of the batch to affected consumers. Continue serving the last known-good batch only if the consumer policy allows it, preserving its original element age and marking it stale when its age crosses the local threshold. Never “recover” by reverting the database to five digits and silently discarding the record.

Fetch responsibly and preserve the raw evidence

CelesTrak’s Usage Policy, published May 15, 2026 and updated May 22, 2026, says GP data is checked for updates every two hours and asks clients to download only the data they need, no more than once per update. For machine clients, non-200 responses are a stop-and-report condition rather than an invitation to retry rapidly. The policy specifically discusses 301, 403, 404 and server-error cases and the risk of repeated requests causing blocks.

Build the fetcher around evidence preservation. Set FORMAT explicitly. Select the smallest provider query that meets the consumer need. On HTTP 200, validate response structure before accepting it as the requested serialization. On any other status, stop that retrieval loop, retain the response evidence permitted by policy, and alert a human owner.

Use the content hash as a batch identity, not as a substitute for source metadata. Two identical payloads retrieved at different times can have the same hash but different retrieval evidence; conversely, semantically equivalent JSON and CSV naturally have different hashes.

The cache-identity checklist is short: no basename-only keys; no implicit response format; no overwrite of accepted raw evidence; no promotion before schema/semantic checks; no automatic retry storm on provider errors. For a CelesTrak cache, schedule around its documented update policy rather than polling each object independently.

Separate data freshness from successful download

HTTP success answers “did I receive bytes?” It does not answer “are these elements current enough for this consumer?” Skyfield’s satellite documentation makes the same operational distinction: downloading a TLE or OMM again can return data whose element epoch has not advanced, so software should inspect the element epoch rather than treating a fresh file as a fresh orbit.

Freshness therefore needs a consumer-owned threshold. Do not copy CelesTrak’s two-hour provider update cadence into a mission rule for maximum element age. Those are different quantities. The operations data authority and flight-dynamics owner should approve the allowable element age and any additional quality criteria for each downstream use.

Element epoch, retrieval time and pipeline completion

Store at least three timestamps with different meanings. element_epoch is part of the orbital record. retrieved_at records when the provider response was obtained. pipeline_completed_at records when your validated batch became available internally. A replay can have an old retrieval time and a new pipeline-completion time; that is expected and should be visible.

Never rewrite an old element epoch to the replay time or download time. That would convert a provenance event into false orbital freshness. If the system derives age_at_use, compute it from the actual element epoch under the agreed time-system interpretation, and keep the calculation rule versioned.

Blocked responses and quarantined records

CelesTrak’s Usage Policy instructs automated processes to stop when they encounter non-200 responses and report the problem to a human; repeated requests can worsen a block. Follow that boundary for CelesTrak rather than substituting a generic exponential-retry pattern.

Quarantine is for data problems: truncated identity, unresolved units/time/frame semantics, malformed required fields, missing provenance, or propagation-interface rejection. Retain the raw batch and reason code. Notify affected consumers that new data was not promoted. If last-known-good data remains available, preserve its original epoch and retrieval evidence and mark it stale according to the consumer rule. Recovery ends only when a newly validated batch passes the same gates; clearing an alert is not itself data acceptance.

Observe coverage and identity integrity after cutover

Cutover observability should answer three questions: did the provider response cover what we asked for, did we preserve every identity we received, and did downstream consumers join the same objects after the schema change? An increase in object count is not enough. It can coexist with duplicate keys, stale records or broken joins.

Keep object IDs out of unbounded metric labels. Emit counts and bounded dimensions such as provider, format, parser version and failure reason; put per-object detail in searchable logs or audit records. That gives operators enough evidence without creating a telemetry system that fails under catalog growth.

These are proposed operational signals, not measured industry thresholds. Establish baselines during shadow ingestion, then make alert thresholds local and reviewable. For automation ideas, satellite-operations automation is adjacent context; the control point here remains deterministic data-integrity evidence, not an anomaly model deciding whether orbit data is trustworthy.

A useful post-cutover dashboard separates provider status, ingestion status and consumer status. “Provider 200 / 12,000 records” can be green while “34 join misses” is red. Likewise, a parser can be green while element-age policy is red. Assign those states to different owners so a ground-system alert is not silently reinterpreted as a flight-dynamics acceptance.

Rehearse a rollback that does not lose new objects

Rollback should restore application behavior, not restore the old data limitation. Once the system has accepted wider catalog identifiers, shrinking the schema or switching to a reader that omits those rows is data loss. The safe pattern is a forward-compatible storage layer, immutable raw supported-format archives, and reader/adaptor versions that can be selected without discarding records.

Before cutover, run a recovery exercise in a staging copy that already contains the synthetic 100123 record. Roll back the application release, restore from backup, rebuild indexes and replay raw batches. The pass condition is not merely “service starts.” The six-digit record must remain intact, visible to the appropriate new-capability consumer, and quarantined rather than truncated if the rolled-back reader cannot process it.

Irreversible schema operations need a stop gate. Dropping the old column can wait until dual-path evidence is complete; shrinking the new column should never be part of rollback. If a database migration tool cannot represent the coexistence period safely, redesign the migration rather than accepting an untestable recovery path.

The stale-data policy also belongs in the rollback plan. Define who can authorize temporary use of last-known-good elements, for which consumers, and how age is displayed. A software rollback is not authority to reset the freshness clock.

Set the boundary between ingestion and flight decisions

The migrated feed has an authorized-use boundary. A parser owner can certify that bytes became a semantically valid canonical record. A flight-dynamics owner can certify that the propagation interface produces expected results under a pinned configuration. An operations authority decides whether that data source and freshness state are approved for a specific operational use. Those are separate approvals.

This article intentionally does not reproduce TraCSS operations and conjunction workflows. Conjunction screening, Collision Data Message triage, operator ephemerides and maneuver decisions are adjacent operational processes with their own provenance and authority. Public GP ingestion plus the lab described here is not independently sufficient authority for a spacecraft maneuver.

The stop condition is explicit: identity truncation, unresolved units/time/frame, malformed required fields or missing provenance blocks promotion. Propagation failure blocks the affected propagation consumer. A successful parse does not upgrade the authority of the source, and a successful SGP4 call does not approve a maneuver.

This separation also makes incident recovery cleaner. Data engineering can repair acquisition without rewriting flight rules; flight dynamics can reject a semantically suspect batch without diagnosing HTTP behavior; operations can choose a stale-data posture without pretending the record is fresh.

Build an orbit-data integrity portfolio

The most credible artifact from this migration is not a screenshot of a six-digit ID. Package the evidence an independent reviewer would need to reconstruct the change: schema diff, provider contract, fixture manifest, raw-payload provenance, differential comparison record, cache-key design, observability specification and rollback/replay exercise.

For readers building satellite mission-operations foundations, this is a useful portfolio because it demonstrates interface discipline, not just orbital vocabulary. Mark every synthetic fixture, every proposed threshold and every unexecuted result so the reviewer can distinguish design evidence from test evidence.

For structured study around the underlying disciplines, Refonte Learning’s Satellite Operations Specialist/Engineer Program lists orbit determination and control, ground-station operations, spacecraft health/data analysis, automation and operational simulations. It states three months at 10–12 hours per week, describes aerospace, electrical engineering or a related background as ideal, and requires working toward a bachelor’s or higher-level degree. The page does not verify this exact CelesTrak/OMM/SGP4 migration lab, so treat it as foundation-building rather than vendor-specific qualification.

Answer the remaining format-migration questions

Do all old TLEs stop working now that five-digit catalog numbers are exhausted?

No. CelesTrak states that legacy TLE/2LE/3LE delivery continues for objects whose catalog numbers fit the format. The operational failure is coverage of newly cataloged objects outside that representable range, plus software that assumes TLE is the only possible serialization. Keep legacy TLE fixtures for regression testing, but stop treating successful TLE parsing as proof that your feed covers the catalog you intend to consume.

Does Alpha-5 solve every provider case?

No. Alpha-5 is a parser/provider compatibility mechanism with its own representable range and syntax. The python-sgp4 library supports Alpha-5, but CelesTrak’s current notice says its 100000+ newly cataloged objects do not have GP data available in TLE format. A library feature cannot manufacture a provider response. Test Alpha-5 only where both the data source and the pinned parser explicitly support it.

Is CSV automatically more accurate than TLE?

No. Serialization and orbital accuracy are different concerns. CelesTrak’s JSON/CSV carry OMM-named GP fields and avoid the five-character catalog-number limit; GP data are still mean elements intended for SGP4-family propagation. A CSV migration can reduce identity and fixed-field limitations without changing the underlying orbit determination. Compare like-for-like source epochs and propagation configuration before attributing any numerical difference to format.

Does a fresh download mean the orbital elements are fresh?

No. Retrieval time and element epoch are separate. A provider can return HTTP 200 with an element set whose epoch is older than a consumer’s approved limit. Store element epoch, retrieval time and pipeline-completion time separately, then evaluate freshness from the element epoch. Skyfield’s documentation explicitly cautions that reloading does not guarantee a newer satellite epoch.

Why must rollback preserve wider IDs?

Because the identifier-width migration changes what your system can faithfully represent. Once a supported-format record with a six- or nine-digit catalog number has been accepted, reverting to a five-digit-only schema would turn rollback into silent data deletion or aliasing. Roll back code paths behind a forward-compatible data model, retain raw payloads, and quarantine unsupported reads instead of shrinking identity.

Use this final release checklist before calling the migration complete:

The next failing assumption to test is whichever component still treats catalog identity, serialization, freshness or operational authority as the same thing. In a controlled GP data pipeline, they are separate contracts, with separate owners and separate evidence.