Updated migration script

For a long while we had a script to migrate content between Redash instances. It worked, but wasn’t very much maintained. About a year ago @jesse started the effort of refreshing this script as part of the redash-toolbelt project, it didn’t go far but we’re restarting the effort now.

The goal is to create a maintained version of the script built on top of the toolbelt that will support latest version of Redash along with all the objects (previous versions of the script didn’t migrate alerts or favorites).

The PR is here: Add migration script to examples by susodapop · Pull Request #23 · getredash/redash-toolbelt · GitHub.

If anyone interested in helping with testing, please let us know. We will update on this thread with the progress of this effort.


Do we have an ETA on when the migration script will be usable?

Late July or early August. You can follow along on the PR Arik linked.

in which database I have to store my dashboards which is available in your database after migrating

Redash uses Postgres.

ok after migrating where will my dashboards which are in your database will be stored, which database I have to use those dashboards which you have stored ,do I have to use Postgres ,and how do I have to store that can you tell me the steps

can you tell me the dashboards which are stored in your Postgres then how will I have to migrate those dashboards in my Postgres account.

All this will be handled by the migration script.

hi how to take backup of the data

Hey everyone, last call for feedback on the migration script before it’s deployed out to Pypi:

1 Like

Hi there all.

We are planning the work required to migrate to our own hosted Redash in Q4.

Is there a guide on how to do it end to end?

1 Like

Once OSS V10 and the migration script are released we’ll make docs for this :slight_smile:

1 Like

Ok great. Just raising that this leaves about 2 months to migrate, and for larger companies who have trusted hosted redash and paid them, this does not leave a lot of time to do the migration.

Is there an ETA on this?

1 Like

Agreed that this doesn’t leave a lot of time to do the migration and test/validate everything.

We will need some contingency time for issues or implementing alternative solutions if it doesn’t work as expected, so we ideally would want to be running the migration script around now.

Is there any talk of offering an extension for those that wish to move to self hosted?

The V10 release is now pending (just waiting for our images to build). The migration script will be published next week. The 30 November deadline is firm. Migration, even for large accounts, should require only a few minutes. We’ve tested the migration script on our internal instance (many thousands of queries and dashboards and alerts) and it takes around 6 six minutes. Most instances will be much quicker than that.

1 Like

Just a quick question:

will the migration script also be able to export current users, or shall they re-create a new account?


Will the IDs of queries, widgets, visualizations, and dashboard slugs change after migration? Does the migration script cope with the following:

  1. queries to the source ‘Query Results’ where we use Redash’s own query ids inside the query like ‘select … from cached_query_xxx’;
  2. query based dropdowns?

Will there be available the matching of the old and the new query ids after the migration? (for user information purposes)?

Just wondering whats the ETA on the script?

This week :crossed_fingers:

Also, we as a community, need a better way to communicate upcoming timelines. I think it’s frustrating for everyone.

This is possible since meta.json contains a map of $originQueryId to $destinationQueryId. It will not be part of the release this week. But we will aim to add it within the next few weeks (or would merge a contribution that implements it sooner).

[Edit] I added an issue to redash-toolbelt to track this: Migration Script: convert origin QRDS queries to destination · Issue #64 · getredash/redash-toolbelt · GitHub