Технология проведения миграции данных в крупных проектах. Методика организации проведения миграции данных Что такое миграция данных

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

РАЗГРУЗКА «Миграция данных»

Перенос данных представляет собой значительный риск непрерывности бизнеса, если он выполнен неправильно. Потеря данных, конечно, является худшим сценарием, но компании также должны иметь дело со временем простоя, проблемами совместимости и общей проблемой производительности системы. Перенос данных затрудняется из-за большого количества данных, различных форматов данных и различий в данных в корпорациях.

Чтобы свести к минимуму риски миграции данных, компании создают подробные политики переноса данных, которые по мере необходимости приостанавливают резервное копирование, порядок перемещения и параллельные среды данных. Если компания не может запускать среду предварительной миграции при подготовке новой среды, тогда будет значительное время простоя, так как бизнес-операции над текущими приложениями приостанавливаются, чтобы разрешить миграцию данных. Этот тип переноса остановки, переноса и запуска может потребоваться при переходе на новые платформы или при наличии жестких ограничений на физическое хранение, а для существующей технологии хранения требуются свопы или исправления.

Миграция данных с нулевым временем простоя

Модель миграции с нулевым временем простоя зависит от наличия достаточного количества хранилища для создания и запуска двух полных сред. Полная копия данных компании берется в новую среду и проверяется, пока сотрудники остаются в старой среде. Ошибки разрабатываются из новой системы, гарантируя, что все приложения все еще работают, и все там, где должно быть. По завершении тестирования появляется новая копия, и все сотрудники переходят на новую среду. Старая среда данных иногда остается открытой в течение нескольких месяцев, чтобы сотрудники могли получать файлы из старой системы данных, но не записывали новые данные на эти серверы. Во всех миграциях данных выполняется проверка данных после миграции для проверки потери данных.

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

Сергей Бердачук, 1.0 2006.12.01

Казалось бы, что наличие уже существующей информационной системы (ИС) должно упростить и ускорить разработку новой ИС на основе старой, но на практике все обычно происходит с точностью до наоборот. Во первых, так как возникла необходимость в создании новой ИС, то это чаще всего означает, что ранее созданная ИС была создана с существенными изъянами и изобилует разнообразными ошибками.

Обычно, ото ИС, которая писалась на протяжении многих лет различными разработчиками. При этом проектная документация чаще всего находится в жалком состоянии, а порой и вообще отсутствует. «Настоящие» программисты не пишут документации, а тем более не документируют программный код. Зачем, ведь все просто и прозрачно. Тем не менее, когда смотришь на свой же код спустя пол года, то довольно сложно разобраться, что же там делалось. Особенно, если за это время было сделано несколько других проектов.

Мало того, каждый новый разработчик обычно не утруждает себя тщательным изучением ни кода, ни архитектуры системы. Так как сроки всегда «горят», то просто пишутся «примочки» для временного решения насущной проблемы. В результате получается «каша», состоящая из множества разношерстных модулей и каким то чудесным образом состыкованных технологий, которые порой не совместимы друг с другом. Положение усугубляется использованием устаревших систем управления базами данных (СУБД) для хранения данных, например dbase-III, FoxPro или Clipper. Отсутствие понятия транзакции, а при неумелом проектировании и ссылочной целостности приводит к многочисленным нарушениям целостности данных. Можно считать, что повезло, если в старой системе использовалась СУБД, иногда встречаются творения, использующие текстовые файлы для хранения данных (при миграции одной из таких систем автору пришлось писать специальный драйвер для доступа к такой базе данных).

Пожалуй, единственным положительным моментом является накопленный опыт по формированию требований к вновь разрабатываемой ИС. С другой стороны, опыт общения со старой системой может стать существенным тормозом при внедрении нового продукта. Чаще всего это возникает из-за различий построения визуального интерфейса и используемых функциональных клавиш для выполнения некоторых операций. Так, часть функциональных клавиш может быть зарезервирована операционной системой для выполнения некоторых действий. Типичным примером является применение клавиши “Enter” для перехода к следующему элементу редактируемой формы в старых ИС под DOS. В графических интерфейсах обычно для этих целей применяется клавиша “Tab”. В результате, мы получаем жесткое противодействие со стороны пользователей при внедрении новой версии продукта. Конечно, можно эмулировать поведение UI (User Interface) интерфейса старой системы, но делать это лучше всего опционально. Т.е. ввести возможность настройки поведения системы в модуле конфигурирования ИС, а по умолчанию использовать настройки соответствующие текущей операционной системе. В противном случае, вновь разработанный продукт будет труден в освоении новыми пользователями, которые ожидают поведения программы в соответствии с текущими стандартами.

Что же касается работы с хранимыми данными старой системы, то тут положение еще хуже. Наиболее тяжелые последствия будет иметь решение руководства использовать часть модулей старой системы. Например, когда перед нами стоит задача разработать новую версию складского учета, а решением остальных задач (бухучет и т.д.) пока будет заниматься старая версия ИС. В данном режиме работы встает проблема миграции данных в «реальном» режиме времени. Накладные расходы, по поддержанию работы всех модулей в целом могут превысить затраты на разработку новой версии всех модулей. Причем затраты могут отличаться на порядки, с учетом возможных потерь от недочетов старой системы и ошибок при обмене и преобразовании данных. Так что следует тщательно оценить состояние старой ИС и целесообразности. И что самое интересное, на практике данная проблема обычно не затрагивается, вплоть до возникновения: “Вот создадим новую систему, а потом и будем заниматься стыковкой с другим программным обеспечением и мигрировать данные”.

Но вот настает момент, когда проблема назрела, новая система написана, и пора заниматься преобразованием и перекачкой данных в новую систему. Анализируя опыт мигрирования данных большого количества разнообразных информационных систем можно выделить типовую процедуру миграции данных, которая включает в себя:

• Анализ форматов данных структуры старой базы данных и новой, подготовка плана миграции и преобразования данных;
• Определение взаимосвязей между таблицами (иерархии объектов);
• Определение последовательности закачки данных в соответствии с иерархией зависимостей. Иногда, но не всегда (например, когда новая версия базы данных уже находится в эксплуатации) можно не учитывать взаимосвязи, а просто отключить все внешние ключи перед миграцией и пересоздать их после завершения всех манипуляций с данными;
• Выполнение скрипта по изменению объектов в новой версии базы данных;
• Непосредственная перекачка данных с необходимыми преобразованиями “на лету”;
• Выполнение скрипта для восстановления отключенных индексов, дополнительных преобразований и т.д. после завершения процедуры миграции данных.

Самым простым вариантом обычно является создание промежуточной программы. Она должна связываться с исходной и целевой базами данных, и выполнять нужные преобразования.

Рис. 1. Вариант с промежуточной программой для миграции данных

Существенным недостатком данного решения может стать сетевая нагрузка при передаче данных. Если объем данных существенен, то сетевой обмен может сильно сказаться на производительности.

Более выгодным решением может быть предварительная загрузка старых данных во временные таблицы новой СУБД. Современные СУБД (например, Oracle) обычно содержат специальные утилиты, которые позволяют производить очень быструю закачку внешних данных различных форматов. Непосредственно модуль миграции пишется встроенными в СУБД процедурными языками (например, PL/SQL или java). Можно существенно повысить скорость выполнения процедуры миграции за счет того, что встроенные языки программирования работают в “родной” среде, оптимизированы под целевую СУБД и нет накладных расходов на обмен данными по сети.

Рис. 2. Вариант миграции данных средствами СУБД

Из практического опыта написания таких программ хочется обратить внимание на использование пакетных SQL методов, которые поддерживаются большинством СУБД и языками программирования (например, методы addBatch() и executeBatch() в java). Выполнение одного оператора добавления INSERT или обновления UPDATE для массива данных пачками по 100 - 200 записей дает существенный выигрыш производительности, в сравнении с выполнением данного оператора поочередно в цикле для каждой записи.

Миграция данных

Миграция данных – многоэтапный процесс перемещения баз данных, программного обеспечения, финансовых или других бизнес-данных между различными ИТ-системами. Продуманный план перехода позволит плавно перенести базы данных, программы и приложения, а также любые иные данные в облако провайдера без неожиданных рисков простоя бизнес-процессов. DEAC обеспечивает надежный пошаговый перенос данных из собственного или размещенного у третьих лиц ИТ-оборудования в инфраструктуру дата-центров DEAC .

Пошаговый план миграции
Эксперты DEAC контролируют и документируют весь процесс миграции данных, поддерживая прозрачность и эффективность проекта

Миграция в облако или сервер
Вне зависимости от географического расположения и используемых систем хранения данных, DEAC обеспечит полную интеграцию данных без риска потери данных

Минимальное влияние на активные бизнес-процессы
Подробный план миграции сохраняет полную производительность приложений, защищая от проблем технической несовместимости или внезапного простоя

Дата-центры стали критическим элементом бизнеса, когда для его развития требуется надежная миграция данных и перемещение рабочих нагрузок. Миграция между дата-центрами, консолидация, план аварийного восстановления или перестройка облачной инфраструктуры - DEAC обеспечит опытную команду, инструменты и знания для успешного проведения проекта. DEAC сотрудничает с ведущими мировыми поставщиками и вендорами, обеспечивая клиенту единую точку контакта на всех этапах миграции.
Такой подход гарантирует выгодную, защищенную от рисков стратегию миграции как для виртуальной, так и для физической миграции данных.

Выберите опытного поставщика услуг и получите качественный
и бесперебойный процесс миграции данных.

Многолетний опыт DEAC , сертифицированные эксперты и гибкая инфраструктура гарантируют надежную миграцию данных в дата-центры повышенного уровня безопасности. Для обеспечения непрерывности процессов, особое внимание экспертов DEAC во время миграции направлено на успешное перемещение, целостность, приватность и безопасность данных и приложений. Ваши данные могут быть размещены как в частном , публичном или гибридном облаке , так и на выделенном или виртуальном сервере , с высокоскоростными соединениями. Наши эксперты помогут подобрать индивидуальное или уже готовое к работе решение, которое соответствует требованиям вашей ИТ-системы.

Миграция облака

Миграция базы данных

Миграция приложений

DEAC предоставляет полный процесс миграции из собственной инфраструктуры клиента в облако или из одной облачной среды в другую (cloud-to-cloud migration ). Перемещение данных, информационных хранилищ, приложений, и других ИТ-элементов бизнеса в облако позволяет сохранить безопасность и доступность без неожиданных простоев процессов. DEAC использует специализированные облачные инструменты для полноценной интеграции данных или систем.

Миграция базы данных предполагает смену программной платформы, поэтому в подготовительной фазе проводится полный аудит обеих платформ, чтобы обеспечить высочайшую совместимость и снизить риск возникновения ошибок на уровне приложений. Наши сертифицированные эксперты документируют весь процесс миграции базы данных в облако, сохраняя максимальную безопасность и функциональность систем.

Приложения имеют собственную архитектуру данных и специфическую конфигурацию платформы, которая может отличаться от новой среды, поэтому при миграции собственных приложений необходимо создавать пошаговый план перехода. Комплексный подход перенесения приложений позволяет сохранить важные данные, не отставать от плана и придерживаться проектного бюджета. Для каждого клиента DEAC разрабатывает индивидуальный план миграции, который соответствует необходимому объему данных, типу приложений, исходным технологиям и выбранной ИТ-инфраструктуре заказчика.

УЗНАТЬ БОЛЬШЕ О ДРУГИХ УСЛУГАХ:

Отрасль PLM развивается уже более десяти лет и наступил тот момент, когда предприятия, опробовав решения, выбранные изначально, вполне резонно решают сменить существующую PLM на другую, либо существенно изменить конфигурацию текущей. И тут возникает вопрос миграции данных PLM из старой системы в новую. Как мы знаем, даже трансляция самих геометрических данных является непростой и неоднозначно решаемой задачей, миграция данных PLM – еще более сложный и пока малоизвестный процесс.

Как это бывает

Выбор новой системы PLM был сделан, команда руководителей с облегчением празднует результат сложных усилий этого выбора. На деле, только теперь начинается настоящая работа, планирование и осуществление миграции данных из существующих систем в новую целевую платформу PLM. Существующие данные компании содержат значительную часть интеллектуальной собственности (ИС) и, следовательно, конкурентные преимущества и капитал компании. Успех внедрения новой системы в значительной степени зависит от выполнения эффективной миграции существующих данных, интеллигентно, качественно и своевременно.

Этот сценарий регулярно повторяется в том или ином виде по всему миру и в любой отрасли. С быстрыми темпами совершенствования технологий, усилением конкурентного давления, приводит к тому, что многие компании постоянно оценивают их PLM-решения и проводят улучшения. Решение может быть вызвано признанием того, что текущее решение, или, чаще, его техническое обслуживание, либо использование нескольких систем, не устраивают руководство компании. Кроме того, есть еще один общий мотив - последствия приобретений компании и осознание того, что консолидация их различных PLM решений является оправданным. Еще один сценарий – необходимость массивной перенастройки текущей платформы. Независимо от причин изменений, эффективное выполнение изменений будет зависеть от успешной миграции существующих данных на новую платформу.

Проблемы миграции данных

Миграция данных выносит на первый план многочисленные вопросы. Например, может выясниться, что это первая за многие годы ревизия того, как компания выбирала средства управления данными о продукте. Для того чтобы преодолеть очевидные недостатки в текущей модели данных, которая развивалась с течением времени, компании, возможно, придется изменить части модели или расширить ее. В любом случае, эти изменения окажут дополнительное давление на процесс перехода от старого к новому, простой перенос данных может оказаться невозможным. Один из важнейших моментов миграции заключается в том, что сначала нужно определить все данные, которые подлежат рассмотрению. Многие считают, что речь идет лишь о передаче цифровых данных, однако опытные специалисты наверняка признают, что какая-то часть критической ИС компании может все еще быть в печатном виде, либо вообще ее носителями являются головы ведущих сотрудников.

После того как данные, которые подлежат миграции были идентифицированы, необходимо разработать и исполнить процессы проверки их правильности. Часто данные могут оказаться устаревшими, поскольку последние изменения не были внесены в более ранние версии данных. Кроме того, часто используются дублированные данные (или поддерживается в нескольких системах), требуя постоянной или периодической проверки согласованности и чистки данных. Определение полного объема данных для миграции требует использования знаний наиболее опытных сотрудников компании.

Возможно, одной из самых больших проблем миграции данных являются сроки миграции. Старые данные будут постоянно пополняться и модифицироваться, так как компания не может остановить свою работу и ждать завершения новой реализации PLM. Кроме того, в реальности коллектив, осуществляющий миграцию, имеет весьма ограниченные технические сроки для реального переключения, типично это - выходные или праздничные дни. Необходимость уложиться в доступное календарное время требует реализации алгоритмов миграции с помощью специальных инструментов, так как данные могут легко содержать в себе сотни тысяч (или даже миллионов) записей.

Пример решения

Обратимся к опыту тех, кто осуществлял и осуществляет миграцию данных PLM на регулярной основе. Одним из признанных специалистов в области миграции данных PLM является немецкая компания PRION Group , имеющая одиннадцатилетний опыт оказания таких услуг и эффективный инструментарий для их выполнения. Так как портфолио PRION включает в себя интерфейсы для наиболее распространенных PDM и унаследованными системами, из которого данные должны быть перенесены, в каждом конкретном случае у компании нет необходимости заново разработать ПО для миграции. Это позволяет быстро разработать план перехода с учетом особенностей конкретной компании и быстро выполнить миграцию, чтобы минимизировать ее воздействие на развитие продукта и производства. На рисунке ниже изображена схема типового процесса миграции данных по методологии PRION.

Наиболее существенно то, что работоспособность этой схема многократно подтверждена выполненными проектами миграции данных PLM у многочисленных клиентов PRION. Более того, неоднократные попытки произвести прямую трансляцию данных из одной системы PLM в другую доказали 100% неработоспособность такого примитивного подхода. Среди факторов, определяющих такое положение дел: сбор данных из нескольких источников, необходимость преобразования и чистки данных, их аттестации и загрузки в новую систему (ы), которые также могут быть физически распределены. Таким образом, существуют совершенно неприемлемые при переходе на новую платформу PLM.

Для снижения этих рисков, PRION разработал средства миграции, которые используют промежуточную базу данных. Данные экспортируются в промежуточную базу данных и, перед загрузкой в новую целевую платформу PLM, преобразуются в этой базе данных. Такой подход не приводит к немедленному изменению в рабочих данных и бизнес может продолжаться как обычно, в то время как разрабатываются правила и детали процесса миграции данных. Критическим фактором для успеха миграции является создание системы управления изменениями, чтобы не только отслеживать изменения, сделанные в ходе миграции самих данных, но и изменения данных, сделанные после загрузки в новую платформу PLM. Эта система управления изменениями должна поддерживать конкретные требования заказчика от самого процесса миграции до запуска новой системы в эксплуатацию в реальных условиях.

Тот факт, что PRION может использовать многие из сценариев миграции из своей обширной библиотеки, которая была разработана для бывших клиентов снижает риски миграции и снижает затраты для будущих клиентов значительно. Этот подход помогает во многих трудных сценариев миграции, особенно когда целевая система является распределенным решением.

Для получения более детальной информации об инструментах и услугах PRION рекомендую обратиться на сайт

• перевести существующие домены ресурсов в организационные единицы новых доменов, что позволит упростить управление сетевыми ресурсами;
• "имитировать" ход миграции, при этом реального переноса данных не происходит;
• отменить сделанные действия, связанные с миграцией;
• переместить учетные записи служб;
• восстановить доверительные отношения между исходным и целевым доменами;
• преобразовать множество доменов в один или несколько крупных доменов в уже созданной среде Active Directory;
• реструктуризировать существующие группы или объединить несколько групп в одну в целевом домене ;
• провести анализ процесса переноса данных с помощью журнализации миграционных событий.

Миграция пользователей и рабочих станций в единую структуру Active Directory реализуется с сохранением существующих прав доступа.

Варианты модернизации

Существует два основных варианта модернизации доменной инфраструктуры [ 4 ] :

• Обновление доменов. Данный способ является наиболее распространенным и простым для реализации при миграции доменов. Этот способ позволяет сохранить текущую структуру доменов, настройки системы, структуру пользователей и групп. Обновление домена (in-place обновление) включает перевод контроллеров существующего домена в создаваемый домен .
• Реструктуризация доменов. Данный способ позволяет изменить существующую структуру доменов, объединить домены или преобразовать домены в организационные подразделения.

Помимо указанных выше вариантов, существует также смешанный вариант, основанный на них, - обновление доменов с их последующей реструктуризацией [ 13 ] .

Эти варианты называются путями перехода при внедрении Active Directory . Выбранный из них путь перехода будет являться главным звеном в общей стратегии обновления доменной инфраструктуры. Эта стратегия будет включать описание того, какие объекты службы каталога и в каком порядке необходимо переместить. Наилучший способ любого перемещения приложений при внедрении Active Directory состоит в документировании каждой детали в рабочий документ, называемый планом перехода.

Критерии выбора пути перехода

При выборе пути перехода подразумевается, что это решение касается только одного домена , то есть совершенно справедливо использовать различные пути перехода для различных доменов в пределах одной организации.

Рассмотрим основные критерии, которые используются при выборе наиболее подходящего пути перехода [ 13 ] , приведенные в таблицах 12.1 , 12.2 , 12.3 , 12.4 , 12.5 , 12.6 .

• Критерий 1. Удовлетворенность имеющейся моделью существующего домена . Таблица 12.1. Выбор пути перехода по критерию 1

  Путь перехода	Соответствие критерию
  Обновление домена	Если нет никаких существенных изменений, которые хотелось бы сделать в доменной модели, то обновление домена обеспечит самый легкий путь. Имя домена останется тем же самым, так же как и существование всех учетных записей пользователей и групп
  Реструктуризация домена	Если имеющаяся доменная модель больше не удовлетворяет организационным потребностям либо больше не является наиболее оптимальной для подразделений организации, то наилучшим выбором будет реструктуризация домена

• Критерий 2. Степень риска при переходе к новой модели домена. Таблица 12.2. Выбор пути перехода по критерию 2

  Путь перехода	Соответствие критерию
  Обновление домена	Обновление домена представляет собой метод с минимальным риском. Процесс модернизации контроллера домена выполняется автоматически, следовательно, без взаимодействия с пользователем возможностей для ошибок возникает немного. Методология восстановления после сбоя при обновлении домена также относительно проста: если обновление прошло неудачно, необходимо выключить основной контроллер домена ( PDC ), назначить любой резервный контроллер домена ( BDC ), имеющий свежие данные, на роль PDC , и начать процедуру снова
  Реструктуризация домена	Реструктуризация домена представляет собой путь с более высоким риском, чем обновление домена. Надо выполнить большее количество задач, и поэтому многие процессы могут идти не так как надо. В результате растет недовольство пользователей, которые не могут войти в систему, обратиться к необходимым ресурсам или получить доступ к своим почтовым ящикам

• Критерий 3. Время выполнения перехода 1График времени перехода не является решающим фактором при выборе пути перехода, тем не менее он может быть определяющим для небольших организаций с ограниченными ресурсами. . Таблица 12.3. Выбор пути перехода по критерию 3

  Путь перехода	Соответствие критерию
  Обновление домена	Обновление домена - это линейный процесс: если он был начат, то должен быть закончен. Для него требуется меньше действий, чем для реструктуризации, и, соответственно, меньше времени требуется для выполнения всего перехода
  Реструктуризация домена	Реструктуризация домена всегда длится дольше. Например, при реструктуризации тратится много времени на создание и проверку инфраструктуры целевого домена, на перемещение всех учетных записей с исходного домена на целевой домен. Крупные организации, возможно, не смогут переместить все объекты за один раз, так что достаточно часто реструктуризация домена производится в несколько этапов

• Критерий 4. Рабочее время службы каталога, которое необходимо затратить на процесс перехода. Таблица 12.4. Выбор пути перехода по критерию 4

  Путь перехода	Соответствие критерию
  Обновление домена	Объекты учетных записей недоступны в процессе перехода, потому что они самостоятельно модернизируются при обновлении домена
  Реструктуризация домена	Хороший выбор для организаций, в которых рабочее время системы является критической величиной. Так как она включает создание незаполненного, "чистого" леса и оставляет исходную среду по существу без изменений, то работоспособность службы каталога сохраняется, поскольку пользователи продолжают функционировать в существующей среде. Можно переносить большие или маленькие партии пользователей в течение непиковых часов работы и оставлять эти новые учетные записи бездействующими до того времени, как появится готовность покинуть старую систему

• Критерий 5. Наличие ресурсов для выполнения перехода. Таблица 12.5. Выбор пути перехода по критерию 5

  Путь перехода	Соответствие критерию
  Обновление домена	Поскольку обновление домена является автоматизированной операцией, то на реализацию этого пути перехода потребуется меньшее количество людских ресурсов
  Реструктуризация домена	Реструктуризация домена влечет за собой большее количество задач, чем обновление домена, и поэтому требуется большее количество ресурсов, то есть необходимо, чтобы штат сотрудников был адекватно укомплектован для выполнения дополнительной рабочей нагрузки, связанной с реструктуризацией домена. В качестве альтернативы можно переложить часть задач или весь проект на внешних сотрудников: существует множество консультативных групп, которые специализируются на таких проектах, что позволит сэкономить время и деньги, необходимые для обучения внутренних сотрудников

• Критерий 6. Бюджет проекта перехода. Таблица 12.6. Выбор пути перехода по критерию 5

  Путь перехода	Соответствие критерию
  Обновление домена	Факторы, способствующие уменьшению необходимых бюджетных средств: возможность использовать существующие серверные аппаратные средства; более низкие затраты на людские ресурсы; уменьшение расходов на тестирование, поскольку нужно будет тестировать меньшее количество задач модернизации
  Реструктуризация домена	По многим причинам реструктуризация домена потребует большего бюджета, чем обновление домена. Аппаратные требования, необходимые для построения незаполненной среды леса, в которую необходимо переносить объекты службы каталога, следует рассмотреть с точки зрения бюджетных затрат

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

Данный путь перехода к Active Directory позволит получить немедленную выгоду (делегирование администрирования, групповые политики , публикация приложений и многое другое), а также долговременную выгоду от реструктуризации домена (меньшее количество доменов с увеличенным объемом домена, проект домена в соответствии с деловыми и организационными целями компании).