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

Question

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

Удачи!