Azure migration readiness
Azure migration Kazakhstan guide: workloads, data residency, landing zone, FinOps в РК, backup/DR, identity и estimate inputs для миграции.
Tugelbay Konabayev, Marketing Specialist · 9 июня 2026 г.
Эти блоки отвечают на практические вопросы без скрытого текста и без неподтвержденных обещаний по срокам, стоимости или результату.
Начните не с выбора виртуальной машины, а с migration readiness: список систем, владельцы workloads, зависимости, данные, безопасность, сеть, текущие метрики, SLA/RTO/RPO, требования закупки и cost model. После этого выберите один пилотный workload и подготовьте landing zone, бюджет, теги и rollback plan.
Первым лучше переносить workload с понятным owner, умеренным риском, измеримыми метриками, ограниченными зависимостями и ясной бизнес-причиной. Плохой первый кандидат - критичная система с неизвестными зависимостями, sensitive data без review, сложной лицензией и отсутствием rollback.
Контроль расходов начинается до миграции: cost model, tags, ownership, budgets, alerts, reserved/savings options where applicable, right-sizing, shutdown policies for non-prod and regular cost review. Microsoft budgets and alerts notify about thresholds, but they do not automatically stop resources.
Azure landing zone - это подготовленная основа для workloads: subscriptions, management groups, identity, network, security, governance, monitoring, policies and automation. Это не один сервер, а repeatable environment, где новые workloads не запускаются хаотично.
Если бизнесу важнее устойчивость, RTO/RPO, восстановление после сбоя или отказ от второго datacenter, сначала может быть уместен backup/DR route. Это не полноценная migration, но он помогает защитить workloads, проверить зависимости и подготовить cloud discipline.
Проверьте текущий Microsoft Azure region list, contractual terms, категории данных, персональные данные, внутренние политики, отраслевые требования, cross-border processing, backup/replication scope and legal/compliance approval. Нельзя обещать, что Azure автоматически закрывает требования Казахстана.
Сначала классифицируйте данные и получите legal/compliance decision по каждому workload. Если политика клиента или юридический review требует хранение отдельных данных в Казахстане, нельзя решать это простым lift-and-shift в ближайший Azure region: нужны hybrid design, локальный approved storage для sensitive data, tokenization/anonymization или другой validated architecture.
FinOps в РК начинается с owner, tags, budget, alerts, cleanup rules, right-sizing, non-prod shutdown, review of backup/log retention and procurement/tax assumptions. Не полагайтесь только на calculator: после pilot нужно сверять фактическое потребление, прогноз, business value and finance rules.
Нужны текущие CPU/RAM/storage/network metrics, peak load, OS/database versions, лицензии, dependencies, security requirements, region assumptions, backup/DR expectations, traffic, support model, target architecture, non-prod environments and cost owner. Без этих вводных estimate будет гаданием.
Проверьте Microsoft Entra tenant ownership, admin roles, guest users, partner access, conditional access, MFA, service accounts, privileged identities, cross-tenant collaboration and audit logs. Если identity не готова, Azure migration может усилить старые риски вместо того, чтобы их закрыть.
Azure часто становится инфраструктурным, integration or data layer рядом с Microsoft 365, Dynamics 365, Power BI/Fabric, Power Platform and security. Важно заранее определить, где Azure нужен для hosting, API, identity, data platform, backup/DR, integration or governance.
Azure migration Kazakhstan должна начинаться с readiness, а не с покупки cloud resources. Правильный стартовый вопрос звучит так: “Какой workload можно безопасно перенести первым, какие данные он обрабатывает, какие у него зависимости, кто владеет бюджетом, какой rollback возможен и какие требования legal/security/compliance нужно проверить”. Не “какой сервер взять в Azure?”.
Этот гайд адресован IT, безопасности, финансам, закупке и владельцам бизнеса, обсуждающим Azure в контексте Microsoft stack. Он не заменяет юридическое заключение, коммерческое предложение или расчет цены. Его задача — помочь собрать исходные данные, отделить migration от backup/DR, различать landing zone и отдельный VM, сохранить cost governance и избежать неоправданных утверждений о data residency.
Microsoft Cloud Adoption Framework определяет миграцию как последовательность шагов, сроки и метод переноса рабочих нагрузок в Azure. Оценка workload дает видимость архитектуры, производительности, безопасности, кода и баз данных до переноса. Главное: Azure migration начинается с видимости. Без знания dependencies, CPU/RAM/storage metrics, security requirements, database versions, network flows, RTO/RPO и владельцев проект станет набором предположений, а не управляемым процессом.
Для Казахстана добавляется уровень: data residency, персональные данные, договорные обязательства и клиентские политики. На момент подготовки гайда (июнь 2026) при проверке официального Microsoft Azure regions list Казахстан не найден как public Azure region. Поэтому гайд не утверждает “Azure закрывает требования Казахстана” и не советует “выберите регион — будет legal”. Вместо этого он фиксирует необходимое: вопросы размещения данных и персональных данных должны проверяться юристами, безопасностью и комплаенс-владельцем клиента, опираясь на текущую документацию Microsoft (https://azure.microsoft.com/en-us/explore/global-infrastructure/geographies/ и https://learn.microsoft.com/en-us/azure/reliability/regions-list) и законодательство Казахстана.
Первый workload должен снижать риск, а не демонстрировать смелость команды. Если начать с критичной системы, где никто не знает dependencies, есть персональные данные, legacy database, hard-coded credentials, нестабильная сеть и отсутствует rollback plan, быстро получится дорогой cloud incident. Если начать слишком узко — например с неважного тестового сервера — пилот не докажет пользу бизнесу.
Хороший первый workload обычно имеет несколько признаков:
Внутренний сервис с умеренной нагрузкой, понятной БД, ограниченными пользователями и четким мониторингом часто подходит лучше, чем основная ERP. Системы 1С, CRM, клиентские порталы, финансовые БД и сервисы с чувствительными персональными данными требуют более зрелого assessment. Их можно переносить, но редко как первый эксперимент.
Большую миграцию лучше проводить волнами, а не одним броском. Wave объединяет связанные компоненты, которые нужно переносить вместе. Microsoft CAF подчеркивает: прямые зависимости требуют совместного переноса, иначе возникают сбои. На практике: сервер приложения без БД, queue, identity integration, firewall rules и monitoring не сработает после переноса, хотя сам VM запустится.
Перед первой wave соберите:
Без этих данных estimate выглядит уверенно на бумаге, но в реальности команда обнаруживает зависимости после cutover — самый дорогой момент для discovery.
| Ситуация | Что это значит | Практичный следующий шаг |
|---|---|---|
| Есть один понятный workload, owner, metrics, dependencies and rollback. | Можно готовить migration pilot. | Собрать assessment, landing zone minimum, cost model, security baseline and cutover plan. |
| Бизнесу важнее восстановление после сбоя, чем перенос production. | Backup/DR route может быть лучше first step. | Описать RTO/RPO, критичные systems, replication/backup scope and recovery testing. |
| Azure уже используется, но расходы растут без owner. | Проблема не migration, а FinOps/governance. | Ввести tags, budgets, alerts, cost review, resource cleanup and accountability model. |
| Нет subscriptions, policies, network, identity model or monitoring foundation. | Нужна landing zone до production workloads. | Подготовить minimum landing zone design: identity, networking, governance, security and automation. |
| Workload содержит personal/client/regulated data. | Region и data residency нельзя решать только технически. | Подключить legal/compliance owner and validate Microsoft docs, contracts, policies and KZ requirements. |
Data residency при Azure migration — это не выбор ближайшего региона. Это категории данных, юридические обязательства, внутренние политики, договорные ограничения, логика backup/replication, доступ в поддержку, логирование, мониторинг, пути данных и утверждающая сторона.
Закон Республики Казахстан от 21 мая 2013 года № 94-V «О персональных данных и их защите» (источник: Adilet) — основной правовой документ. Гайд не толкует закон для конкретной компании и не гарантирует, что любой Azure region, архитектура или контракт соответствуют требованиям Казахстана. Он фиксирует необходимое: если workload обрабатывает персональные, клиентские, сотрудничские данные, финансовую отчетность или регулируемую информацию, юридический и compliance-владелец должны проверить путь данных перед миграцией.
Это не юридическая консультация. Production-архитектуру должны согласовать квалифицированный юридический/compliance-эксперт и владелец data-protection клиента, с учетом текущего законодательства и условий Microsoft.
Чеклист для обсуждения размещения данных:
Microsoft Azure region list нужно трактовать как живой источник. На момент подготовки гайда Казахстан не входил в список публичных Azure regions. Это не заменяет финальное подтверждение Microsoft и не решает юридические вопросы. Это означает: гайд не предполагает локальный регион в Казахстане и не обещает автоматическую локальную резидентность.
Для региональных компаний, работающих в КЗ, УЗ, АЗ, АМ, ГЕ, КГ и УА, вопросы размещения данных становятся более сложными. Одна региональная страница не должна утверждать один универсальный ответ. Каждая страна, контракт клиента и класс данных могут потребовать своего пути одобрения.
Если review показывает, что определенные данные должны оставаться в одобренной казахстанской среде, ответ не “перенесем всё в ближайший регион Azure и будем надеяться”. Более безопасное обсуждение архитектуры может включать:
Вот почему запросы про data residency Казахстана требуют аккуратного контента. Гайд может объяснить фреймворк решения, но только текущая проверка документации Microsoft, review контракта и customer-specific legal/compliance review могут одобрить финальный маршрут.
Azure landing zone — основа для рабочих нагрузок с согласованным управлением. Microsoft определяет это как стандартный подход к настройке и управлению Azure в масштабе с согласованием security, compliance и операционной эффективности. Включает: billing и tenant, управление идентичностью, группы управления и subscriptions, сетевую топологию, security, governance, автоматизацию и DevOps.
Просто: landing zone — это не “мы создали VM”. Это подготовленная среда вокруг VM и приложения. Без него каждая новая рабочая нагрузка изобретает свою идентичность, сеть, именование, мониторинг, политику, резервную копию, теги и security-решения. Может работать на демонстрации, но не как устойчивая платформа.
Минимальные вопросы landing zone:
Для небольших компаний landing zone не нужно делать масштабной программой. Но даже минимальный вариант должен предотвратить хаос. Если разработчики, подрядчики и отделы создают ресурсы без тегов, бюджета, owner и security controls, расходы и риск быстро растут.
Azure cost management начинается до миграции. Workload с фиксированной стоимостью локального сервера может стать переменной облачной стоимостью. Это хорошо, когда использование эластично и управляемо. Это опасно, когда ресурсы завышены по размеру, неиспользуемы, без тегов, always-on и никто не владеет счетом.
Принципы оптимизации затрат Microsoft Well-Architected подчеркивают ROI, финансовые ограничения, модель затрат, подотчетность, границы бюджета, непрерывный мониторинг и повторяемые процессы. Практический перевод для казахстанских B2B-покупателей прост: не спрашивайте только “сколько стоит Azure”. Спросите:
Microsoft Cost Management budgets помогают планировать и обеспечивают подотчетность. Они срабатывают оповещениями по фактическим или прогнозируемым затратам, но, по документации Microsoft, ресурсы не блокируются и потребление не останавливается. Это важно: оповещение без владельца и плана действий — просто письмо. FinOps требует поведения: review, cleanup, right-sizing и принятие решений.
Чеклист контроля затрат:
Для FinOps в РК добавьте финансовые и закупочные предположения с начала. Облачная стоимость — не только техническая оценка. Нужно понять маршрут счета, валютный риск, налоговый режим, лимиты одобрения, tender/RFP правила, собственника контракта и был ли Microsoft куплен через CSP/LSP. Гайд не дает налоговые советы. Но операционная логика такая: если finance увидит налоговые, счетные и закупочные вопросы только после пилота, одобрение может остановиться, даже если архитектура хороша.
Практический ритм FinOps:
Это разница между “Azure estimate” и “Azure cost governance”. Estimate дает число. Governance гарантирует, что число имеет владельца, monitoring loop и бизнес-решение за ним.
Иногда первый облачный проект не должен быть миграцией. Если главная боль — риск простоя, расходы второго дата-центра, слабая резервная копия, отсутствие test-восстановления или неясный RTO/RPO, backup/DR может быть лучшим маршрутом.
Azure Site Recovery — сервис аварийного восстановления локальных рабочих нагрузок и Azure VMs. Помогает непрерывности бизнеса через репликацию с основного сайта на резервный, обеспечивая failover и failback. Azure Backup сохраняет данные в безопасности и восстанавливаемости.
Это не значит, что backup/DR просто или бесплатно. Это все еще требует:
Backup/DR может быть менее дезорганизующим, чем полная миграция. Он выявляет зависимости и operational gaps до cutover production-workload. Если компания никогда не тестировала восстановление, migration-проект может начаться с обсуждения resilience.
Для запросов про резервное копирование Azure, держите разницу ясной:
Эти маршруты могут поддерживать друг друга, но это не одни и те же сервисы. Компания может начать с backup/DR, чтобы уменьшить operational риск, а потом использовать findings для планирования волн миграции.
Для B2B-сценариев Azure migration — также проект идентичности. Workload может быть инфраструктурой, но реальный риск часто в Microsoft Entra ID: учетные записи администратора, гостевые пользователи, доступ партнеров, старые service accounts, отсутствие MFA, слабый conditional access, неуправляемый break-glass или непроверяемые audit logs.
Перед перемещением рабочей нагрузки, проверьте:
Это важно для CSP-партнеров, LSP-клиентов, CSP-заказчиков и tender/RFP-покупателей. Proposal миграции, игнорирующий идентичность, может выглядеть дешевле, но часто скрывает сложнейшую security-работу. Если компания уже использует Microsoft 365, Dynamics 365, Power BI или Power Platform, Azure readiness должна быть связана с tenant readiness, а не рассматриваться отдельно.
Для customer-facing или partner-facing систем проверьте B2B collaboration flows. Кто может пригласить внешних пользователей? Какие домены разрешены? Что происходит с guest доступом после проекта? Проверены ли partner-администраторы? Видны ли privileged действия в логах? Это не косметика. Это решает, будет ли Azure контролируемой платформой или еще одним местом, где живут старые access-проблемы.
Azure estimate без вводных — это угадывание. Может быть полезным как приблизительный диапазон, но не как бюджетное решение. Microsoft CAF рекомендует собирать подробную информацию об архитектуре, производительности, безопасности, коде и БД. Вот что нужно собрать:
Technical inputs:
Бизнес и governance вводные:
Cloud target inputs:
Без этих вводных следующий шаг — не натянутая цифра, а assessment. Azure Migrate помогает обнаружить, оценить и спланировать. Это сервис для решения, планирования и выполнения миграции в Azure с оценкой готовности и стоимости для серверов, БД, веб-приложений, виртуальных рабочих столов с минимальным downtime и риском.
Azure редко используется отдельно. Для Promise Group Kazakhstan Azure обычно подключен к более широкому маршруту Microsoft:
Если Dynamics 365 project требует API layer, integration monitoring или обмен данными с локальными системами, Azure может быть частью архитектуры. Если Power BI требует подготовленные данные, Fabric или data pipelines, Azure может быть релевантна для data layer. Если Microsoft 365 tenant имеет security gaps, Azure migration не должна игнорировать идентичность и мониторинг. Если закупка формальная, Azure scope нуждается в ясном RFP package.
Useful internal routes:
Before image generation, use this prompt:
Professional realistic cloud migration planning room in Kazakhstan: infrastructure architect, finance owner and security lead reviewing an abstract workload migration roadmap and Azure cost-control dashboard on a large screen, clean blue/teal enterprise lighting, subtle regional operations context, visual elements for workloads, network paths, budget thresholds and backup/DR without readable text, no logos, no fake cloud provider badges, no cartoon style, premium B2B consulting photography, 16:9, sharp web hero composition.
Alt text after generation: Команда IT, finance and security планирует Azure migration, workload roadmap and cost governance.
Caption: Azure migration начинается с readiness, data policy and cost governance, not with a random VM size.
Технические факты в этом гайде основаны на официальных источниках Microsoft и официальных/юридических источниках, где это применимо:
https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/migrate/plan-migrationhttps://learn.microsoft.com/en-us/azure/cloud-adoption-framework/plan/assess-workloads-for-cloud-migrationhttps://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zonehttps://learn.microsoft.com/en-us/azure/well-architected/cost-optimization/principleshttps://learn.microsoft.com/en-us/azure/cost-management-billing/costs/tutorial-acm-create-budgetshttps://learn.microsoft.com/en-us/azure/cost-management-billing/costs/cost-mgt-alerts-monitor-usage-spendinghttps://learn.microsoft.com/en-us/azure/reliability/regions-listhttps://azure.microsoft.com/en-us/explore/global-infrastructure/geographieshttps://learn.microsoft.com/en-us/azure/migrate/migrate-services-overviewhttps://learn.microsoft.com/en-us/azure/site-recoveryhttps://learn.microsoft.com/en-us/azure/site-recovery/site-recovery-overviewhttps://adilet.zan.kz/rus/docs/Z1300000094/z13094.htmЭтот гайд не публикует специфичные для Казахстана цены Azure, не обещает экономию затрат, не гарантирует успех миграции, не подтверждает tier/status партнера Microsoft, не дает юридический совет, не сертифицирует data residency и не заменяет документацию Microsoft или customer-specific оценку. Перед production миграцией, проверьте текущие условия Microsoft, доступность Azure region, доступность сервиса, contractual commitments, security controls, legal/compliance вопросы, правила procurement и workload-specific архитектуру.
Иногда технически можно, но как стратегия это часто рискованно. Без dependency map, landing zone, cost model, security baseline and rollback plan массовая миграция может перенести старые проблемы в облако и добавить новые расходы.
На июнь 2026 года в официальном списке регионов Microsoft Azure Казахстан не значится как public Azure region. Перед любым решением нужно заново проверить актуальный список регионов на официальном сайте Microsoft и согласовать требования по data residency и персональным данным с legal/compliance owner.
Нет. Microsoft Cost Management budgets помогают планировать, назначать accountability and notify stakeholders through alerts. Они не останавливают ресурсы сами по себе. Для контроля нужны governance rules, alert response, automation and operational ownership.
Они связаны. Первый workload помогает не строить абстрактную платформу без бизнес-цели, а landing zone помогает не запускать workload хаотично. Обычно нужен минимально достаточный foundation плюс один контролируемый pilot workload.
Azure Migrate полезен, когда нужно discover, assess, plan and migrate servers, databases, web apps or other supported workloads. Он помогает оценить readiness and cost, но результаты нужно проверять с workload owners, security and finance.
Нет. Цена зависит от region, service choice, sizing, storage, data transfer, backup, monitoring, support, licensing, reserved/savings options, environments and growth. Без metrics and target architecture точная оценка будет ненадежной.
Если закупка формальная, migration readiness нужно превратить в scope: workloads, assumptions, exclusions, dependencies, estimate inputs, security requirements, data residency questions, acceptance criteria and support model. Иначе RFP быстро станет слишком широким.
Да. Для Microsoft-focused компании Azure часто связан с Entra ID, Microsoft 365, CSP/LSP процессами и внешними подрядчиками. Guest users, partner relationships, privileged roles, MFA, conditional access and audit logs должны быть частью readiness review.
Используйте этот гайд как migration-readiness brief: соберите workloads, dependencies, data categories, metrics, region assumptions, budget owner and risk questions. После этого проще понять, начинать ли с migration, landing zone, backup/DR, FinOps, compliance review или RFP.