How to Migrate InfluxDB 1.x/2.x to 3.0 Without Losing Your History: Introducing Historian

When I worked at InfluxData, one of the most common requests from customers was: “What about cold storage for queries?” The answer back then was simple: “We don’t have that yet. If you need it, you’ll have to build your own solution and push data into BigQuery or something similar.”

Two years after leaving the company, I decided to solve that problem myself. Many customers on InfluxDB 1.x or 2.x aren’t ready to move to 3.0, but they still need a way to extend retention and reduce cluster pressure. That’s why I built Historian.

Historian lets you export older data from InfluxDB into Parquet files, stored in systems like S3, MinIO, or Google Cloud Storage. From there, you can still query it. thanks to an integration with DuckDB, without keeping everything inside Influx.

The goal is to take pressure off InfluxDB instances (memory and disk I/O) while still keeping historical data available. For example, data you rarely query, or that you want to use for machine learning training or BI workloads, can be moved out of Influx without sacrificing access.

Today, Historian is already helping several enterprise customers and large OSS users I consult for. It’s reducing costs, extending retention, and making migrations smoother, exactly the pain point I used to hear about when I was inside InfluxData.

Now, here’s the interesting part: InfluxData released InfluxDB 3.0, which natively works with Parquet files and supports tiered storage. That got me thinking, why not extend Historian to also act as a migration bridge from InfluxDB 1.x and 2.x into 3.0?

That’s exactly what I’ve built, and what I want to show you today in this blog post.

Arquitecture of Historian

Before moving on to the migration process, let me show you the typical architecture of Historian.

At a high level, you connect your data sources, InfluxDB OSS, Enterprise, or even Cloud, and export that data into Historian. Historian then saves and compresses it into Parquet files, giving you two big wins right away:

1. The data is compressed, reducing storage footprint.
2. It can be stored in low-cost cold storage solutions like Amazon S3, Google Cloud Storage, or MinIO.

That means you save instantly on storage allocation and long-term costs.

Historian also includes a UI component that lets you configure exports, but it goes further: with the integration of DuckDB, you can query Parquet files directly. Performance is excellent, even on large datasets, making it practical for BI workloads, analytics, or machine learning pipelines without stressing your InfluxDB cluster.

Finally, and this is the part I’m most excited about, Historian can now take the data stored in Parquet and re-import it into InfluxDB 3.0. This makes it not just a cold-tier storage solution, but also a migration tool, helping users move cleanly from older versions of InfluxDB into the brand-new 3.0.

Moving Data

Moving data from InfluxDB 1.x or 2.x (Enterprise or OSS) with Historian is straightforward. The screenshot below shows the main configuration points:

• Data Source Connections – This is your InfluxDB source, where Historian will read data from. You can configure multiple instances here and simply activate the one you want to use for a specific job.
• Storage Connections – This is where the exported data is saved. In this example, I’m using MinIO with a bucket named historian and database exported. You could just as easily use S3 or Google Cloud Storage.
• Destination Connections – These are only needed when running migration jobs. If you only want tiered storage, Historian itself is your “destination.” But if you’re migrating to InfluxDB 3.0, this is where you configure your 3.0 instance: specify host, organization, database, source storage, batch size, and timeout.

This simple connection setup makes it easy to export data out of 1.x/2.x and move it either into low-cost Parquet storage or directly into InfluxDB 3.0.

The Magic: Running Jobs

Once your connections are configured, the next step is to schedule an export job. In this case, we’re taking data out of InfluxDB and saving it into MinIO.

In the Schedules section you define:

• Which data to export (entire database or specific measurements).
• Chunk duration and buffer.
• Retries and chunk size.

Once the job is started, you can follow progress in the Monitoring section, where you’ll see how the export is performing in real time.

When the export finishes, Historian can continue to ingest data programmatically, so you can keep your cold tier updated automatically.

From there, you can also configure a Migration Job. This is where you set the number of workers and batch size. These parameters matter a lot:

• If you have a huge dataset, larger batch sizes will move data faster.
• But if your InfluxDB 3.0 target is already in production, you need to be careful not to overload it.

As with most things in data engineering, you’ll find yourself tuning these settings depending on dataset size and required speed.

When the migration process finishes, you’ll see it marked as 100% complete in Monitoring. At that point, you can run a query in InfluxDB 3.0 and validate that the data counts match what you had in Historian.

Here is an example:

influxdb3 query --database exported --token "your-token" "SELECT MIN(time), MAX(time), COUNT(*) FROM cpu"
+---------------------+---------------------+----------+
| min(cpu.time)       | max(cpu.time)       | count(*) |
+---------------------+---------------------+----------+
| 2025-07-01T00:00:00 | 2025-09-10T02:00:00 | 4012581  |
+---------------------+---------------------+----------+

Ok, I Love It, What’s the Next Step?

At this point you might be wondering how to try Historian yourself. A couple of important notes:

• Historian is not a free or open-source tool. It’s a paid solution designed primarily for on-prem deployments where enterprises need control over their data and infrastructure.
• That said, I’m preparing a hosted version with limits on storage and data throughput. This will let interested users test Historian in a self-service way, explore the workflows, and see the value before deploying it on-prem.

So if you’re curious, the next step is simple: reach out through Basekick website, and I’ll share details on how you can test Historian or discuss on-prem licensing for your environment.