Сайт працює, але підтримувати його має інша команда. У власника можуть бути робоча адреса, архів і кілька доступів без розуміння, чи цього вистачить. Не починайте з перенесення домену або обіцянки швидко виправити все: спочатку потрібен огляд вихідного стану.
Цей матеріал — про приймання вже наявного сайту новим виконавцем. Передача результатів нового замовлення та регулярна підтримка розібрані окремо. Зміна студії не означає автоматичного редизайну або перенесення хостингу.
Сформулюйте задачу й збережіть вихідний стан
Запишіть, чому змінюєте виконавця й чого очікуєте зараз: оновлювати матеріали, виправити конкретний збій, додати функцію чи спланувати перебудову. Відділіть наявні помилки від нових побажань. До проблеми додайте адресу, кроки відтворення та фактичний результат.
Зберіть важливі сценарії, які не можна втратити: звернення, запис, продаж або публікацію матеріалів — лише ті, які справді є на сайті. Зафіксуйте дату огляду й відомі обмеження. Це основа для порівняння після змін, а не підтвердження справності всього проєкту.
Зберіть карту матеріалів замість списку паролів
Для кожного пункту позначте стан: доступний, потребує перевірки або відсутній. Якщо чогось немає, так і запишіть; не видавайте приблизну відповідь за підтверджений факт.
| Частина | Що з’ясувати | Що ще може бути невідомим |
|---|---|---|
| Робочий сайт | Домен, платформа й поточна публічна версія | Звідки та як її публікують |
| Код або проєкт платформи | Репозиторій, експорт чи кабінет із потрібними правами | Чи відповідає комплект робочій версії |
| Залежності | Пошта, форми, оплата, запис та інші реальні сервіси | Хто ними керує й що зупиниться без них |
| Матеріали та копії | Контент, зображення, інструкції, резервні копії | Актуальність, повнота й умови використання |
Перевірте права до початку змін
Визначте, які акаунти контролює бізнес, хто може запросити нову команду та відновити доступ. Для першого огляду погодьте потрібні права; не передавайте всі облікові записи лише тому, що починається знайомство. Паролі та секрети не вставляйте в публічну форму чи загальний документ.
Окремі сервіси мають власні ролі. Наприклад, Search Console розрізняє власників і користувачів; доступ до файлів сайту не підтверджує потрібного доступу до його пошукових даних. Перевіряйте кожен сервіс окремо.
Для впорядкування акаунтів використайте карту домену, хостингу й пошти. Порядок завершення доступів попереднього виконавця погодьте разом із переходом, щоб не втратити керування до перевірки нової команди.
Попросіть перевірити, що комплект придатний до роботи
Нова студія має з’ясувати, чи можна запустити або відновити доступний комплект у погодженому тестовому середовищі, як публікується зміна та як повернути попередню версію. Окремо порівняйте його з робочим сайтом. Архів із давньою датою або успішна локальна збірка самі по собі цього не доводять.
Склад копії залежить від платформи. Наприклад, документація WordPress про резервування розділяє файли й базу даних: для типового відновлення потрібні обидві частини. Це приклад, а не припущення, що ваш сайт працює на WordPress.
Використовуйте безпечні тестові дані та погоджені доступи. Не переносіть реальні звернення в зайве середовище й не відновлюйте копію поверх робочого сайту заради демонстрації. Якщо перевірка неможлива без відсутнього матеріалу, залиште це відкритим питанням із відповідальним.
Уточніть обмеження й умови матеріалів
Попросіть перелік залежностей, які впливають на продовження роботи: підписки, модулі, прив’язки до акаунтів, особливі налаштування та недокументовані зміни. Для кожного важливого обмеження потрібен наслідок: що не можна перевірити або що доведеться погодити окремо.
Наявність коду не пояснює дозволені способи використання. GitHub описує роль ліцензії репозиторію; для конкретного проєкту зберіть відомі умови й погодьте спірні питання окремо. Не припускайте автоматичного права передати будь-який сторонній матеріал.
Навчальний приклад: архів сайту відкривається, але сповіщення форми залежать від акаунта попереднього виконавця. Команда записує цю залежність і потрібне рішення до оцінки змін. Це умовний сценарій, не кейс XEVOR і не привід одразу міняти всю платформу.
Погодьте огляд окремо від майбутніх доробок
Після початкової перевірки попросіть короткий висновок: що підтверджено, що не перевірено, які доступи відсутні та які задачі можна оцінити. Якщо потрібне додаткове дослідження, назвіть його результат і межі до початку. Не об’єднуйте невідомі старі проблеми з обіцянкою необмеженої підтримки.
- Поточна помилка: відтворення, очікувана поведінка та перевірка виправлення.
- Нова функція: окремий сценарій і залежності.
- Недоступний матеріал: хто його запитує та що він блокує.
- Подальший супровід: погоджені задачі й канал звернень.
Якщо огляд показав потребу в системних змінах, відділіть її за посібником про редизайн. Заміна виконавця й рішення перебудувати сайт — різні домовленості.
Зафіксуйте момент переходу й спосіб приймання
Погодьте, хто підтримує чинну версію до переходу, хто може публікувати зміни та хто ухвалює рішення при збої. Додайте порядок повернення й перелік дій після передачі. Саме знайомство з новою студією не є дозволом змінювати DNS або поштові налаштування.
- Дата огляду, версія та перевірені сценарії.
- Отримані матеріали й доступи з фактичними ролями.
- Відомі помилки, невідомі залежності та відповідальні.
- Перша погоджена задача, результат і спосіб перевірки.
- Порядок публікації, повернення та повідомлення про збій.
- Відповідальність до й після переходу та завершення старих доступів.
Першу зміну прийміть за погодженим сценарієм на кінцевому сайті. Реальну тестову заявку узгодьте з одержувачем і позначте як тест. Повідомлення на сторінці не замінює перевірки отримання.
Обговорити приймання сайту на підтримку · Надіслати адресу й опис задачі без секретів
Часті запитання про зміну студії
Чи достатньо пароля від адмінпанелі?
Не завжди. Потрібний комплект залежить від платформи, способу публікації та підключених сервісів. Перевірте його для конкретної задачі.
Чи треба одразу переносити хостинг?
Ні. Спочатку визначте потребу й залежності. Перенесення погоджують як окрему дію з перевірками та поверненням.
Що робити, якщо частини коду або доступів немає?
Зафіксуйте відсутність і те, які перевірки вона блокує. Погодьте отримання матеріалу або інший обсяг робіт, не припускаючи повної готовності.
Чи означає нова студія повний редизайн?
Ні. Початковий огляд має допомогти відокремити підтримку, локальне виправлення й системну перебудову.