Ожидайте, что вам придется как обрабатывать, так и обрабатывать данные вручную, что бы ни случилось. С самого начала признайте, что ваши данные, вероятно, будут в худшем состоянии, чем вы думаете: поля будут использованы не по назначению; ссылки «запись-запись» (внешние ключи) могут быть реализованы неправильно или вообще не реализованы; контент может нуждаться в прополке и иногда быть просто плохим или неправильным.
Проверьте кодировку базы данных. Старые базы данных не будут в Unicode-кодировках и будут раздражительными, если вам придется экспортировать дампы данных и импортировать их в другое место. Даже тогда предположим, что в ваших данных будут какие-то дурацкие непечатаемые символы: программы вроде Word, кажется, каким-то образом внедряют их повсюду, и я видел ... кодовые точки ... вы, люди, не поверите. Рассмотрите возможность очистки ваших данных до того, как вы начнете (или даже очистите дамп базы данных) для этих символов. Решите, следует ли их отбрасывать или попытаться преобразовать в случае, например, Слово «умные» знаки препинания.
Очень сложно создать явные структуры данных из подразумеваемой. Если ваши входящие данные имеют отдельное поле даты, вы можете сопоставить это с полем даты; если она содержит часть большого фрагмента HTML, даже если эта дата находится в теге с атрибутом id, простой сценарий не будет работать. Вы можете использовать автономные сценарии с BeautifulSoup или (если ваш HTML немного лучше) для более быстрой lxml предварительной обработки набора данных, извлечения этих неявных полей и сохранения их в неявном формате. Подумайте о создании промежуточной базы данных, куда пойдут эти ревизии.
Модуль Migrate превосходен, но чтобы получить действительно хорошую достоверность данных и использовать более хитрые уловки, вам может понадобиться узнать о его системе хуков (терминология Drupal для функций, следующих определенной схеме именования) и основах написания модуль для установки этих хуков (в общем случае модуль - это просто файл PHP, в котором все функции начинаются с одного и того же текста, имени файла модуля.)
Весь импортируемый контент должен быть помечен как минимум для краткой проверки. Вы можете сделать это, импортировав его с status = 0, то есть неопубликованным, а затем создать представление с помощью модуля Views, чтобы просмотреть содержимое и открыть его на других вкладках для проверки. Операции массового просмотра позволяют вам иметь набор флажков рядом с вашими элементами просмотра, чтобы вы могли утверждать сразу несколько узлов.
Ожидайте запуска, повторного запуска и повторного запуска импорта, каждый раз исправляя новые вещи. Проверьте десять или двадцать пунктов как можно раньше. Если есть какие-либо проблемы, проверьте еще десять или двадцать. Исправьте и повторите импорт.
Определите, сколько времени может занять один запуск импорта. Будьте пессимистичны: у нас был импорт, который мы ожидали занять десять часов, столкнулись с экспоненциальным замедлением, когда мы представили полный набор данных; пока мы, наконец, не исправили некоторые медленные запросы, это, по прогнозам, заняло бы две недели.
Если вы сомневаетесь, или если вы думаете, что технические аспекты вышеупомянутого просто займут больше времени, чем сама работа, тогда просто наймите временных для обработки данных. Но вам все равно нужны достойные средства контроля качества, как можно раньше во время их работы. Разработчики Drupal также нанимаются: попробуйте соответствующий IRC-канал вашей страны или разместите заметку в соответствующей группе groups.drupal.org. Они дороже, чем временные, но обычно пишут лучше на PHP ...! Также подумайте о найме агентства: это бесстыдная вилка, так как я работаю на нее, но иногда лучше привлекать специалистов для этих конкретных работ.
Действительно хороший импорт всегда труден, сложнее, чем вы ожидаете. Не позволяйте этому сбить вас с толку!