Миграция системы. Этапы процесса миграции данных в проектах внедрения ис

Услуга по миграции действующей системы автоматизации управления ИТ-услугами с продукта HP OpenView Service Desk 4.5/5.x нацелена на решение следующих задач:

• снижения эксплуатационных рисков за счет перехода на продукт, который находится на полной поддержке у разработчика и его партнеров в РФ;
• снижение миграционных рисков, сокращение стоимости и сроков миграции за счет перехода на решение, которое идеологически максимально близко к HP OpenView Service Desk 4.5/5.x (не требует серьезной переработки действующих процессов и полного переобучения персонала);
• обеспечение возможности дальнейшего развития практики управления ИТ за счет преодоления функциональных ограничений, присущих действующей системе автоматизации.

Миграция выполняется на специализированное проектное решение OMNITRACKER CleverENGINE , реализованное на базе платформы OMNITRACKER. Данное решение обеспечивает заказчикам следующими важными преимуществами:

• решение CleverENGINE изначально создавалось с учетом необходимости максимально полного соответствия продукту HP OpenView Service Desk для обеспечения «мягкой» миграции. В CleverENGINE заложена схожая модель данных и тот же принцип организации пользовательского интерфейса. Это позволяет при миграции экономить силы и средства на вынужденную корректировку действующих процессов управления, переобучение персонала, а также оставляет возможность переноса исторических данных;
• решение CleverENGINE проектировалось и создавалось действующими консультантами в области управления ИТ. Функциональность, заложенная в CleverENGINE, существенно превосходит HP OpenView Service Desk. В частности, обеспечивает визуализацию CMDB, учет и контроль использования лицензий на программное обеспечение, управление релизами, ведение базы знаний, автоматизацию регламентных операций, мощный механизм согласований и многое другое. Это позволяет заказчикам совершенствовать практику управления ИТ, преодолев функциональные ограничения действующей системы автоматизации;
• платформа OMNITRACKER является средой для быстрой разработки различных workflow-приложений (в том числе за рамками управления ИТ-услугами). Решения на базе OMNITRACKER, как правило, передаются заказчикам в открытом виде - доступном для адаптации и дальнейшего развития. Многие заказчики самостоятельно развивают свои системы автоматизации, прибегая к незначительной помощи партнеров или не привлекая их совсем. При этом на базе одной платформы можно постепенно развивать функциональность, традиционно присущую различным продуктам - управление услугами, управление проектами, управление документами и другие решения.

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

Результаты

В результате выполнения проекта по миграции заказчик получает:

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

Типовой профиль проекта

Длительность проекта по миграции составляет от 2,5 до 4,5 месяцев - в зависимости от степени «кастомизации» действующей системы на базе HP OpenView Service Desk (количества правил бизнес-логики, форм и представлений данных, отчетности, решений по интеграции и так далее), а также от необходимости переноса исторических данных. Проект выполняется силами 1-2 специалистов. К работам привлекаются специалисты с экспертными знаниями по обоим продуктам - и HP OpenView Service Desk, и OMNITRACKER CleverENGINE.

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

Примеры выполненных проектов

Примеры проектов, выполненных консультантами Cleverics:

• Миграция системы автоматизации ITSM-процессов с HP OpenView Service Desk на OMNITRACKER CleverENGINE и оптимизация деятельности по поддержке пользователей (СК Альянс, 2014)
• Миграция системы автоматизации процессов ITSM с HP OpenView Service Desk 4.5 на OMNITRACKER CleverENGINE (КАТРЕН, 2013)
• Миграция системы автоматизации процессов ITSM с HP OpenView Service Desk 4.5 на OMNITRACKER CleverENGINE (ВТБ24, 2012-2013)
• Миграция системы автоматизации процессов ITSM (АвтоСпецЦентр, 2010)

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

О тонкостях процесса миграции нам рассказал Владимир Лебедев, директор по развитию бизнеса Stack Group .

Требования законодательства

В 2006 году был принят 152-ФЗ «О персональных данных» , который призван защитить физических лиц при автоматизированной обработке персональных данных. В прошлом году вступил в силу пакет поправок о локализации персональных данных на территории России, что, по мнению авторов, должно повысить уровень информационной безопасности внутри государства и простимулировать российский рынок технологических решений и рынок информационной безопасности.

По закону бизнес обязан собирать, хранить и обрабатывать персональные данные на территории РФ. Все требования совершенно одинаковы как для российских, так и для зарубежных компаний, если их деятельность направлена на территорию России. При этом передавать персональные данные за пределы страны можно, но они должны быть неизменяемыми, и их объем не должен превышать объем в российских базах данных.

Для кого закон?

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

В план проверок Роскомнадзора на 2016 год вошли: крупнейшие софтверные компании, международные банки, сетевые торговые компании и интернет-магазины.

Сложности переноса персональных данных для международных компаний

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

Виртуализация

Переехать в облачную среду менее затратно, чем покупать и монтировать оборудование. В конце 2014 года цены на российские облака были в среднем на 15–30% выше, чем на европейские, а в конце 2015 года, наоборот, наши цены стали на 20–30% ниже: изменился валютный курс и относительная стоимость размещения в российских дата-центрах.

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

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

Риски, возникающие при миграции систем хранения данных

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

Этапы миграции в облако

Общие принципы миграции сервиса, то есть переноса операционных систем, отвечающих за работу этого сервиса, в виртуализированную среду, рассмотрим на примере решения VMware vSphere .

Архитектуру информационных систем компании желательно разделить на выполняющие конкретные задачи сервисы. Обычно в облако перемещается все, кроме сервисов, которые несовместимы с cloud-технологией по техническим причинам (RISC-архитектура) и тех, что нельзя переместить из-за лицензии.

Далее необходим аудит информационных систем . На этом этапе определяется состав сервисов (какие ОС относятся к тому или иному сервису), а также их связность. Главная сложность заключается в многообразии исходных ОС и физической архитектуры серверов, на которых они работают. На основе этой информации составляется план миграции с учетом текущих бизнес-процессов: определяются требования к связности физической и виртуальной инфраструктур, порядок миграции, задаются допустимые «окна миграции». Важно помнить, что нельзя во время миграции обновлять версии программных продуктов или операционных систем. Одновременно с миграцией допускается только пересмотр вычислительных ресурсов (CPU, RAM, HDD).

Как правило, для миграции используется утилита VMware converter , которая эффективно работает при переносе ОС семейства Microsoft Windows (но у миграции работающих в этих ОС служб есть свои нюансы). А вот из-за особенностей файловых систем Linux примерно в 40% случаев после окончания работы VMware converter виртуальная машина может не запуститься. Если в Linux используется LVM, то надо развернуть в виртуальной среде новый экземпляр ОС из шаблона провайдера и затем перенести данные, программные продукты и внутренние службы.

Для любого типа ОС есть общие условия, затрудняющие миграцию: во-первых, способ хранения данных, из-за которого прямая миграция невозможна, - это динамические диски в Windows или LVM в Linux, а во-вторых, сложности из-за использования программных и аппаратных массивов RAID. Так, даже точный перенос данных сам по себе не гарантирует, что виртуальная машина успешно запустится. На физическом сервере работу виртуальных машин обеспечивает гипервизор - ОС, разделяющая физический сервер на несколько виртуальных машин, которые могут работать одновременно и использовать одни и те же физические ресурсы. Естественно, что набор виртуального оборудования у гипервизора не совпадает с оборудованием физического сервера, на котором работала ОС до миграции. Соответственно, из-за разницы драйверов возникает множество отличий доступа к этому оборудованию.

Миграция ADDS и MS SQL без остановки сервисов

Практически всегда для бизнеса необходимо, чтобы ряд сервисов оставался доступным в ходе миграции. При этом зачастую миграция без остановки сервиса рекомендуется как самая надежная. Поэтому рассмотрим особенности миграции без остановки наиболее популярных служб ОС Microsoft: Active Directory Domain Services (ADDS или AD) и Microsoft SQL (MS SQL). Для миграции Active Directory без остановки службы применяется следующий алгоритм:

• Формируется сетевая связность между физическим оборудованием и виртуализированной средой. Как правило, это site-to-site VPN - он создает логическую сеть поверх другой сети. При этом трафик может быть защищен шифрованием по протоколам IPsec.
• В облаке разворачиваем новые виртуальные машины из шаблона, где настраиваем контроллеры домена AD с добавлением их в лес.
• Базу данных Active Directory реплицируем по сети через VPN с работающих контроллеров на стороне физического оборудования в облачные.
• После репликации данных переназначаем мастеры ролей операций на облачные контроллеры и убираем роли контроллеров домена с серверов.
• Затем проверяем работу сервисов и отключаем учетные записи старых контроллеров и физическое оборудование.

Алгоритм миграции MS SQL более сложен, так как MS SQL обычно применятся в многоуровневом сервисе в качестве бэкенда. В записях DNS в приложениях, использующих базы данных (в клиентах MS SQL), приходится вручную указывать новое расположение базы данных. Поэтому совсем исключить простой нельзя, но его можно свести к минимуму. Существуют механизмы и безостановочной миграции MS SQL, к ним относятся Mirroring и AlwaysOn , но их применение не всегда оправданно. AlwaysOn доступен только в дорогих редакциях Enterprise-уровня, а Mirroring должен поддерживаться клиентами MS SQL. К тому же для применения механизмов Mirroring нужна дополнительная настройка всех клиентов MS SQL.
Рассмотрим наиболее частый вариант миграции MS SQL в облако:

• Настраивается сетевая связность между облаком и физическим оборудованием.
• Убеждаемся, что модель восстановления базы MS SQL полная, тогда можно сделать и перенести полную резервную копию, а затем синхронизировать обе базы данных, перенося копии транзакционных логов.
• В облаке разворачиваем виртуальную машину из шаблона, в которой устанавливаем и настраиваем новый MS SQL сервер.
• Создаем полную резервную копию базы данных MS SQL сервера, работающего на физическом сервере, затем восстанавливаем ее в облачном, при этом способ переноса резервной копии зависит от размеров файла и пропускной способности сети - перемещаем на физическом носителе либо копируем по сети.
• После восстановления базы данных в облаке делаем копию транзакционных логов и их также восстанавливаем в облаке.
• Во время «окна миграции» останавливаем работающий на физическом оборудовании MS SQL сервер, создаем и восстанавливаем последнюю минимальную по размеру копию транзакционных логов в облаке, запускаем MS SQL сервер в облаке и переключаем клиенты на новое месторасположение базы.
• Проверяем работу сервисов, отключаем физическое оборудование.

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

Информационная безопасность

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

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

Требования к хранению персональных данных

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

Требования к инфраструктуре

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

Также есть международные стандарты ISO, регламентирующие построение системы управления информационной безопасностью (комплекс стандартов ISO 2700х ). Многие иностранные компании соответствуют этим стандартам.

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

INFO

Прогноз на перенос

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

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

Многое изменилось в мире информационных технологий за последние 32 года, с тех пор как Microsoft выпустила Windows 1.0. Единственное, что осталось прежним, - сложность процессов миграции, или перехода на новую версию операционной системы, и развертывания обновлений. Если спросить пользователей, чего они хотят от миграции, вы получите ответ: плавного перехода с минимальными простоями и привычного взаимодействия с рабочим столом. Некоторые заявят, что вообще против миграции, но таких обычно немного.

Для чего нужна миграция

Существует много причин в пользу миграции на уровне настольных компьютеров. Две основные - безопасность и стоимость эксплуатации. Разработчики Microsoft неуклонно повышали безопасность настольных операционных систем; список технологий обеспечения безопасности, которых не было в старых версиях, производит сильное впечатление. Угрозы становятся все более изощренными, и Microsoft пришлось добавить такие функции, как запуск на первом этапе загрузки антивредоносного решения ELAM (https://docs.microsoft.com/en-us/windows-hardware/drivers/install/early-launch-antimalware) и управляемый доступ к папкам (https://docs.microsoft.com/en-us/windows/threat-protection/windows-defender-exploit-guard/controlled-folders-exploit-guard), превосходный способ защиты от программ-шантажистов, сам по себе достаточный повод задуматься о миграции. Безопасность - особенно серьезная проблема для компаний, все еще работающих с версиями операционной системы Windows 7 (и даже Windows XP), поскольку с тех пор угрозы значительно изменились, и усовершенствования, внесенные в Windows 10, в некотором отношении представляют самый начальный и не всегда достаточный уровень безопасности.

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

Процесс миграции

На приведенном рисунке показана простая схема основных этапов процесса миграции.

Существует много разных подходов к тому, как проводить каждый этап; целые книги написаны о том, как выполнять, например, пилотные ИТ-проекты. Коротко рассмотрим каждый этап с позиций миграции.

Инвентаризация среды

Многие компании располагают развитыми системами инвентаризации и управления, с помощью которых можно получить ответы на вопросы типа «как много активно используемых настольных компьютеров работает с Windows 8.1 с пакетом обновления 2?» или «сколько ноутбуков Dell XPS 13 имеется в наличии?» Системы управления, такие как System Center Configuration Manager (SCCM) и Microsoft Intune, можно задействовать для инвентаризации, если вы располагаете достаточными средствами и развернули их. В противном случае вам, возможно, придется прибегнуть к менее эффективным методам, например запросить отзывы пользователей, подготовить средство инвентаризации и продвигать его через групповую политику или вручную выполнить инвентаризацию и настроить параметры систем. Ключевое условие на данном этапе - получить точную модель существующих систем, чтобы правильно планировать нужное состояние.

Проектирование требуемого состояния

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

• Что вы переносите из исходного пункта (необходима инвентаризация среды).
• Что вы переносите в пункт назначения. При этом необходимо ответить на многочисленные вопросы, в том числе: на какую версию Windows выполняется переход? Вы остаетесь на физических настольных компьютерах, переходите в локальную виртуальную среду или перемещаетесь в «облако»? Как будет настроена целевая среда? Что делать в случае сбоя миграции или невозможности переноса систем?
• Ваше расписание. Большинству компаний приходится выполнять миграцию в течение продолжительного периода, а не одним гигантским прыжком. Когда следует переводить тех или иных пользователей? Как выглядит расписание в целом и как на нем отражаются внешние события (например, начало учебного года, конец финансового года или сезон распродаж)?
• Ваш бизнес. Вы выполняете миграцию для достижения определенных целей? Возможно, существуют бизнес-приложения, которые необходимо перенести, или особые требования нормативных актов либо соответствия к новой среде.

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

Приступаем к созданию прототипа

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

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

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

Пилотный этап

Во время проектирования нового самолета или ракеты инженеры планируют обширную программу испытательных полетов. У каждого испытательного полета есть конкретная цель, которая может быть простой (проверить выпускание и подъем шасси на разных скоростях) или сложной (маневрирование истребителей 2 на 2). Летчики-испытатели не импровизируют во время полетов, они строго следуют заданию на каждый полет, достигая поставленных целей. Ваш пилотный проект должен работать точно так же: укажите, что нужно доказать, протестировать или проверить, а затем позаботьтесь о том, чтобы все действия в пилотном проекте были ориентированы на достижение поставленной цели. Слишком часто пилотная программа на самом деле означает «выберите нескольких случайных пользователей и посмотрите, что испортится». Хорошая пилотная программа начинается со структурированного тестирования набора базовых функций - миграция одного пользователя, миграция группы пользователей, тестирование полученной в результате среды при выполнении повседневных задач, а затем переход к более сложным сценариям. Структурированное тестирование особенно важно, если вы переходите из традиционной настольной среды в «облако» или к виртуальным элементам. Потребуется время, чтобы научиться управлять «облачной» средой или гипервизором, в том числе получать поддержку поставщика в случае неполадок на пилотном этапе.

Хотя это действие не считается отдельным этапом, данный момент самый подходящий, чтобы познакомить пользователей с новой средой. Было бы прекрасно, если бы можно было развернуть новую настольную среду, не обучая пользователей, но в действительности необходимо выделить время для ознакомления пользователей с особенностями среды. Имея стабильную пилотную программу, вы можете проводить демонстрации, записывать обучающие видеофильмы или предоставить пользователям «песочницу» с ограниченным доступом к новой среде в процессе обучения. Не забудьте, что обучение, вероятно, понадобится и техникам группы поддержки. Не исключено, что потребуется дополнительный персонал, чтобы справиться с возросшим потоком запросов на обслуживание: «Не могу найти функцию X» - типичная жалоба на ранних стадиях миграции.

Развертывание

Основные события происходят на этапе полномасштабного развертывания. Этот этап миграции не сильно отличается от любого другого сложного технического проекта: вы определяете график миграции различных групп пользователей, а затем выполняете запланированные шаги, решая проблемы по мере их возникновения. Если этапы построения прототипа и пилотный проект выполнены грамотно, у вас не должно возникнуть серьезных новых проблем. Как правило, при проектировании данного этапа лучше проявлять осторожность; если вы планируете переносить 100 настольных компьютеров в неделю, а в действительности вам удается переносить 150, это лучше, чем планировать 150, а сделать 100. Не забудьте о праздниках, отпусках и других ограничениях, связанных с персоналом. Для успешного развертывания необходимо учитывать, что вы переносите среду, от которой зависит работа пользователей, поэтому делать это нужно так, чтобы они испытали как можно меньше неудобств.

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

Эксплуатация

Этап эксплуатации немного скучен, поскольку вынуждает вернуться к тому, с чего вы начали: обычной поддержке и операциям управления в стабильной среде. На данном этапе выполняется повседневная работа по обслуживанию новой среды, в том числе исправление неполадок, с которыми сталкиваются пользователи, тестирование и применение регулярных обновлений безопасности от поставщика. Пилотный этап подобен подъездной дороге к процессу миграции, а данный этап - автострада; вы без затруднений движетесь на постоянной скорости (по крайней мере, до следующего крупного обновления от Microsoft).

Упрощение процесса

Правильный выбор инструментов позволит заметно упростить пилотный этап и выпуск в производство. Пользователи должны иметь возможность работать с минимальными неудобствами, и лучший способ удовлетворить эту потребность - продуманное проектирование, миграция профиля и управляемые решения разных компаний. Например, компания Liquidware предлагает пакет Workspace Environment Management, который поможет выполнить каждый этап миграции Windows, в том числе оценку и проектирование с использованием Stratusphere, и миграцию с помощью ProfileUnity User Management. Stratusphere обнаруживает установленные и используемые приложения и помогает оценить и подготовить оборудование для Windows 10. С помощью ProfileUnity можно без проблем переносить профили пользователей между любыми версиями Windows и значительно уменьшить трудоемкость миграции. Технология Profile Bridge, применяемая в ProfileUnity, позволяет поместить профили пользователей в контейнеры и без проблем работать с ними на разных версиях Windows, совместимых как в обратном, так и в прямом направлении. Благодаря функциональности ProfileUnity сокращается время перемещения и синхронизации, и вы можете выполнять развертывание на настольных компьютерах, ноутбуках, виртуальных и «облачных» системах, чтобы обеспечить пользователям привычную среду на всех устройствах одновременно.

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

Интеграция различных информационных решений позволяет Компании:

организовать работу со всеми уровнями корпоративных данных вне зависимости от типа программных продуктов;

исключить или минимизировать дублирующий ввод информации в существующие информационные решения Компании;

организовать единое информационное пространство Компании, с четко определенными потоками информации между различными решениями, разграничением прав между пользователями.

Основным преимуществом решений по интеграции являются то, что положительный эффект от их использования Компания может получить в более коротки сроки и с меньшими затратами, чем при выборе решений, подразумевающих замену или модернизации информационных решений. Специалисты IDelync обладают большим опытом по интеграции и реализовывали проекты различных информационных систем, таких как: 1С 7.7 --> 1С 8.x; Инфобухгалтер --> 1С; Турбобухгалтер --> 1C; Парус --> 1С; StoreHouse --> 1С; R-Keeper --> 1С; Excel --> 1C.

Миграция систем на более технологичные платформы или решения осуществляется в случае, когда отдельные информационные решения устарели и перестали отвечать требованиям компании. При этом Компании необходимо осуществить переход быстро и качественно. Именно на таких – качественных и оптимальных по времени решений – специализируется IDelync. Кроме того, наша компания разработала унифицированный интегрируемый модуль для учетных систем на базе 1С:Предприятие, а именно с 1С:Предприяте 7.7 на 1С:Предприятие 8. В результате миграции Компания получает не только более современное, производительное решение, но и может автоматизировать процессы, ранее не охваченные.

Осуществлять миграцию на другие программные продукты IDelync предлагает поэтапно, проходя следующие стадии:

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

Выбор технологий для миграции IT-систем. На этом этапе осуществляется выбор и проектирование технологий для выполнения работ по миграции. В случае, если предполагается миграция с различных конфигураций 1С:Предприятие 7.7 на 1С:Предприятие 8, IDelync использует собственный, протестированный на множестве проектов модуль.

Разработка и настройка механизма миграции и его тестирование.

Осуществление миграции на новое решение, опытная эксплуатация полученной IT-системы.

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

Поддержка системы осуществляется в рамках отдельной договоренности с Заказчиком или собственной ИТ-службой Заказчика.

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

Ещё услуги (3)

Ещё решения (1)

Ещё опыт (3)

• «ID.Integration»: интегрируемый модуль обмена данными

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

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

  Интеграция – необходимость объединения нескольких отдельных систем для получения единого информационного решения и исключения необходимости многократного внесения данных в отдельные информационные базы;

  Миграция – осуществление быстрого и качественного перехода с решений любых версий системы учета на системы версии 1С:Предприятие 8.
  

  Для решения этих вопросов специалистами компании IDelync разработан универсальный интегрируемый модуль обмена данными между различными учетными программами и конфигурациями «1С:Предприятие» платформ версии 7.7 и 8.1.

  Интегрируемый модуль обеспечивает широкие возможности гибкой настройки:

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

  Синхронизацию ПС, проводок и корреспонденций – для отражения операций ведения хозяйственной деятельности.

  Использование универсального модуля обмена данными позволяет корректно решить следующие задачи:
  

  Слияние данных множества учетных баз в единую консолидированную систему.

  Трансформация проводок бухгалтерского учета как в проводки учетов других видов (Налоговый, Международный и др.), так и в проводки бухгалтерского учета с другой корреспонденцией в зависимости от объектов аналитики.

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

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

  Следует отметить, что использование модуля интеграции при переходе предприятия с систем на базе 1С 7.7 на 1С 8.1, позволяет не только качественно и быстро перенести «срез» остатков (т.е. остатки на бухгалтерских счетах на определенную дату), но и обеспечить полный перенос оборотов по счетам за любой период данных, имеющихся в текущей системе учета. Такой подход позволяет осуществить переход с одной системы учета на другую с сохранением возможности формирования регламентированной отчетности за весь отчетный период, вне зависимости от даты начала эксплуатации новой системы.

Оптовая и розничная торговля, E-Commerce

• Автоматизация управленческого учета и оптимизация бизнес-процесса реализации и логистики для ООО «Торговый Дом «Слобожанка»

  Компания ООО «Торговый Дом «Слобожанка» (далее «ТДС», «Предприятие») – импортёр и дистрибутор известных брендов косметики, средств гигиены и товаров для дома. Используя развитую структуру, ТДС продаёт оптом своим клиентам широкий выбор косметических и гигиенических товаров известных марок от производителей Польши, России, Украины, Китая.

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

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

  По результатам предварительного обследования, на основании анализа бизнес-требований Предприятия Консультант рекомендовал осуществить переход с информационной системы «Гранит» на систему ERP класса на базе 1С Предприятие 8. В качестве базового решения была выбрана конфигурация 1С «Управление производственным предприятием». В единой системе оперативного, управленческого учета реализован бизнес-процесс по управлению обслуживанием заказов покупателей, включающий в себя задачи подготовки документов, транспортной и складской логистики и контроля подтверждения отгрузки. Для оптимизации процесса приема заказов покупателей в системе реализован широкий спектр возможностей интеграции с внешними источниками (Emigo, Exite, EXCEL, КПК). В системе также реализован процесс ценообразования по брендам и клиентам, а также механизм контроля дебиторской задолженности по брендам и срокам. Внедренное решение охватывает все блоки хозяйственной деятельности Предприятия и позволяет также вести учет ОС, расчет управленческой заработной платы, управлять взаимоотношениями с клиентами (CRM) и получать финансовую отчетность за любой интересующий период (в т.ч. на ежедневной основе). В блоке финансовой отчетности реализованы следующие отчеты: Отчет о финансовых результатах, Отчет о движении денежных средств, Баланс. Единая система управленческого учета интегрирована с системами бухгалтерского учета для последующей подготовки регламентированной отчетности, осуществлена интеграция с системой «Клиент-банк».

• Техносила, Инновации и Реинжениринг для E-Commerce, Слияние Техносилы с группой Техношок

  Техносила, Москва, Россия, http://www.tehnosila.ru, один из лидеров сетевой розницы в сфере торговли электроникой и предметами бытовой техники в России. 50 регионов, 137 магазинов и интернет магазин с охватом всех регионов.

  Проекты: IT Аудит информационных систем и бизнес-окружения (SAP, 1C, PHP, FoxPro, Delphi); Управление IT Проектами и бизнес-инновациями для e-commerce направления; Реинжиниринг бизнес-процессов для e-commerce; Дизайн IT-архитектуры для e-commerce, интеграция и онлайн взаимодействие; Релизация IT-Проектов для e-commerce; Слияние Техносилы с группой Техношок, http://tshok.ru , Ст.Петербург, Россия, 16 городов, 42 магазина и интернет магазин.

• • Интеграция MS CRM (Microsoft Dynamics 4.0) и 1С.8.1 "Управление производственным предприятием" для группы интернет-компаний SUP и +SOL, Москва, Россия

    Целью данного Проекта являлись разработка и внедрение приложения, решающего задачу обмена информацией в установленном формате между специализированной информационной системой Microsoft Dynamics CRM 4.0 и УИС на базе 1С:8.1 «Управление производственным предприятием».

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

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

В данной статье мы хотели бы систематизировать наш опыт проведения миграции данных в крупных корпоративных проектах, связанных с переходом Заказчиков на работу в конфигурациях «1С:Предприятие 8».

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

Термины и определения

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

Следует отличать миграцию данных от интеграции данных. Интеграция, в отличие от миграции - это постоянная часть архитектуры IT, и ответственна за потоки данных между различными системами и хранилищами данных - и является процессом, а не деятельностью по осуществлению проекта.

Схема миграции в общем случае выглядит следующим образом:

Рис. 1

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

Система-приёмник - целевая система, произвольная конфигурация «1С:Предприятие 8».

Исходные данные - данные, выгруженные из исторических систем в произвольный формат xls -файлов. В данном случае формат xls представляется, как один из самых удобных, поскольку возможность выгрузки в xls -файл присутствует во многих учетных системах «предыдущих поколений».

Как современную альтернативу в качестве транспорта возможно рассматривать формат xml -файлов.

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

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

Данные для загрузки - данные, предназначенные для загрузки в систему-приёмник. В данной статье, так же как и исходные данные, рассматривается xls -формат.

Шаблоны данных для загрузки - описание таблиц данных для загрузки в целевую систему.

Этапы миграции

Рассмотрим поэтапно процесс подготовки и проведения миграции.

К организационным этапам миграции можно отнести следующие пункты:

· Определение стратегии миграции. На данном этапе Исполнитель и Заказчик договариваются о технологии проведения миграционных работ;

· Определение состава рабочей группы по миграции. В рабочую группу должны входить специалисты и Исполнителя и Заказчика, знакомые в достаточной степени с работой исторических систем (со стороны Заказчика) и целевой системы (со стороны Исполнителя);

· Предварительный план миграции. План миграции по ходу проекта будет неоднократно корректироваться;

· Периоды дат выгрузки данных из исторических систем, объемы данных. Периоды среза данных для миграций, даты тестовых и итоговой миграций. Данную информацию можно отнести к плану миграции;

· Состав данных, подлежащих миграции. Справочные данные, классификаторы, транзакционные данные, остатки, обороты и пр.;

· Вопросы проверки качества, корректности и целостности данных в процессе миграции и по итогам;

· Вопросы отката к предыдущему состоянию в случае сбоев.

Остановимся подробнее на технологических этапах миграции.

Рис. 2

1.Подготовка шаблонов загрузки данных

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

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

В шаблоне указывается:

· Описание всех полей xls -файла данных для загрузки, включая:

o Имя поля

o Признак обязательности заполнения поля

o Пример заполнения поля

o Примечание

· Описание правил загрузки таблицы целевой системы на основании данных для загрузки (очередность в случае нескольких связанных таблиц, алгоритмы поиска по ключевым полям и т.п.)

· Описание заполнения непосредственно полей таблиц целевой системы в случае, если предусматривается что-либо отличное от переноса данных «один в один» из файла данных для загрузки. Актуально для ссылочных полей, например.

В процессе работ по данному этапу Исполнитель также должен подготовить загрузчик файлов данных для загрузки. В случае работы с файлами xls данная задача не представляет особой сложности.

2.Выявление источников данных

Данный этап может начинаться вместе с предыдущим этапом «1. Подготовка шаблонов загрузки данных».

В рамках данного этапа специалисты Заказчика определяют из каких систем и какие данные могут быть выгружены. Также следует определить какие данные возможно могут понадобиться.

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

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

Тем не менее, на данном этапе нужно постараться выявить как можно больше необходимых данных.

3.Выгрузка исходных данных

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

Наиболее удобным вариантом представляется выгрузка в xls файлы. Многие старые IT -системы поддерживают такой вариант.

Также могут быть варианты выгрузки в csv формат, dbf , xml форматы и прочие.

Стоит отметить, что по тем или иным причинам (вопросы безопасности, например) Заказчик не всегда может предоставить выгрузки данных в полном объеме на этом этапе! Только структура данных и несколько тестовых позиций. Таким образом, может сложиться такая ситуация, что при тестовых и итоговой загрузках будут обнаруживаться некачественные данные в исходных таблицах, что будет приводить к незапланированным ошибкам.

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

4.Мэппинг данных

Мэппинг (data mapping ) - в общем случае процесс сопоставления данных исторических систем и системы-приемника. То есть, исходных данных и данных для загрузки.

Этап мэппинга - наиболее трудоёмкий этап и может занимать более 50% всех работ по задаче миграции.

На данном этапе в полной мере задействуется вся рабочая группа проекта по миграции.

В процессе мэппинга данных необходимо выделить подэтапы мэппинга таблиц и мэппинга полей.

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

· Мэппинг полей - сопоставление полей таблиц в рамках уже определенного мэппинга таблиц. Результатом данной работы является реестр мэппинга полей.

В рамках данного этапа также следует провести возможные работы по нормализации данных.

5.Подготовка правил трансформации

В отличие от предыдущих этапов, данный этап - технический и предполагает работу разработчика Исполнителя.

На основании согласованных реестров мэппинга полей специалисты Исполнителя разрабатывают правила трансформации данных.

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

При этом требования к данной среде включают в себя:

· Удобство и быстрота разработки правил трансформации;

· Скорость конвертации данных. Файлы на входе и на выходе могут быть и в сотни тысяч строк!

· Возможность работать с несколькими входными файлами одновременно;

· Возможность сохранения правил трансформации в отдельные файлы.

Для своих проектов миграции мы разработали специализированное АРМ разработчика, взяв за основу стандартную обработку «Консоль запросов» 1С.

Обработка «Консоль запросов» была доработана для возможности делать прямые запросы к файлам xls .

Приведем пример объединения двух исходных xls -файлов Сотрудники. xls

и Операции. xls со страницами:

Списания

и Поступления :

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

Технологическая последовательность операций трансформации здесь выглядит следующим образом:

С помощью языка запросов Access SQL (дающего существенные дополнительные возможности, по сравнению с языком запросов 1С) создается первоначальный запрос, извлекающий данные из файла xls в среду 1С. При этом уже на данном этапе возможны различные проверки и нормализации данных.

Технология доступа к данным ADO обеспечивает высокую скорость работы.

Рис. 3

2.Запрос на языке 1С - основной запрос, реализующий алгоритм мэппинга полей. А также: обогащение загружаемых данных данными из базы 1С, перегруппирование, объединение с результатами запросов к другим исходным xls -файлам и пр.

3.Постобработка результата запроса 1С при необходимости. Реализуется с помощью скрипта на языке 1С.

Для примера здесь реализуется добавление строки «ИТОГО» по колонкам сумм.

4.Запись итогового набора данных в xls -файл.

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

Также данный инструмент позволяет сохранять правила конвертации данных в отдельный xml файл:

Кроме того, реализована возможность работать в пакетном режиме , что особенно актуально при большом количестве разнородных мигрирующих данных.

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

Следует отметить, что перед итоговой миграцией обязательно следует провести несколько тестовых. В ходе тестовых миграций Исполнитель совместно с Заказчиков выявляют:

· ошибки конвертации, ошибки загрузки данных

· проводят предварительную оценку качества загружаемых в целевую систему данных

· по итогам тестовых миграций составляют/актуализируют план итоговой миграции

7.Выверка данных

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

· Совпадения итоговых сумм по остаткам, по документам;

· Количественные совпадения, например количество ОС;

· Корректность заполнения отдельных выборочных сущностей;

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

Например:

· Проверка на дубли по ключевым полям. Можно и нужно проводить еще на исходных данных;

· Приведение типов полей;

· Ссылочная целостность;

· Математические нестыковки. Например, проверка на незаполненные численные поля, на которые запланировано деление при трансформации;

· В целом, проверки обязательной заполненности полей;

· Замена некорректных символов. Например, английские символы в кириллических полях («о», «а», «е» и т.п.) Особенно актуально это для ключевых полей!

· Проверка значений строковых полей на соответствие типов системы-приемника (Ограничения по длине)

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

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

В некоторых случаях может происходить параллельная работа двух систем на время опытной эксплуатации (ОЭ) и даже более этого периода. Вопрос параллельной работы пользователей в двух системах тесно связан с вопросом возможности отката к старой системе, в случае если миграция (или же, в целом, работа новой системы!) будет признана неудовлетворительной.

Заключение

В заключении хотелось бы отметить, что когда речь идёт о миграции больших транзакционных систем, к которым относятся и многие конфигурации «1С:Предприятия», переход на новую систему может быть весьма трудоёмким.

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