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:
- Redmine: the REST API is switched on from the first start of your instance, and Redmine's built-in CSV import works as usual.
- GitLab: the GitLab API and GitLab's own project import are available, and repositories go in with a plain
git push.
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:
- move to another provider,
- move to your own infrastructure,
- have your data erased.
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:
- help you, and the provider you are moving to, within reason;
- keep the service running as it ran before, at the same level of security;
- tell you about any risk to continuity that we know about.
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
- We do not move your data into the other provider's system for you. You download the package and restore it yourself, or the provider you are moving to does it for you.
- There is no automatic import into another tool. The package is a set of database dumps and archives, not a live migration.
Technical limits you should know about
- The dumps restore into matching versions of the software we run: Redmine 7.0.2 and PostgreSQL 17, and GitLab CE 19.4.2 for the GitLab part. Restoring them into a different version may take manual work.
- The host configuration in the package is written for our instance image. On other infrastructure you will have to adapt it.
- The package is a snapshot taken at the moment it was built. It is not a backup service and it does not keep updating.
- If part of your instance cannot be read while the package is being built, we build the package from the rest instead of failing. The
export-manifest.txtfile inside the archive always says what went in and what did not. While your server still exists, a missing part can still be collected - a later attempt may complete the package. If the package is still incomplete when your server is taken down at the end of the contract, we email you the list of what is missing. If none of your data can be read at all, no package is built; that is a fault on our side and we treat it as one.
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 holds | File in the package | Format |
|---|---|---|
| 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
- Your instance runs on a server rented from Hetzner Online GmbH, in one of its data centres in the European Union.
- This storefront - your account, your orders, and the database behind them - runs on the seller's own servers in Poland.
- Your data package is kept on the seller's servers in Poland.
- Email we send you, and our logs of this storefront, stay on those same servers in Poland.
- The service is sold and run by Daidala AI Konrad Makowski, a business registered in Poland - see section 1 of the Terms of Service.
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
- All the infrastructure we run the service on is in the European Union. The data on your instance leaves the EU only in the cases listed in section 10 of the Terms of Service. One of those cases happens every day, and it is the next point on this list. We do not move that data out of the EU in any other way.
- For your agents to work at all, Daidala sends what they are working on to the AI provider whose access you connected to your instance. That is the content of your instance that the work needs: issues, notes, wiki pages and whatever else the agent reads or writes while doing it. That content goes to the account you connected, including outside the European Union, if that is where the provider works. We send it to carry out your instructions. You choose the provider and the account, and connecting that access is your instruction to us to run your agents' work on it. That provider is your own, not one of the companies that handle your data for us. It handles what we send under your own agreement with it. The rest of the measures on this list, and what we do with a request from an authority outside the EU, protect the data we hold. They do not reach what is on that account. Sections 10 and 18 of the Terms of Service set this out.
- Hetzner Online GmbH hosts your instance, and it is the only company that holds the data on that instance for us. Hetzner is established in Germany, we are established in Poland, and neither of us is controlled by a parent company under the law of a country outside the EU.
- Three other suppliers outside the EU are part of how this service reaches you, and none of them can reach your data: Cloudflare runs our authoritative DNS with proxying switched off, so no traffic passes through it; Stripe handles card payments and has no access to your instance, your data package or this storefront; Let's Encrypt issues our TLS certificates, which is a matter of names, not of data.
- Access to the systems that hold your data is limited to one person, the owner of the business. There is no standing team with access to it. Changes to production go through the deployment pipeline and leave a record.
- The credentials to your instance are stored encrypted, not as plain text. The key used to reach your instance exists only in the process that needs it. Traffic to this storefront and to the store where data packages are kept is HTTPS-only. Email addresses, passwords and tokens are filtered out of our logs, which we keep for 30 days.
- If an authority of a country outside the EU asks us to hand over your data, we follow Article 32 of Regulation (EU) 2023/2854. We comply only under an international agreement in force between that country and the EU or a member state, or when the conditions of Article 32(3) are met. We hand over the smallest amount of data that answers the request. We tell you before we comply - unless the request serves law enforcement purposes, and then only for as long as keeping it confidential is necessary.
What it costs
- The service costs EUR 249 net per month. Whether tax is added on top depends on where your business is established and on the tax number you give us - see section 6 of the Terms of Service.
- Ending early costs nothing. We charge no penalty for ending the contract before you planned to. The service runs to the end of the month you have already paid for, and the fee for that month is not refunded.
- Switching to another provider costs nothing. Article 29(1) of Regulation (EU) 2023/2854 bans switching charges from 12 January 2027, and until that date Articles 29(2) and 29(3) allow reduced ones. We charge none - neither before that date nor after it.
- The transition period is billed at the normal monthly fee. That is a fee for the service you are still using, not a charge for switching.
- Getting your data out costs nothing. We charge nothing for building the package, for the export, or for the traffic it takes to download it.
Questions about any of this: support@daidala.tech.