Export dat, změna poskytovatele a ukončení služby

Verze: 1.0
Účinnost: dnem zveřejnění této verze
Naposledy aktualizováno: 20. 8. 2026
Stabilní URL: https://shipvise.com/cs/legal/data-portability/

Tento dokument popisuje exit, portabilitu a switching u Shipvise. Je navržen s ohledem na kapitolu VI nařízení (EU) 2023/2854 (Data Act) týkající se změny poskytovatele služeb zpracování dat.

Je součástí smluvního rámce Shipvise.

1. Základní zásada: žádný vendor lock-in prostřednictvím dat

Zákazník má mít možnost odejít ze Shipvise a převzít exportovatelná data a digitální aktiva, která jsou potřebná k přechodu k jinému poskytovateli nebo k vlastnímu provozu.

Shipvise nevyžaduje, aby zákazník svůj zdrojový kód ponechal v managed Git Shipvise.

2. Switching fee

Shipvise stanovuje switching fee na 0 Kč.

To znamená, že za samotný standardní proces exportu a změny poskytovatele neúčtuje zvláštní switching poplatek ani data-egress poplatek.

Během doby, kdy smlouva a placená služba nadále běží, mohou být nadále splatné standardní poplatky za objednaný tarif. Tyto běžné service fees nejsou switching fee.

Nadstandardní individuální konzultační práce, kterou zákazník výslovně objedná nad rámec standardního switching procesu, může být zpoplatněna po předchozím odsouhlasení.

3. Jak lze exit zahájit

Zákazník může podle dostupnosti funkce:

• zahájit export/switching v Portálu;
• požádat přes support@shipvise.com z ověřeného e-mailu zákaznického Účtu.

Shipvise přiměřeně ověří identitu a oprávnění žadatele. U citlivých exportů, zejména secrets, se vyžaduje silnější re-authentication než samotná existence e-mailové zprávy.

DKIM/DMARC nebo shoda odesílacího e-mailu mohou být pomocným bezpečnostním signálem, nikoli jediným důkazem oprávnění k citlivému exportu.

4. Notice period

Shipvise neuplatňuje vlastní čekací dobu pro zahájení switchingu. Po ověření žádosti začne proces bez zbytečného odkladu.

Smluvní maximální notice period pro zahájení switchingu je tedy z pohledu standardního procesu Shipvise 0 dní.

5. Transitional period

Standardní proces bude dokončen bez zbytečného odkladu a nejpozději v rámci 30 kalendářních dní od zahájení transitional period, pokud je to technicky možné a zákazník poskytuje nutnou součinnost.

Během transitional period:

• smluvní vztah v potřebném rozsahu pokračuje;
• Shipvise poskytuje přiměřenou součinnost a relevantní informace;
• usiluje o zachování kontinuity funkce, kterou potřebuje k přechodu;
• zachovává přiměřenou bezpečnost exportovaných dat.

6. Technická nemožnost dokončit switching do 30 dní

Pokud je standardní 30denní maximum technicky neproveditelné, Shipvise:

1. zákazníka informuje nejpozději do 14 pracovních dní od switching requestu;
2. vysvětlí konkrétní technický důvod;
3. uvede alternativní transitional period;
4. alternativní transitional period nepřesáhne 7 měsíců.

Taková výjimka má být používána pouze v řádně odůvodněném případě.

7. Právo zákazníka na jedno prodloužení

Zákazník může transitional period jednou prodloužit na dobu, kterou považuje za vhodnější pro své potřeby, v rozsahu požadovaném použitelným Data Act režimem.

Během prodlouženého období zůstává smlouva relevantním způsobem v účinnosti a standardní cena pokračující služby může zůstat splatná. Shipvise za samotný switching neúčtuje zvláštní fee.

8. Co může zákazník při ukončení zvolit

Zákazník může podle situace zvolit zejména:

• přechod k jinému poskytovateli služeb zpracování dat;
• přechod na vlastní/on-premises infrastrukturu;
• pouhý export dat;
• výmaz exportovatelných dat a digitálních aktiv po ukončení služby.

Pokud je pro přímý switching k jinému poskytovateli potřeba jeho identifikace nebo technické údaje, zákazník je Shipvise poskytne.

9. Exportovatelné kategorie — managed source

Pokud zákazník používá managed source Shipvise, standardní export zahrnuje podle technické dostupnosti:

• kompletní Git historii;
• branches;
• tags;
• tracked source files;
• relevantní zákaznická metadata repozitáře.

Export nemá být omezen pouze na ZIP aktuálního working tree, pokud je Git historie součástí zákaznického managed repozitáře.

Preferovaný technický formát pro kompletní source je Git bundle nebo jiný mirror-compatible formát, který zachovává historii a reference.

Git LFS není součástí MVP, dokud Shipvise výslovně nezavede jeho podporu. Pokud bude v budoucnu podporován, tato stránka bude aktualizována o způsob exportu LFS objektů.

10. Externí Git

Pokud zákazník připojí externí Git, například vlastní repository u podporovaného poskytovatele, externí repository a jeho originální data zůstávají pod kontrolou zákazníka a externího poskytovatele.

Shipvise v takovém případě exportuje pouze data a digitální aktiva, která samo drží nebo vytvořilo pro poskytování služby, například konfiguraci, deployment metadata, managed DB data a jiné položky uvedené níže.

Shipvise není povinno znovu exportovat data, která nikdy nedrželo a která jsou nadále přímo dostupná zákazníkovi u jeho vlastního externího poskytovatele.

11. Managed databáze

Pokud Projekt používá managed databázi, export zahrnuje zákaznický databázový dump v běžně použitelném formátu odpovídajícím dané databázové technologii.

U PostgreSQL se předpokládá standardní PostgreSQL-compatible dump/export podle technické implementace.

Export nezaručuje, že cílový poskytovatel automaticky provede migraci, upraví schéma nebo vyřeší aplikační kompatibilitu.

12. Projektová a runtime konfigurace

Export podle dostupných funkcí obsahuje zejména:

• seznam Projektů a Aplikací;
• prostředí a jejich zákaznickou konfiguraci;
• non-secret runtime konfiguraci;
• zákaznické domény/routing metadata, pokud jsou relevantní a exportovatelná;
• relevantní build/release/deployment metadata;
• Project Context vytvořený zákazníkem nebo přímo vztahující se k jeho Projektu;
• další zákazníkem vytvořená metadata potřebná k obnovení funkce u jiného poskytovatele.

Přednostně se používají běžně čitelné formáty, například JSON, CSV, Git-native formáty nebo standardní databázový dump podle typu dat.

13. Review a zákaznické výstupy

Export zahrnuje zákazníkovi určené výsledky Senior Review a dalších objednaných služeb, pokud jsou v době exportu v Shipvise uchovávány a nejsou pouhou interní pracovní poznámkou nebo proprietárním risk modelem.

14. OCI artefakty

Pokud Shipvise stále uchovává zákaznický OCI artefakt vytvořený z jeho source a je technicky exportovatelný, zákazník může získat možnost:

• artefakt stáhnout/exportovat; nebo
• získat standardní cestu k jeho přenosu/pullu,

podle aktuální implementace registry.

Shipvise nemusí regenerovat artefakt, který již podle běžné retence neexistuje.

15. Logy

Export může zahrnout dostupné build/runtime logy vztahující se k zákaznickému Projektu v rozsahu, v jakém ještě existují v běžné retenční době.

Standardní retence těchto logů je 14 dní. Data Act nevytváří povinnost znovu vytvořit již řádně smazané logy.

16. Secrets

Běžné API Shipvise nevrací plaintext secret values.

Pro kompletní exit/export však Shipvise nabídne, pokud jsou secret values stále technicky dostupné a zákazník má právo je získat, zvláštní mechanismus s vyšším stupněm ověření, který umožní bezpečný jednorázový export zákazníkem vložených secret values.

Bezpečnostní pravidla:

• vyžaduje se re-authentication nebo ekvivalentní silné ověření;
• export musí být časově omezený;
• citlivý export se nesmí poslat jako plaintext v běžném e-mailu;
• přístup k exportu se auditně zaznamená v rozsahu dostupné funkce;
• zákazník je upozorněn, že po stažení nese odpovědnost za bezpečné uložení a doporučenou rotaci secrets.

Pokud byl secret dříve revokován nebo technicky neobnovitelně odstraněn, Shipvise jej nemůže znovu vytvořit.

17. Co standardní export nezahrnuje

Do exportu není třeba zahrnout data specifická pro interní fungování Shipvise, pokud jejich zveřejnění není nutné pro switching a mohlo by poškodit bezpečnost nebo obchodní tajemství, zejména:

• zdrojový kód a interní konfiguraci platformy Shipvise;
• interní orchestration implementation;
• interní risk modely, scoring, anti-abuse heuristiky a bezpečnostní pravidla;
• interní administrační poznámky, které nejsou zákaznickým výstupem;
• credentials, secrets nebo data Shipvise a jiných zákazníků;
• data třetích osob, k nimž zákazník nemá právo;
• interní bezpečnostní topologii, jejíž zveřejnění by vytvářelo riziko.

Taková výjimka nesmí být použita k tomu, aby switching fakticky zablokovala nebo nepřiměřeně zdržovala.

18. Online registr formátů

Shipvise na této stránce nebo v navazující dokumentaci udržuje aktuální registr hlavních exportních struktur a formátů.

MVP registry formátů

Přesný technický formát se může změnit, pokud zůstane běžně použitelný a změna neztíží switching.

19. Generování exportního archivu

Pro ochranu výkonu a bezpečnosti může Shipvise:

• umožnit pouze jeden aktivní exportní archiv na Projekt;
• při vytvoření nového archivu předchozí zneplatnit;
• používat přiměřený rate limit na opakované generování;
• omezit platnost download linku;
• vyžádat znovu autentizaci u citlivého exportu.

Technické limity nesmí být zneužity k neodůvodněnému blokování portování.

20. Retrieval period

Po skončení dohodnuté transitional period poskytuje Shipvise zákazníkovi nejméně 30 kalendářních dní pro retrieval dostupných exportovatelných dat a digitálních aktiv.

Během retrieval period již nemusí běžet Production/Preview, pokud byla samotná provozní služba ukončena a není pro switching potřebná, ale exportní cesta musí zůstat dostupná v rozsahu smlouvy.

21. Výmaz

Po skončení retrieval period:

1. exportovatelná data a zákaznická digitální aktiva jsou odstraněna z aktivních/primárních systémů, pokud neexistuje právní důvod pro další uchování;
2. běžný přístup k nim je ukončen;
3. případné zbývající technické kopie v rotačních zálohách jsou vyloučeny z běžného používání a zanikají v rámci standardního 7denního backup cyklu.

Pokud použitelný Data Act režim vyžaduje přísnější okamžik úplného fyzického výmazu i ze záloh, bude provozní proces před ostrým spuštěním upraven tak, aby tomuto požadavku odpovídal. Ve smluvním vztahu má kogentní požadavek Data Act přednost před technickým backup cyklem.

22. Dobrovolný okamžitější výmaz

Zákazník může elektronicky požádat o zkrácení ochranné retrieval lhůty a dřívější výmaz, pokud to použitelné právo umožňuje.

Takový požadavek musí být silně a přiměřeně ověřen, protože může být nevratný. Pouhý e-mail s platným DKIM není dostatečný jako jediný faktor pro nevratný výmaz citlivého Projektu.

23. Součinnost zákazníka

Zákazník musí poskytnout údaje a součinnost, bez kterých switching nelze provést, například cílové technické údaje, pokud žádá přímý transfer.

Prodlení způsobené zákazníkem se nezapočítává jako porušení povinnosti Shipvise, pokud Shipvise jinak poskytuje potřebnou součinnost.

24. Omezení funkční ekvivalence

Export a switching neznamenají, že cílová infrastruktura bude mít identické interní funkce Shipvise nebo že Shipvise přepíše zákaznickou Aplikaci pro jiného poskytovatele.

Shipvise poskytne exportovatelná data, digitální aktiva a přiměřenou switching součinnost; zákazník nebo cílový poskytovatel odpovídá za vlastní deployment a kompatibilitu, není-li individuálně objednána migrační služba.

25. Kontakt

Switching/export: support@shipvise.com
Privacy otázky k osobním údajům: privacy@shipvise.com

Požádat o export