--- title: "Въпроси към партньор за миграция към облака преди договор" description: "Какво да попитате партньор за миграция към облака: инвентаризация, стратегия по приложения, landing zone и сигурност, превключване, връщане, разходи, предаване." canonical: https://sdk.enterprises/bg/insights/questions-before-hiring-a-cloud-migration-partner language: bg --- # Въпроси към партньор за миграция към облака преди договор Обновено: 2026-09-26 > Преди да подпишете с партньор за миграция към облака, попитайте как ще инвентаризира това, което използвате, как ще избере стратегия за миграция за всяко приложение, как ще проектира и защити целевата среда, как ще връща назад всяко превключване, как ще Ви показва разходите и как ще подготви екипа Ви да поддържа резултата. Конкретните писмени отговори Ви казват повече за предстоящата миграция, отколкото дневната ставка. ## Попитайте как ще разберат какво всъщност използвате Планът за миграция е толкова добър, колкото е инвентаризацията зад него. Попитайте партньора как ще я изготви: от интервюта с отговорниците за приложенията, от данни за инфраструктурата като метрики на сървърите и мрежови връзки, от самия код или от трите източника. Съществуващата документация е отправна точка, а не доказателство, защото тя се отдалечава от това, което реално работи. Попитайте какво ще съдържа инвентаризацията и чия ще бъде след това. Добрият отговор назовава полетата и потвърждава, че инвентаризацията остава при Вас, каквото и да решите след това. - Всяко приложение, неговият бизнес отговорник и доколко е критично - Среди за изпълнение, рамки и операционни системи, като се отбелязва всичко с изтекла поддръжка - Бази данни, споделени файлови ресурси, планирани задачи и опашки, от които зависи всяко приложение - Интеграциите в двете посоки, включително тези, които никой не е документирал - Лицензи, обвързани с хардуера или с броя процесори, които може да не се пренесат в облака - Приемливото време на прекъсване и бизнес календарът: края на месеца, пиковия сезон, регулаторните срокове ## Очаквайте стратегия за всяко приложение, а не една за целия парк Приложенията преминават към облака по различни начини. Обичайните варианти са да преместите приложението както е (lift and shift), да го пренесете на нова платформа с малки промени, например управлявана база данни, да го преработите, за да използва облачни услуги, да го замените със SaaS продукт, да го оставите засега там, където е, или да го изведете от употреба. Партньор, който предлага един подход за всичко, не се е вгледал достатъчно. Поискайте критериите, по които избира, и поискайте да ги видите приложени към три или четири от Вашите приложения, преди да подпишете. Разсъжденията му за реалните Ви системи казват повече от слайд с методология. Попитайте по-специално как подхожда към приложения в среди за изпълнение с изтекла поддръжка, защото преместването им без промени пренася старите рискове на новата платформа. ## Разберете кой проектира и защитава landing zone Landing zone е подготвената целева среда: структура на акаунтите, самоличност и достъп, мрежа, дневници, криптиране и предпазните правила, които всяко приложение наследява. Грешка тук се повтаря във всяко приложение, което се премести в нея. Попитайте кой я проектира, дали е описана като код, например с Terraform, и дали Вашият екип по сигурност я преглежда, преди да се премести първото приложение. Сигурността в облака е споделена. Доставчикът защитава основната инфраструктура, а Вие оставате отговорни за това как я конфигурирате и използвате. Попитайте партньора кои механизми за контрол ще настрои, кои остават за Вашия екип и как достъпът на собствените му инженери се предоставя, записва и премахва накрая. - Отделни акаунти или проекти за всяка среда, с изолирана продукционна среда - Единен вход (SSO) с именувани потребители и роли с минимални права, без споделени администраторски идентификационни данни - Централизирани дневници и одитни следи, които инженерите по проекта не могат да изключат - Криптиране на съхраняваните и предаваните данни по подразбиране, с тайни, държани извън кода - Региони, избрани така, че да отговарят на задълженията Ви за местоположение на данните и по GDPR ## Накарайте ги да Ви покажат стъпка по стъпка едно превключване и едно връщане Превключването е моментът, в който трафикът и данните преминават към новата среда, и там миграцията е най-видима за бизнеса. Помолете партньора да разгледа стъпка по стъпка превключването на едно от Вашите приложения: как се синхронизират данните, как се превключва трафикът, какви проверки се изпълняват след това и кой решава, че е успешно. След това попитайте как биха се върнали назад. Надеждният план назовава условията, които задействат връщането, човека, който взема решението, и колко дълго старата среда остава на разположение. Ако след превключването потребителите са записвали данни в новата среда, попитайте как тези данни се връщат в старата. Слабите планове пропускат този въпрос. Нашата статия за миграцията на стотици стари приложения към AWS показва как тези стъпки се превръщат в ръководства за експлоатация (runbooks) за голям парк от приложения. ## Настоявайте да видите разходите, преди да пристигне първата сметка Разходите в облака се държат различно от тези в център за данни. Плащате за това, което работи, включително тестови среди, които никой не е изключил, хранилище, което продължава да расте, и данни, прехвърлени извън мрежата на доставчика. Поискайте оценка на разходите за всяко приложение с писмено изложени допускания и попитайте как партньорът ще я сравнява с реалното използване през първите месеци. Прозрачността на разходите е проектно решение, а не месечен отчет. Поискайте правила за етикетиране (tagging), които свързват всеки ресурс с приложение и отговорник, бюджети и известия от първия ден и преглед на размерите на инстанциите, след като приложенията са работили при реално натоварване. Оразмеряването на облачните сървъри по стария хардуер е сигурен начин да плащате за капацитет, който никой не използва. ## Предупредителни знаци, че предложението за миграция не е готово Всеки от тях поотделно може да има обяснение. Няколко в едно и също предложение обикновено означават, че рискът е оставен на Вас да го откриете. - Фиксиран график, преди някой да е видял инвентаризацията Ви - Една стратегия за миграция, приложена към всяко приложение - Липса на писмен план за връщане или връщане, което зависи от възстановяване от резервни копия под напрежение - Облачни акаунти, инфраструктурен код или pipeline, които са на партньора, а не Ваши - Оценки на разходите без допускания и без план за етикетиране или бюджети - Предаване на знанията, насрочено за последната седмица ## Планирайте предаването на знания от първата седмица, а не от последната Миграцията приключва; поддръжката на платформата – не. Попитайте как екипът Ви ще се научи да управлява изграденото: съвместна работа по реални задачи по време на миграцията, ръководства за повтарящите се операции и преглед на наблюдението и известията с хората, които ще бъдат на дежурство. Поискайте всичко да е във Вашите акаунти и хранилища от самото начало: инфраструктурен код, pipeline, ръководства и диаграми. След това договорете как се приема предаването, например екипът Ви да внедри и да върне назад приложение без помощта на партньора. Работихме в екипа, който премести 600+ вътрешни приложения на Crédit Agricole от стари виртуални машини към AWS, като сами изпълнихме 50+ от тези миграции. Ако искате второ мнение за предложение за миграция или екип, който да изпълни част от работата, нашите инженери по облачна инфраструктура могат да минат през тези въпроси заедно с Вас. ## Основното накратко - Попитайте как ще бъде изготвена и проверена инвентаризацията, защото всяка оценка и всеки план по вълни зависят от нея. - Очаквайте стратегия за миграция, избрана за всяко приложение, с критерии, които можете да видите приложени към собствените си системи. - Нека landing zone е описана като код, прегледана от екипа Ви по сигурност и държана във Вашите акаунти. - Не приемайте план за превключване без посочено условие за връщане и без начин да възстановите данните, записани след превключването. - Договорете етикетирането, бюджетите и начина на приемане на предаването, преди да се премести първото приложение. ## Въпроси и отговори ### Трябва ли партньорът, който оценява нашия парк от приложения, и да го мигрира? Може, и често това спестява време, защото екипът, изготвил инвентаризацията, познава граничните случаи. Купете оценката като отделен резултат, който е Ваш, за да можете да я занесете на друг партньор, ако предложението за миграция не Ви убеди. ### Как да сравним предложенията на различни партньори за миграция? Дайте на всеки партньор едно и също извлечение от инвентаризацията и едни и същи въпроси и помолете всеки да приложи критериите си към едни и същи няколко приложения. Сравнявайте разсъжденията, плановете за връщане и допусканията зад оценките, а не само общата цена. ### Може ли екипът ни да продължи да пуска нови функции по време на миграцията? Да, ако планът казва как. Договорете прозорец за замразяване на промените за всяко приложение, начин двете среди да се поддържат синхронизирани, докато то се премества, и кой одобрява изданията, докато приложението е в процес на преместване. ## Свързани услуги - [Миграция към облака](https://sdk.enterprises/bg/services/cloud-infrastructure) - [Технически одит и консултации](https://sdk.enterprises/bg/services/consulting) ## Още по темата - [Миграция на стотици стари приложения към AWS без забавяне](https://sdk.enterprises/bg/insights/migrating-hundreds-of-apps-to-aws) - [Какво да попитате софтуерен партньор, преди да го наемете](https://sdk.enterprises/bg/insights/choosing-a-software-partner)