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

Ответ 1

Прежде всего, перемещение систем WIN + NEW в систему CURRENT потребует времени. поэтому вам нужно убедиться, что когда вы начнете мигрировать/конвертировать все, вы знаете, куда идете. Миграция может быть непростой задачей, и вы можете столкнуться с проблемами, которые вы никогда не думали после начала процесса.

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

Плюсы:

• поддерживается только одна система: вы не хотите поддерживать 3 системы;
• один код/​​база данных environement: PHP против ASP.NET и MSSQL против MySQL;
• централизованный код/​​база данных;
• стандартный код (код и база данных);
• сохранить/продать equiments (вы перенесите код на свои 14 серверов, возможно, вам не нужны другие 9 (WIN + NEW), поэтому вы можете продать или сохранить их для следующих проектов).

минусы:

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

Это большая база данных, изменение/оптимизация которой потребует значительных инвестиций в часы работы. Это не то, что вы можете легко сделать за несколько часов. Это может занять несколько месяцев, возможно, месяцев, чтобы успешно перенести данные в систему CURRENT без ошибок. Если вы можете, вы можете начать с миграции общих или сходств из обеих схем базы данных, таких как клиенты или продукты. Таким образом, вы импортируете данные, которые система CURRENT может запускать без ошибок, а также ваш код будет распознавать. Пользователи вашей системы CURRENT могут немедленно начать управление этими элементами/отчетами без проблем. Что касается новых или записей, которые ваша система CURRENT не распознает, вы можете просто перепроектировать эти таблицы и перенести их в систему CURRENT (затем обновить текущий код).

Что касается миграции кода, если код из новой системы достаточно хорош и соответствует вашему стандарту, вы можете сохранить его. Это сэкономит время на разработку, просто убедитесь, что вы обновили запросы и соединения с серверами. С другой стороны, если он похож на код спагетти, вам нужно будет понять, что делает код. Это также может потребовать значительных инвестиций в часы работы. Я могу порекомендовать здесь стандартизировать этот вариант и упорядочить код так же, как вы его организуете на ТЕКУЩЕМ. Вы можете централизовать свой код в одной общей папке, используя общую структуру файлов и папок. Вы можете поместить все свои общие библиотеки, третьи стороны и т.д., Поэтому, когда вы вызываете код CURRENT и NEW, он загружает тот же класс PHP. Это облегчит вам переход из системы NEW в CURRENT. Таким образом, вы знаете все необходимые файлы в одном месте и очень просты в обслуживании. Особенно, если ваш код требует требуемых файлов, требующих файлов. Если вы используете код вокруг серверов, вы можете создать NFS, если вам нравится эта идея.

Теперь я могу предложить начать с Parallel Adoption. Таким образом, вы убедитесь, что все системы работают нормально и здоровы. Затем медленно переносите данные/код в систему CURRENT, пока все не будет завершено. Это будет нелегко, и вы должны определить, какую часть систем NEW + WIN вам нужно перенести в первую очередь. Моя рекомендация - мигрировать систему WIN. Поскольку это не зависит от систем CURRENT и NEW, пока вы показываете тот же результат, вы должны быть в порядке. Искать исходный код или аналогичные проверки в PHP или если вы не можете найти их, создайте их. Таким образом, эта система WIN легко переносится на вашу существующую структуру организации и стандарты кодирования. Выполнение тестов и гарантий качества будет легким, и вы можете быть завершены очень быстро.

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

Я не буду рекомендовать принятие большого удара для этого случая.

Ответ 2

Я должен мигрировать, это не ваше решение, но больше вы принимаете решение.

Для того, как это сделать, это зависит от количества данных, которые нужно выполнить. Я бы, очевидно, рекомендовал работать с SQL на SQL с помощью операторов inter-database, но это не всегда возможно.

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

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

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

Удачи.