Task: Migration of bizneshelper.ru from Ruby to haih-cms
Migration of bizneshelper.ru from Ruby to haih-cms
Main project objective: migration of the existing website to haih-cms.
Migration of bizneshelper.ru from Ruby to haih-cms
Main project objective.
The goal is to migrate the public website from the existing Ruby implementation to haih-cms while preserving significant content, core user scenarios, material accessibility, and search engine compatibility.
All sub-tasks must contain only publicly acceptable wording and exclude internal commercial data, access credentials, secrets, or personal information.
Ворклоги
The public commercial project bizneshelper.ru and an associated public modernization concept have been created. The main task is defined as migrating the website from Ruby to haih-cms. A tree of subtasks has been created for this, covering inventory, CMS architecture, content migration, URLs and redirects, forms and integrations, SEO, analytics, testing, launch, post-migration verification, and further public commercial packaging. All entities use only general, publicly permissible formulations without internal commercial data and secrets.
Adjusting the Migration Strategy
Following the successful local launch of the legacy Ruby site, the project approach has been refined. The old Rails application is no longer viewed as a system that needs to be maintained in parallel with the new version. Its role is strictly that of a backup, a data source, and a reference for verification.
Key decision: perform a one-time migration of necessary data and public content into haih-cms, after which the new version becomes the sole active production site.
Full backward compatibility with all historical routing is not required. The search index contains a limited number of pages—around 85—so SEO continuity will be handled on a case-by-case basis only for genuinely significant URLs.
Consequently, tasks related to inventory, data models, URLs and redirects, forms, SEO, testing, and launch have been revised. A separate task has been added for reproducible data import from the legacy MySQL into haih-cms.
Observation on the Current Legacy Site: Mixed Content
An external JavaScript resource is being loaded via insecure HTTP on a public HTTPS page:
http://ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js
Modern browsers block such requests as Mixed Content. As a result, part of the client-side logic that depends on this script may potentially fail to work.
Significance for the Project
This is a clear example of why even a working website cannot be considered a system that can be launched once and left unmaintained for years. External dependencies, browser requirements, TLS policies, CDNs, libraries, and security standards change over time, even if the website's own code remains unchanged.
During the new implementation on haih-cms, regular technical audits of the public site should be planned: the absence of Mixed Content, the state of external dependencies, browser errors, certificate validity, form correctness, sitemaps, and other critical components.
Practical Conclusion
Use the legacy site solely as a data source and reference. In the new version, avoid hardcoded insecure external URLs and, whenever possible, minimize dependency on third-party resources that may change behavior over time or become unavailable.
Architectural Pivot of Migration: Concepts + AI-driven content
Following the analysis of the legacy database and the practices of other haih projects, a new core migration principle has been established: all useful, meaningful content from the old site is transferred into a maximally unified Concept model, while specialized legacy tables and fields are not replicated on the new side without an objective necessity.
The main effect of such a model is not just schema simplification. After the initial import, the content becomes suitable for a unified AI pipeline: an agent can receive the source data of the old record and the new Concept, and then update content, structure, formatting, presentation, and internal links through the exact same contract.
This is directly related to a broader principle described in the article "Growth of Specialist Productivity Requires the Development of the Business Technological Environment": accelerating the work of specialists and AI provides a real economic effect only when the system itself does not create unnecessary architectural friction.
To formalize this approach, a separate public case study has been created: Unified Data as the Basis for AI-driven Projects — The VietnamGuru and BiznesHelper Case Study.
Stage: The website has been essentially completely rebuilt on the new system
The main technical overhaul of bizneshelper.ru is complete. The new website is built on haih-cms and no longer depends on having to replicate the old Ruby architecture as a working system.
At the same time, some of the internal page styling was intentionally not fully restored. Trying to achieve an exact match with the old design would offer little practical value at this point: it would require extra time, lock in old visual solutions, and ultimately only complicate the development of a new design.
The current stage of the project is not about final visual polishing, but about testing whether the website can re-enter search visibility and recover organic traffic, which is currently virtually non-existent. If visibility and traffic begin to recover, it will make sense to develop the visual part as a separate next stage on the new architecture.
The main immediate priority shifts to working with content: migration, normalization, updating, internal linking, SEO, and AI-driven processing of materials.
Important conclusion regarding migration costs
In practice, the main overhaul took about 3–4 days, but a significant portion of this time was spent not on creating new functionality, but on bypassing the quirks of the old technical implementation. The legacy site turned out to be significantly more difficult to migrate than it should have been for a comparable volume of content.
The main sources of unnecessary complexity:
- too many specialized entities and tables;
- different storage models for essentially similar types of content;
- separate presentation logic for different entities;
- custom CSS for many page types and components;
- accumulated WYSIWYG/HTML quirks that had to be normalized during import;
- high coupling between the data structure and specific old templates.
This is practical confirmation of the adopted architectural decision: unifying content entities around Concept is not for the sake of abstract schema neatness, but so that future changes do not require going through such a volume of special-case logic again.
From the project's perspective, this is precisely why the result is important: despite the poor internal state of the legacy system, the new version was assembled in just a few days, and future development can now proceed on top of a significantly simpler and AI-friendly environment.