What happens to a satellite-data archive when the service changes?

A satellite dataset can remain safely stored while becoming difficult for a customer to use. The download address may change, a familiar identifier may resolve to a different processing version or documentation needed to interpret an old product may disappear from the new interface. Archive continuity is therefore a broader question than whether the files still exist.

For a company building a recurring data product, historical access can support comparisons, explain earlier findings and reduce dependence on the people who originally built the workflow. A supplier transition should preserve those uses deliberately. The customer needs to understand what changes, what remains accessible and what evidence will show that its important workflows still work.

Storage and usable preservation are different commitments

The December 2024 OAIS reference model describes long-term preservation in terms of information remaining independently understandable to a defined user community, with supporting evidence of authenticity. Its treatment of representation information addresses the explanatory material needed to understand stored objects. These are preservation concepts, rather than a certification that a particular commercial archive satisfies them.

The practical implication is straightforward. A customer may need product definitions, quality information, processing history and a way to interpret the stored values alongside the data itself. The exact package depends on what the customer is expected to do with the archive. Preserving an image for visual reference is a different commitment from preserving enough context to reproduce an analytical result.

The supplier should describe that commitment in terms of supported uses. A phrase such as permanent archive access leaves unresolved which products, versions, interfaces and supporting material are included. The customer should turn it into a concrete account of what it expects to retrieve and understand during the contract and after the active service changes.

An access migration can affect customers differently

A 3 June 2025 LP DAAC announcement provides a useful historical example. It announced retirement of legacy Data Pool access for MODIS datasets on 30 June 2025. The notice said Earthdata Search users would see no workflow change, while users of the legacy archive, including scripts, needed to update their access workflow for Earthdata Cloud. The same migration therefore had different consequences depending on how a customer obtained its data.

That example does not establish the present condition of every NASA endpoint. It shows why a supplier's claim that the data remains available can be accurate while a particular customer's process still requires work. The commercial review should identify the access route actually used by each important workflow.

A company may have one team downloading data manually and another running a scheduled application. A successful manual download from the new portal does not prove the application has migrated. The customer should retain those as separate acceptance cases, with an owner for each.

Inventory the dependency before the notice arrives

An archive dependency has several parts: the collection and version used, identifiers retained in customer records, access method, essential metadata and the software that interprets the result. The company should be able to identify these parts without reconstructing them during an urgent migration.

The inventory need not cover every file the business ever downloaded. Start with workflows that support a current customer product or an important historical claim. For each, identify what would be lost if the existing access route stopped working and which material is already held in the company's own approved storage.

This also reveals hidden human dependencies. If only one analyst knows how an old product's flags should be interpreted, the archive is less reusable than its size suggests. A transition is an opportunity to preserve the explanation with the relevant version, making it accessible to the next person responsible for the product.

BDI's guide to derived-data lineage explains how a result can retain its connection to source objects and processing steps. An archive handover should preserve those connections rather than leaving the downstream product with references that no longer identify retrievable evidence.

Separate migration from reprocessing

Moving a file to a new access service is different from regenerating the product with a revised algorithm. Both can be useful changes, but they have different consequences for a customer comparing historical results. A new location should not silently imply a new scientific or analytical version.

Consider an illustrative environmental-reporting company that repeats a past analysis after an archive move. It obtains data covering the same period, but the collection has been reprocessed and some values differ. The customer needs to know whether the difference comes from new underlying observations, revised processing or a mistake in its migration.

The supplier should explain whether earlier versions remain accessible, whether identifiers are preserved and how superseded products are marked. If an old version is withdrawn, the notice should describe the effect on reproducibility and identify the available replacement. Providing only the newest data can be a sensible service policy, but it is a different commitment from preserving every historic result.

The customer's own product may then require a version decision. It can retain the original published analysis with its documented basis, issue a revised analysis or explain that comparisons now use a changed source product. The right choice depends on the business purpose; the archive should supply enough information to make the choice explicit.

Check the package at the new destination

A migration review should follow a representative historical use case. Locate the intended collection and version, obtain the required data and supporting information, and confirm that a person unfamiliar with the migration can understand the package. A successful transfer of bytes is only one part of that review.

Include a case that depends on metadata or a quality flag, not only an easy-to-view image. If the business needs a subset of a larger collection, verify that the subset retains the context needed to identify its origin. If it needs a historical version, confirm that the access route actually returns that version rather than a default latest product.

Integrity checks help establish that an intended object survived a move unchanged. They do not establish that the right object was selected or that its meaning has been preserved. The acceptance record should therefore combine identity, integrity and interpretability instead of using one as a substitute for the others.

The ground-service handover guide addresses a related boundary for newly delivered data. Archive migration adds a historical obligation: the recipient must be able to relate the transferred material to the product it previously used.

Make access conditions and costs explicit

A new archive service may change the practical cost of retrieving or processing data even if the dataset itself has no purchase price. A commercial supplier should explain any relevant storage, retrieval or service charges in its offer. The customer should compare the cost of its own expected workflow, including occasional historical retrieval, rather than only a typical new-data download.

Access rights also need continuity. The ability to discover an archived object does not necessarily establish permission to download, retain or redistribute it. Preserve the applicable terms with the customer record, and identify any change that affects the business's planned use. A public archive example should not be treated as evidence that commercial datasets have identical conditions.

The transition notice should name an effective date, affected collections and interfaces, required customer action and support route. After the migration, retain that notice with the acceptance record. It explains why access changed and what the customer verified at the time.

A strong archive commitment ultimately preserves a usable relationship between the data, its identity, its meaning and the customer's rights to use it. Evaluating those parts together lets a company change infrastructure without losing the ability to explain its past products or build confidently on the evidence they contain.