Перенос контента - Content migration

Перенос контента это процесс перемещения информации, хранящейся на Система управления веб-контентом (CMS), Управление цифровыми активами (DAM), Система управления документами (DMS) или плоскую систему на основе HTML в новую систему. Плоский HTML-контент может включать в себя HTML-файлы, Активные серверные страницы (ASP), JavaServer Pages (JSP), PHP, или контент, хранящийся в каком-либо типе HTML /JavaScript на основе системы и может иметь статическое или динамическое содержимое.

Драйверы бизнеса

Причины рассмотреть возможность переноса контента

Content Migrations может решить ряд проблем, начиная от:

  • Объединение одной или нескольких систем CMS в меньшее количество систем. Это обеспечивает более централизованный контроль, управление контентом, а также лучшее управление знаниями и обмен ими.
  • Реорганизация контента в результате слияний и поглощений для ассимиляции как можно большего количества контента из исходных систем для единого внешнего вида.
  • Преобразование органически выросшего контента в CMS или Flat HTML и стандартизация форматирования, чтобы стандарты можно было применять для единого брендинга контента.
  • Сложные пути обновления с неподдерживаемых версий можно упростить, перенеся содержимое на более новую версию платформы.
  • Требования соответствия могут потребовать дополнительных функций от базового хранилища, примерами могут быть необходимость аудита доступа к контенту, повышение безопасности или управление записями.

Аргументы против переноса контента

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

Еще одна распространенная проблема миграции контента - это потеря SEO и рейтинга страницы в поисковых системах. Переход в другое место и внедрение нового программного обеспечения означает, что весь веб-сайт URL-адреса тоже будут изменены,[1] следовательно, поисковым системам придется внести некоторые коррективы, даже если они будут проинформированы о процессе. В белой книге Oracle также обозначил несколько вопросов, связанных с так называемой перспективой людей. В нем указывается на вероятность того, что люди, участвующие в миграции контента, могут не иметь полного представления об истории, структуре и значении исходных данных, а также новой системы, что может привести не только к потере информации, но и повлечет за собой дополнительные Ресурсы.[2]

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

Подходы

Есть много способов получить доступ к контенту, хранящемуся в CMS. В зависимости от поставщика CMS они предлагают либо Интерфейс прикладного программирования (API), Веб-сервисы, восстанавливая запись, записывая SQL запросы, XML экспорт или через веб-интерфейс.

  1. API[5] требует, чтобы разработчик прочитал и понял, как взаимодействовать с уровнем API исходной CMS, а затем разработать приложение, которое извлекает контент и сохраняет его в базе данных, XML-файле или Excel. После извлечения содержимого разработчик должен прочитать и понять целевой API CMS и разработать код для переноса содержимого в новую систему. То же самое можно сказать и о веб-сервисах.
  2. Большинство CMS используют базу данных для хранения и связывания контента, поэтому, если API не существует, программист должен реконструировать структуру таблицы. После обратного проектирования структуры пишутся очень сложные SQL-запросы для извлечения всего содержимого из нескольких таблиц в промежуточную таблицу или в какой-либо тип таблицы. Значения, разделенные запятыми (CSV) или XML-файл. Как только у разработчика есть файлы или база данных, разработчик должен прочитать и понять целевой CMS API и разработать код для передачи контента в новую систему. То же самое можно сказать и о веб-сервисах.
  3. Экспорт XML создает XML-файлы содержимого, хранящегося в CMS, но после экспорта файлов их необходимо изменить, чтобы они соответствовали новой схеме целевой системы CMS. Обычно это делается разработчиком путем написания кода для преобразования.
  4. Файлы HTML, JSP, ASP, PHP или другие форматы файлов сервера приложений являются наиболее сложными. Структура файлов Flat HTML основана на кульминации структуры папок, файловой структуры HTML и местоположения изображений. В первые дни миграции контента разработчику приходилось использовать языки программирования для анализа файлов HTML и сохранения их в виде структурированной базы данных, XML или CSV. Обычно PERL, JAVA, C ++ или C # использовались из-за возможности обработки регулярных выражений. JSP, ASP, PHP, ColdFusion и другие технологии сервера приложений обычно полагаются на включения на стороне сервера, чтобы упростить разработку, но очень затрудняет перенос контента, поскольку контент не собирается, пока пользователь не просмотрит его в своем веб-браузере. Из-за этого очень сложно просматривать файлы и извлекать содержимое из файловой структуры.
  5. Веб-парсинг позволяет пользователям получать доступ к большей части контента непосредственно из пользовательского веб-интерфейса. Поскольку веб-интерфейс является визуальным (это и есть суть CMS), некоторые веб-парсеры используют пользовательский интерфейс для извлечения контента и размещения его в такой структуре, как форматы базы данных, XML или CSV. Все CMS, DAM и DMS используют веб-интерфейсы, поэтому извлечение контента для одного или нескольких исходных сайтов - это в основном один и тот же процесс. В некоторых случаях можно отправить контент в новую CMS с помощью веб-интерфейса, но некоторые CMS используют апплеты JAVA или Active X Control, которые не поддерживаются большинством веб-скребков. В этом случае разработчик должен прочитать и понять целевой API CMS и разработать код для передачи контента в новую Систему. То же самое можно сказать и о веб-сервисах.

Основной поток миграции контента

  1. Сделайте инвентаризацию содержания.
  2. Получите перечень двоичного содержимого, такого как изображения, PDF-файлы, файлы CSS, документы Office, Flash и любые двоичные объекты.
  3. Найдите неработающие ссылки в контенте или ресурсах контента.
  4. Определите структуру меню содержимого.
  5. Найдите родительскую / родственную связь с контентом, чтобы ссылки на другой контент и ресурсы не разрывались при их перемещении.
  6. Извлеките ресурсы со страниц и сохраните их в базе данных или файловой структуре. Сохраните ссылку в базе данных или в файле.
  7. Извлеките содержимое HTML с сайта и храните локально.
  8. Загрузите ресурсы в новую CMS с помощью API или веб-интерфейса и сохраните новое местоположение в базе данных или XML.
  9. Преобразуйте HTML в соответствии с новыми стандартами CMS и повторно подключите любые ресурсы.
  10. Загрузите преобразованный контент в новую систему.

От старого к новому

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

Рекомендации

  1. ^ «5 основных рисков, которые мешают вам перейти на сайт и их решения». CMS2CMS. 2016-06-09. Получено 2018-09-04.
  2. ^ Oracle (октябрь 2011 г.). «Успешная миграция данных» (PDF). Oracle. Получено 4 сентября, 2018.
  3. ^ TAHO (сентябрь 2015 г.). "Консультации по управлению информацией 60, часть 5 Успешное управление информационными рисками во время миграции системы" (PDF). Правительство Тасмании. Получено 4 сентября, 2018.
  4. ^ Санчес-Алонсо, Сальвадор; Афанасиадис, Иоаннис (2010). Метаданные и семантические исследования. Берлин: Springer. п. 28. ISBN  9783642165511.
  5. ^ Чем не являются API переноса контента

внешняя ссылка