Data export, switching provider and Service termination

Version: 1.0
Effective: upon publication of this version
Last updated: 21 August 2026
Stable URL: https://shipvise.com/en/legal/data-portability/

Translation notice: This English version is a machine-assisted translation provided for convenience. The original Czech version is the authoritative version. Where mandatory law requires otherwise, rights granted by mandatory law remain unaffected.

This document describes exit, portability and switching at Shipvise. It is designed with regard to Chapter VI of Regulation (EU) 2023/2854 (the Data Act) concerning switching between data processing services.

It forms part of the Shipvise contractual framework.

1. Basic principle: no vendor lock-in through data

The Customer must be able to leave Shipvise and take over the exportable data and digital assets needed to move to another provider or to their own operation.

Shipvise does not require the Customer to keep their source code in the Shipvise managed Git service.

2. Switching fee

Shipvise sets the switching fee at CZK 0.

This means that no separate switching charge or data-egress charge is levied for the standard export and provider-change process itself.

While the contract and the paid service continue to run, the standard charges for the plan ordered may remain payable. These ordinary service fees are not a switching fee.

Above-standard individual consultancy work that the Customer expressly orders beyond the standard switching process may be charged after prior agreement.

3. How exit can be initiated

Depending on the availability of the feature, the Customer may:

• start the export/switching in the Portal;
• request it via support@shipvise.com from the verified e-mail address of the Customer Account.

Shipvise will reasonably verify the identity and authorisation of the applicant. For sensitive exports, in particular secrets, stronger re-authentication than the mere existence of an e-mail message is required.

DKIM/DMARC or a match of the sending e-mail address may be a supporting security signal, but not the sole evidence of authorisation for a sensitive export.

4. Notice period

Shipvise does not apply a waiting period of its own before switching starts. Once the request has been verified, the process begins without undue delay.

The contractual maximum notice period for initiating switching is therefore, from the perspective of the standard Shipvise process, 0 days.

5. Transitional period

The standard process will be completed without undue delay and no later than within 30 calendar days of the start of the transitional period, where this is technically possible and the Customer provides the necessary cooperation.

During the transitional period:

• the contractual relationship continues to the extent necessary;
• the Provider gives appropriate assistance and relevant information;
• the Provider endeavours to maintain continuity of the functionality needed for the transition;
• the Provider maintains appropriate security of the exported data.

6. Technical impossibility of completing switching within 30 days

Where the standard 30-day maximum is technically infeasible, Shipvise will:

1. inform the Customer no later than within 14 working days of the switching request;
2. explain the specific technical reason;
3. state an alternative transitional period;
4. ensure that the alternative transitional period does not exceed 7 months.

Such an exception is to be used only in a duly justified case.

7. The Customer's right to one extension

The Customer may extend the transitional period once by a period they consider more suitable for their needs, to the extent required by the applicable Data Act regime.

During the extended period the contract remains in effect in the relevant respects and the standard price of the continuing service may remain payable. Shipvise does not charge a separate fee for the switching itself.

8. What the Customer can choose on termination

Depending on the situation, the Customer may choose in particular:

• to move to another data processing service provider;
• to move to their own/on-premises infrastructure;
• a mere export of data;
• deletion of exportable data and digital assets after the service ends.

Where direct switching to another provider requires that provider's identification or technical details, the Customer will supply them to Shipvise.

9. Exportable categories — managed source

Where the Customer uses the Shipvise managed source, the standard export includes, subject to technical availability:

• the complete Git history;
• branches;
• tags;
• tracked source files;
• the relevant Customer metadata of the repository.

The export is not to be limited to a ZIP of the current working tree where the Git history is part of the Customer's managed repository.

The preferred technical format for the complete source is a Git bundle or another mirror-compatible format that preserves history and references.

Git LFS is not part of the MVP until Shipvise expressly introduces support for it. If it is supported in the future, this page will be updated with the method of exporting LFS objects.

10. External Git

Where the Customer connects an external Git, for example their own repository at a supported provider, the external repository and its original data remain under the control of the Customer and of the external provider.

In that case Shipvise exports only the data and digital assets that it itself holds or has created in order to provide the service, for example configuration, deployment metadata, managed DB data and the other items listed below.

Shipvise is not obliged to re-export data it has never held and which remains directly available to the Customer at their own external provider.

11. Managed databases

Where a Project uses a managed database, the export includes a Customer database dump in a commonly usable format corresponding to the given database technology.

For PostgreSQL, a standard PostgreSQL-compatible dump/export is expected, depending on the technical implementation.

The export does not guarantee that the target provider will automatically perform a migration, adjust the schema or resolve application compatibility.

12. Project and runtime configuration

Subject to the available features, the export contains in particular:

• the list of Projects and Applications;
• environments and their Customer configuration;
• non-secret runtime configuration;
• Customer domain/routing metadata, where relevant and exportable;
• the relevant build/release/deployment metadata;
• the Project Context created by the Customer or directly relating to their Project;
• other Customer-created metadata needed to restore the functionality at another provider.

Commonly readable formats are used by preference, for example JSON, CSV, Git-native formats or a standard database dump depending on the type of data.

13. Review and Customer outputs

The export includes the results of Senior Review and of other ordered services intended for the Customer, where they are retained in Shipvise at the time of the export and are not a mere internal working note or a proprietary risk model.

14. OCI artifacts

Where Shipvise still retains a Customer OCI artifact created from their source and it is technically exportable, the Customer may be given the option to:

• download/export the artifact; or
• obtain a standard path for transferring/pulling it,

depending on the current registry implementation.

Shipvise need not regenerate an artifact that, under the ordinary retention, no longer exists.

15. Logs

The export may include available build/runtime logs relating to the Customer's Project to the extent that they still exist within the ordinary retention period.

These logs have a standard 14-day retention period. The Data Act does not create an obligation to recreate logs that have already been properly deleted.

16. Secrets

The ordinary Shipvise API does not return plaintext secret values.

For a complete exit/export, however, the Provider will offer — where the secret values are still technically available and the Customer is entitled to obtain them — a special mechanism with a higher level of verification that enables a secure one-time export of the secret values entered by the Customer.

Security rules:

• re-authentication or an equivalent strong verification is required;
• the export must be time-limited;
• a sensitive export must not be sent as plaintext in an ordinary e-mail;
• access to the export is recorded in the audit trail to the extent of the available feature;
• the Customer is warned that, after downloading, they are responsible for secure storage and for the recommended rotation of secrets.

Where a secret has previously been revoked or technically irrecoverably deleted, Shipvise cannot recreate it.

17. What the standard export does not include

The export need not include data specific to the internal functioning of Shipvise where its disclosure is not necessary for switching and could harm security or trade secrets, in particular:

• the source code and internal configuration of the Shipvise platform;
• the internal orchestration implementation;
• internal risk models, scoring, anti-abuse heuristics and security rules;
• internal administrative notes that are not a Customer output;
• credentials, secrets or data of Shipvise and of other Customers;
• third-party data to which the Customer has no right;
• internal security topology whose disclosure would create a risk.

Such an exception must not be used to effectively block switching or to delay it disproportionately.

18. Online register of formats

On this page or in the related documentation, Shipvise maintains a current register of the main export structures and formats.

MVP format register

The exact technical format may change, provided it remains commonly usable and the change does not make switching more difficult.

19. Generating the export archive

To protect performance and security, the Provider may:

• allow only one active export archive per Project;
• invalidate the previous archive when a new one is created;
• apply a proportionate rate limit on repeated generation;
• limit the validity of the download link;
• require re-authentication for a sensitive export.

Technical limits must not be misused to block porting without justification.

20. Retrieval period

After the agreed transitional period ends, Shipvise gives the Customer at least 30 calendar days to retrieve the available exportable data and digital assets.

During the retrieval period, Production/Preview need no longer be running where the operational service itself has been terminated and is not needed for switching, but the export path must remain available within the scope of the contract.

21. Deletion

After the retrieval period ends:

1. exportable data and Customer digital assets are removed from active/primary systems, unless there is a legal ground for further retention;
2. ordinary access to them is terminated;
3. any remaining technical copies in rotating backups are excluded from ordinary use and expire within the standard 7-day backup cycle.

Where the applicable Data Act regime requires a stricter moment of complete physical deletion, including from backups, the operational process will be adjusted before going live so as to comply with that requirement. In the contractual relationship, the mandatory Data Act requirement prevails over the technical backup cycle.

22. Voluntary earlier deletion

The Customer may request electronically that the protective retrieval period be shortened and that deletion take place earlier, where applicable law so permits.

Such a request must be strongly and appropriately verified, because it may be irreversible. A mere e-mail with valid DKIM is not sufficient as the sole factor for the irreversible deletion of a sensitive Project.

23. Customer cooperation

The Customer must provide the details and cooperation without which switching cannot be carried out, for example the target technical details where they request a direct transfer.

A delay caused by the Customer does not count as a breach of Shipvise's obligation, provided Shipvise otherwise gives the necessary assistance.

24. Limits of functional equivalence

Export and switching do not mean that the target infrastructure will have identical internal Shipvise features, or that Shipvise will rewrite the Customer's Application for another provider.

Shipvise provides the exportable data, digital assets and appropriate switching assistance; the Customer or the target provider is responsible for their own deployment and compatibility, unless a migration service is ordered individually.

25. Contact

Switching/export: support@shipvise.com
Privacy questions about personal data: privacy@shipvise.com

Request an export