Помощь с оценкой миграции данных

Question

Наш клиент имеет полностью настраиваемую CMS, которая была построена в ASP 1.1, а затем обновлена ​​до 2.0. В базе данных более 200 таблиц, и, к сожалению, нет никакой документации ни для ASP-кода, ни для базы данных. Оригинальные разработчики недоступны для опроса, и никто в моей компании не знаком с настройкой.

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

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

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

Answer 1

Чтобы начать с плохих новостей: возможно, нет. (Я не думаю, что 3 календарных недели: не более 140 человеко-часов распространяются в течение более длительного периода).

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

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

Что касается стратегии: я бы определил 80% общей функциональности, которая лежит в основе каждой системы и потребует всего 20% усилий для преобразования. У вас есть код и db: поместите его на тестовый сервер и позвольте нескольким пользователям выполнить общие действия. Поместите трассировку/запись в свой код и посмотрите, что попало. Поместите столбцы временной отметки или контрольный журнал на свои таблицы и посмотрите, какие изменения в вашем db.

Удачи вам!

Answer 2

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

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

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

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