Вихід із SaaS та міграція даних – що має регулювати договір?

Від Mallbutiken · Факти перевірено 1 жовтня 2026 р. · Приблизний час читання: 8 хвилин

Правильний вихід із SaaS-сервісу починається в момент підписання договору, а не тоді, коли вже надіслано повідомлення про розірвання. Договір повинен дозволяти залишити сервіс без перетворення даних, метаданих, інтеграцій або доступу до системи на інструмент тиску в переговорах. Тому з самого початку врегулюйте формати експорту, терміни експорту, підтримку міграції, витрати, доступ після розірвання договору та верифіковане видалення даних.

Чому умови виходу мають бути частиною первинного SaaS-договору

Коли хмарний сервіс починає використовуватися в повсякденній роботі, залежність від нього швидко зростає. Дані клієнта поєднуються з обліковими записами користувачів, правами доступу, історією, робочими процесами, інтеграціями, звітами та конфігураціями. Якщо питання експорту залишити відкритим, зміна постачальника може виявитися значно дорожчою та повільнішою, ніж очікувалося.

Тому вихід із сервісу слід розглядати як частину архітектури послуги та комерційних умов. Спочатку прочитайте SaaS-договори – 12 питань, які потрібно врегулювати для загального розуміння, а також посібник з SLA щодо доступності та рівнів обслуговування.

1. Визначте, які саме дані клієнт може експортувати

Фрази «клієнт володіє своїми даними» недостатньо, якщо їх неможливо отримати у придатному для використання вигляді. Уточніть, які категорії входять в експорт:

• основні реєстри та документи,
• історія та дані транзакцій,
• коментарі та вкладення,
• журнали аудиту або інша релевантна історія логів,
• інформація про користувачів та права доступу, де це доречно,
• конфігурації, таксономії та налаштовані поля,
• зв’язки між записами та інші залежності.

Також визначте, чи можна виконувати експорт регулярно протягом терміну дії договору, чи лише при розірванні. Регулярний експорт зменшує залежність від постачальника (vendor lock-in) та покращує готовність до переходу.

2. Формат, метадані та API – те, що визначає придатність експорту до використання

ZIP-файл із тисячами розрізнених документів технічно може бути експортом, але його буде важко мігрувати. Тому врегулюйте машинозчитуваний формат, кодування символів, формат дати, ключі/ID, зв’язки, метадані та документацію структури даних.

3. Визначте період виходу та подальший доступ

У договорі має бути зазначено, як довго сервіс буде доступним після розірвання і на яких умовах. Якщо доступ закривається в той же день, коли припиняється договір, клієнту може знадобитися виконати всю міграцію заздалегідь.

Тому визначте, наприклад:

• коли можна запитувати фінальний експорт,
• скільки часу є у постачальника на його надання,
• як довго зберігається доступ (тільки для читання або повний),
• чи можна повторити експорт у разі помилки,
• що станеться, якщо міграція затримається з вини постачальника.

4. Підтримка міграції та ціна

Формулювання на кшталт «постачальник надає розумну підтримку» можуть спричинити суперечки, коли настане час виходу. Визначте, яка допомога входить у вартість, а яка оплачується окремо. Це можуть бути роботи з експорту, технічні семінари, маппінг даних, підтримка API або виправлення помилок при верифікації.

Якщо підтримка оплачується додатково, договір має визначати принципи ціноутворення або погодинну ставку, можливо, цінову «стелю» та порядок замовлення послуг. Клієнт повинен мати можливість оцінити витрати на вихід ще до ухвалення рішення про зміну постачальника.

5. Видалення, резервні копії та GDPR

Коли SaaS-постачальник є обробником персональних даних, договір про обробку даних (DPA) повинен регулювати поводження з персональними даними після припинення завдання. Відповідно до ст. 28.3(g) GDPR, обробник повинен, на вибір контролера, видалити або повернути персональні дані та видалити існуючі копії, якщо закон не вимагає подальшого зберігання.

IMY також підкреслює, що видалення має бути безпечним. На практиці договір має регулювати:

• первинні дані,
• копії та кеш,
• резервні копії та нормальне виведення з циклу резервного копіювання,
• законодавчі вимоги, що можуть вимагати зберігання,
• сертифікат видалення або інше підтвердження, де це доречно.

Див. також посібник щодо договору про обробку персональних даних.

6. Контрольоване завершення прав доступу та інтеграцій

Вихід із сервісу також включає API-ключі, SSO-з’єднання, сервісні облікові записи, вебхуки та права адміністратора. Створіть перелік для деактивації, щоб ні постачальник, ні клієнт не залишили зайвих активних доступів після міграції.

Визначте, хто відповідає за відкликання ключів, експорт логів аудиту, закриття інтеграцій та верифікацію того, що старі підключення більше не працюють.

7. Тестування виходу до виникнення кризи

Умова про експорт має обмежену цінність, якщо ніхто не знає, чи працює він насправді. Для бізнес-критичних сервісів клієнт може періодично тестувати частковий експорт або проводити навчання з імітацією зміни постачальника.

Перевірте, чи можна прочитати формат файлів, чи зберігаються зв’язки та чи час експорту відповідає потребам бізнесу. Результати можна пов'язати з аналізом впливу на бізнес (BIA) та планом забезпечення безперервності роботи, якщо SaaS-сервіс є критичним.

Контрольний список для SaaS-виходу

• Які категорії даних можна буде експортувати?
• Чи визначені формат, метадані та зв’язки?
• Чи є API-експорт та задокументовані обмеження?
• Як швидко надається фінальний експорт?
• Як довго клієнт має доступ після розірвання договору?
• Чи включена підтримка міграції і скільки вона коштує?
• Чи може клієнт верифікувати повноту експорту?
• Коли видаляються продуктивні дані?
• Як поводяться з резервними копіями?
• Чи може постачальник надати підтвердження видалення?
• Як закриваються API-ключі, інтеграції та облікові записи?
• Чи тестувалася процедура виходу заздалегідь?

Регулюйте вихід при написанні SaaS-договору

SaaS-договір 2026 року від Mallbutiken містить окремий додаток для виходу, експорту даних та сертифіката видалення, а також SLA, безпеку та додатки, пов'язані з GDPR. Ціна в магазині: 149 крон.

Переглянути SaaS-договір