Созданы публичный коммерческий проект bizneshelper.ru и связанный публичный концепт модернизации. Главной задачей зафиксирована миграция сайта с Ruby на haih-cms. Под неё создано дерево дочерних задач по инвентаризации, архитектуре CMS, переносу контента, URL и редиректам, формам и интеграциям, SEO, аналитике, тестированию, запуску, постмиграционной проверке и дальнейшей публичной коммерческой упаковке. Во всех сущностях используются только общие публично допустимые формулировки без внутренних коммерческих данных и секретов.

Корректировка стратегии миграции

После успешного локального запуска legacy Ruby-сайта уточнён подход к проекту. Старое Rails-приложение не рассматривается как система, которую необходимо поддерживать параллельно с новой версией. Его роль — резервная копия, источник данных и эталон для сверки.

Ключевое решение: выполнить одноразовую миграцию нужных данных и публичного контента в haih-cms, после чего новая версия становится единственным актуальным production-сайтом.

Полная обратная совместимость со всей исторической маршрутизацией не требуется. В поисковом индексе находится ограниченное число страниц — порядка 85, поэтому SEO-преемственность будет обеспечиваться точечно для реально значимых URL.

В связи с этим пересмотрены задачи по инвентаризации, модели данных, URL и редиректам, формам, SEO, тестированию и запуску. Добавлена отдельная задача по воспроизводимому импорту данных из legacy MySQL в haih-cms.

Наблюдение по текущему legacy-сайту: Mixed Content

На публичной HTTPS-странице обнаружена загрузка внешнего JavaScript-ресурса по небезопасному HTTP:

http://ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js

Современный браузер блокирует такой запрос как Mixed Content. В результате часть клиентской логики, зависящая от этого скрипта, потенциально может не работать.

Значение для проекта

Это наглядный пример того, почему даже работающий сайт нельзя считать системой, которую можно однажды запустить и затем годами не обслуживать. Внешние зависимости, браузерные требования, TLS-политики, CDN, библиотеки и стандарты безопасности со временем меняются, даже если код самого сайта остаётся неизменным.

При новой реализации на haih-cms стоит закладывать регулярную техническую проверку публичного сайта: отсутствие Mixed Content, состояние внешних зависимостей, ошибки браузера, актуальность сертификатов, корректность форм, sitemap и других критических компонентов.

Практический вывод

Legacy-сайт использовать только как источник данных и reference. В новой версии избегать жёстко зашитых небезопасных внешних URL и по возможности минимизировать зависимость от сторонних ресурсов, которые могут со временем изменить поведение или стать недоступными.

Архитектурный поворот миграции: Concepts + AI-driven content

По итогам анализа legacy БД и практики других haih-проектов зафиксирован новый основной принцип миграции: весь полезный содержательный контент старого сайта переносится в максимально унифицированную модель Concept, а специализированные legacy-таблицы и поля не воспроизводятся на новой стороне без объективной необходимости.

Главный эффект такой модели — не только упрощение схемы. После первичного импорта контент становится пригодным для единого AI-pipeline: агент может получать исходные данные старой записи и новый Concept, а затем обновлять content, структуру, форматирование, подачу и внутренние связи через один и тот же контракт.

Это напрямую связано с более общим принципом, описанным в материале «Рост производительности специалистов требует развития технологической среды бизнеса»: ускорение работы специалистов и AI даёт реальный экономический эффект только тогда, когда сама система не создаёт лишнее архитектурное трение.

Для фиксации этого подхода создан отдельный публичный кейс: Унифицированные данные как основа AI-driven проектов — кейс VietnamGuru и BiznesHelper.

Этап: сайт фактически полностью пересобран на новой системе

Основная техническая переделка bizneshelper.ru выполнена. Новый сайт собран на haih-cms и больше не зависит от необходимости воспроизводить старую Ruby-архитектуру как рабочую систему.

При этом часть оформления внутренних страниц сознательно не восстанавливалась в полном объёме. Попытка добиться точного совпадения со старым дизайном сейчас дала бы мало практической ценности: потребовала бы дополнительного времени, закрепила бы старые визуальные решения и затем только усложнила бы разработку нового дизайна.

Текущий этап проекта — не финальная визуальная полировка, а проверка того, сможет ли сайт снова выйти в поисковую видимость и вернуть органическую посещаемость, которая сейчас фактически отсутствует. Если видимость и трафик начнут восстанавливаться, визуальную часть имеет смысл развивать уже как отдельный следующий этап на новой архитектуре.

Главный ближайший приоритет смещается на работу с контентом: перенос, нормализацию, обновление, внутреннюю перелинковку, SEO и AI-driven переработку материалов.

Важный вывод по стоимости миграции

Фактически основная переделка заняла порядка 3–4 дней, но значительная часть этого времени была потрачена не на создание новой функциональности, а на обход особенностей старой технической реализации. Legacy-сайт оказался существенно сложнее в переносе, чем должен был быть при сопоставимом объёме контента.

Основные источники лишней сложности:

• слишком большое количество специализированных сущностей и таблиц;
• разные модели хранения для похожих по сути видов контента;
• отдельная логика представления для разных сущностей;
• собственный CSS у многих типов страниц и компонентов;
• накопленные особенности WYSIWYG/HTML, которые приходилось нормализовать при импорте;
• высокая связанность структуры данных с конкретными старыми шаблонами.

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

С точки зрения проекта результат важен именно этим: несмотря на плохое внутреннее состояние legacy, новая версия была собрана за несколько дней, а дальнейшее развитие теперь можно вести уже поверх значительно более простой и AI-дружелюбной среды.