Switching to another provider

Last updated: 13 October 2026.

This page explains how to bring your data into Daidala, how to move your instance to another provider or to your own infrastructure, what we hand over and in what format, where your data is kept and whose law applies to it, and what all of this costs. Anyone can read it - you do not need an account.

The contract itself is our Terms of Service. This page is information, not part of the contract, and we keep it up to date.

How switching works

Coming to Daidala from another system

Your instance starts empty. We do not import data from your old system for you, and there is no import wizard. What you get on day one is administrator access to both applications on your instance - Redmine and GitLab™ - and you bring your data in yourself:

The one thing we cannot do is load a database dump from another installation into your instance. The database belongs to the Redmine version we run and to our plugin, and we manage it for you. If you are moving off an existing Redmine, ask us at support@daidala.tech before you buy and we will tell you what can and cannot be carried over.

Leaving

You can leave at any time. Turn off renewal in your account, or write to support@daidala.tech. The contract ends at the end of the month you have paid for, so you never wait more than a month to leave. There is no other notice period.

Tell us which of these three you want:

The transition period

If you ask for it, we keep your service running for up to 30 days after the day your contract would have ended. During that time the contract stays in force and we:

You can extend this period once, for as long as you need it. You pay the normal monthly fee for it - see What it costs.

Getting your data out

While your service is running, you can ask for a data package from your account, on the Your data page. We pack it within minutes, it holds the same things as the package you get when the contract ends, and it stays there for 7 days. You can do this as often as you need, including during the transition period. We charge nothing for it.

When your service ends, we build the package automatically. You download it from your account. It stays there for at least 30 days, counted from the end of the transition period - or from the end of the contract, if you did not ask for a transition period. If your data package only reaches your account later than that, those days are counted from the day it is there. Your account always shows the last day you can download it. After that day we erase it for good.

What is in the package, and in what format, is listed in the register below.

Other ways to get your data out

You do not have to wait for a package. Throughout the contract you have administrator access to your instance, and the applications on it have their own interfaces: the Redmine REST API, the GitLab API, and git clone for repositories. You, or the provider you are moving to, can read your data through them at any time. We charge nothing for this.

Both interfaces are documented by the projects that build them, and the documentation applies to your instance as it stands: Redmine REST API and GitLab REST API. The versions you are working against are Redmine 7.0.2 and GitLab CE 19.4.2.

What we do not do

Technical limits you should know about

What we hand over, and in what format

This is our register of the data structures and formats in which we hand over your data. We keep it up to date, as Article 26(b) of Regulation (EU) 2023/2854 requires.

The whole package is one gzip-compressed tar archive, downloaded as daidala-<your service number>-<date and time in UTC>.tar.gz. Inside it:

What it holdsFile in the packageFormat
Your Redmine database - issues, projects, users, comments, settings redmine-database.sql plain-text SQL dump made with pg_dump (PostgreSQL 17, Redmine 7.0.2 schema)
The Daidala state database - the data Daidala itself keeps about your instance daidala-database.sql plain-text SQL dump made with pg_dump (PostgreSQL 17); some columns in it are stored encrypted - the keys that open them are in the same package, in the row below
The keys that unlock the encrypted parts of the Daidala state database - without them the columns holding your AI subscription tokens, your agents' access tokens and your projects' pull secrets cannot be read encryption-keys/daidala_provider_oauth_pool_key, encryption-keys/daidala_codex_oauth_pool_key plain text - one key per file, 64 hexadecimal characters, no line break at the end
Files uploaded to Redmine - attachments redmine-attachments.tar tar archive of the files, in their original formats
Host configuration of your instance - how and where it is deployed. The access details to your instance are not in it etc-dedal-daidala/ directory of plain-text configuration files
A list of what is in this package export-manifest.txt plain text - what went in, and what did not
Your GitLab data - repositories, wikis, and everything GitLab keeps with them gitlab-data.tar tar archive holding: repositories/<path>.bundle - one git bundle per repository and per wiki, opened with git clone; database.sql - plain-text pg_dump dump of the GitLab database (projects, issues, merge requests, users, CI configuration); uploads/ and shared/ - attachments, LFS objects, CI artifacts and Pages, in their original formats; README.txt and index.txt - what is in the archive and how to restore it

The same list, and the only categories we are allowed to hold back, are part of the contract - see the switching section of the Terms of Service.

We hold back none of your data. Article 25(2)(f) of the same regulation lets a provider hold back data about the internal workings of its own service where handing it over would risk revealing a trade secret. Nothing in your package is held back on that ground.

Standards and open interoperability specifications. As at the date at the top of this page, no standard and no open interoperability specification for this type of service has been published in the EU central repository referred to in Article 30(3). We therefore hand over data in structured, commonly used, machine-readable formats, as Article 30(5) requires: SQL dumps, tar archives, git bundles and plain text files, all readable with standard tools.

Where your data is, and whose law applies

So the infrastructure your data sits on is under EU law, and each part of it is also under the law of the EU country it stands in - Polish law for this storefront, your data package, our email and our logs. No part of that infrastructure is under the jurisdiction of a country outside the EU. Content from your instance also goes outside that infrastructure - the next part of this section says where.

How we protect non-personal data against access by authorities outside the EU

What it costs

Questions about any of this: support@daidala.tech.