Summary

  • RIPE NCC’s Q3 2026 RIS plan says the migration of RIS/RIPEstat data to rented bare metal is finished. In the same plan, data-processing monitoring and technical-debt cleanup, an investigation of storage alternatives to reduce HBase dependency, and Kafka hardware and version replacement are still in progress.
  • RIPEstat’s archived plan records additional latency between the service and backend systems during the migration. Its team looked at parallel queries and monitored the effect; the source does not quantify the latency or claim a service failure.
  • These statements can all be true because data movement, message transport, processing, storage, querying and publication are different control surfaces. “Finished” needs a boundary, not a rebuttal.
  • A privacy-safe migration receipt should bind each accepted component to its data range, software or infrastructure generation, cutover window, replay decision, known exceptions and observation period. It should test MRT files, RIS Live and RIPEstat separately rather than pretending one healthy surface proves the others.

One plan, several finish lines

The most important word in RIPE NCC’s Q3 2026 RIS plan may be the preposition after “finished.” The organisation says it has finished its migration of RIS/RIPEstat data to rented bare metal. It does not say that every surrounding system has completed renewal.

The rest of the paragraph makes the boundary visible. Monitoring of data processing is being improved. Technical debt is being cleaned up. Alternative storage architectures are under investigation to reduce dependency on HBase. That item remains in progress. The next item says Kafka machines are being replaced and Kafka is being upgraded to a new version after the work was postponed because of resource limitations. That too is in progress.

This is better disclosure than a single undifferentiated progress bar. Yet it leaves an evidentiary question for people who depend on the data: what exactly was accepted when the migration was declared finished?

The wrong answer is to treat continuing work as proof that RIPE NCC’s completion statement is false. Infrastructure programmes rarely end everywhere at once. Data may have crossed into a new store while transport hardware awaits replacement. A consumer path may need latency mitigation after the underlying dataset has moved. Monitoring often becomes more important after cutover, when the new system meets ordinary load and less predictable queries.

The equally wrong answer is to let the finished label spread. A completed data move is not automatically a signed statement about every collector, Kafka topic, processing job, query response or public file. Project language becomes reliable only when the object of completion stays attached to the evidence that accepted it.

RIS is a chain of observations, not a single box

RIPE NCC describes the Routing Information Service as a routing-data collection platform. Volunteer networks peer with globally distributed Remote Route Collectors, usually at Internet Exchanges. The collectors receive BGP updates and withdrawals. RIPE NCC stores and publishes the resulting data so operators and researchers can examine routing behaviour.

That simple description already contains different responsibilities. A volunteer controls what its BGP session presents. A collector records what it receives. Transport carries observations into processing. Storage retains generations of data. Jobs construct files and queryable views. Public services expose results under different timing and interface expectations. A researcher then makes a claim from a selected subset.

The chain is valuable precisely because it turns transient routing messages into evidence. But evidence loses force when its production generation is ambiguous. If a result straddles a cutover, the user needs to know whether the relevant interval came from the old store, the new store, a replay or a mixture. If one consumer experienced more latency, the question is not merely whether the backend stayed “up,” but which query path and data generation were being observed.

RIPEstat’s archived 2026 plan supplies a rare public glimpse of that consumer boundary. It says moving big data related to RIPEstat to rented bare metal led to additional latency between RIPEstat and backend systems. The team supported the migration, looked at methods to hide latency—including parallel queries—and carefully monitored the effect. The support item is marked completed in Q3 2026.

Nothing there establishes an outage, a breached objective or bad data. No percentile is given. “Looked at” does not prove one mitigation became universal. What it does establish is more useful: a migration can be complete at the data layer while its effect remains separately observable at the query layer.

Public outputs provide checks, not shortcuts

RIS offers several ways to encounter the data. Its MRT documentation says files are stored per route collector. Dumps, named bview, capture routing state at a point in time; update files record changes over an interval. The documentation says dumps are currently created every eight hours and updates every five minutes. These cadences make the public archive testable.

Testable is not the same as self-proving. Finding a file at the expected name says something about that collector and interval. It does not by itself establish that every expected update is present, that its contents derive from the intended generation, or that a separate consumer saw the same recency. The earlier BTW article about a generated but unpublished bview file owns that incident boundary. The present question is broader and non-incident-specific: what does a migration acceptance record test across outputs?

RIS Live is a different surface. RIPE NCC presents it as a near-real-time stream of BGP messages. A connected stream can be timely while a historical file is late; an MRT archive can be complete while a query service absorbs extra backend latency. The public sources reviewed here do not prove that all these surfaces share one route. A credible receipt therefore refuses to use any one of them as a proxy for the whole chain.

The archived RIS plans reinforce the point. RIPE NCC says it replaced the pipeline generating public MRT dump files in 2023, reducing delay and changing some file structure. In 2025 it reported resolving an inconsistency in which data from one removed IPv6 peer continued to appear in datasets, while planned public documentation of that and other artifacts was postponed. The inconsistency is described as resolved; the unfinished item was documentation. Both facts make generation and exception records more important, not because corruption is alleged now, but because data users need to know which history produced an observation.

What a component-bounded receipt would contain

A migration receipt should begin with scope. It should name the datasets, date ranges, collectors and consumer surfaces covered by the completed decision. “RIS data” is too broad if some generations, archives or query products were outside the cutover. The receipt can describe classes and ranges without publishing sensitive hostnames.

Next comes lineage. Which collector or ingest generation supplied the bounded interval? Which Kafka hardware and software generation applied, if Kafka was on that path? Which processing deployment transformed it, and which storage generation retained it? These fields should not imply that the separately announced Kafka replacement is part of every data route. Their purpose is to say when it is applicable and when it is not.

Then comes cutover. The record should distinguish extraction, initial ingestion, overlap, traffic switch, write freeze and decommissioning. The RIPE 88 engineering transcript is historical context, not a current RIS topology map, but it usefully shows those as separate decisions. A system can have copied data and built a new cluster before production switches; it can switch before retiring the old system. The receipt should not compress those moments into one date.

Acceptance needs bounded output tests. For selected RRCs and intervals on both sides of cutover, were the expected five-minute updates and eight-hour dumps present? Were counts and chosen routing outcomes within a stated tolerance? Was RIS Live recency examined separately? Which RIPEstat query classes were measured, and what latency distribution—not just an average—was observed before, during and after the switch?

Finally come replay, exceptions and time. If no backfill was needed, say so for the stated range. If replay occurred, record the range and result. List known artifacts and exclusions with their status. Name the owners who accepted storage, processing, query and publication checks. Give the post-cutover observation window. Acceptance is a dated judgement with a defined perimeter, not a promise that a future incident is impossible.

The receipt protects RIPE NCC’s completed claim

Transparency is sometimes framed as an invitation to dispute every operational decision. A bounded receipt does the opposite. It stops readers from demanding that one team prove components outside its completion claim, and it stops critics from converting an in-progress adjacent task into evidence of failure.

It also protects confidential operations. The public does not need internal addresses, credentials, staff identities or raw logs. Data ranges, build identifiers, component classes, aggregate latency, per-RRC checks, exception counts and decision timestamps are enough to make the boundary legible.

The sources do not show that RIPE NCC lacks such internal records. They show that the public status vocabulary is more granular than a headline but less granular than an acceptance chain. That gap matters because RIS is not merely an application. It is part of the evidentiary infrastructure through which researchers and operators reconstruct routing events.

The completed migration should therefore remain completed. The follow-up work should remain in progress. Kafka replacement should keep its own clock. HBase alternatives should remain an investigation until a choice is made. RIPEstat latency should remain a measured consumer effect rather than a claim of failure. The governance task is to join those honest states without flattening them.

Sources