Initial Technical Inventory of the Legacy Site

Initial documentation on the current implementation of bizneshelper.ru has been received.

Confirmed Stack

• Ruby on Rails 3.2.21 — legacy framework version.
• Ruby is not explicitly pinned; a compatible range of older Ruby versions is assumed for the project, roughly 1.9.3–2.2.x. For local reproduction, Ruby 2.2.10 seems like a reasonable starting point, but compatibility must be confirmed by actual execution.
• MySQL via mysql2 ~> 0.3.11.
• Bundler 1.15.4.
• A separate Solr environment is used for full-text search via sunspot_rails / sunspot_solr.

Key Dependencies

• devise — authentication, including administrative access.
• ckeditor — content editing.
• paperclip ~> 3.0 — handling uploaded files and images.
• friendly_id ~> 4.0.9 — human-readable URLs; critical for analyzing current routes and preserving URLs during migration.
• sunspot_rails, sunspot_solr — search; Solr will be required to fully reproduce legacy behavior.
• omniauth and social media providers — historical OAuth scenarios; the relevance of each provider must be checked individually.
• will_paginate, simple_form — pagination and forms.

Data and File Structure

• db/ contains 77 migrations, schema.rb, and seeds.rb; this is an important source for restoring the actual data model and its development history.
• files/ contains about 1,320 items; this directory must be mapped separately against Paperclip models and public media URLs.
• public_html/ contains static assets that must be distinguished from Rails-generated pages when preparing the migration map.
• solr/ contains search configuration and must be accounted for when inventorying search functionality.

Public Features

• The admin interface is available at /admin and uses Devise.
• The default locale is Russian (config.i18n.default_locale = :ru).

Major Technical Risks

1. The stack is significantly outdated, so running it locally on a modern system may require a separate legacy environment or containerization.
2. therubyracer / libv8 are potentially problematic when building on modern OSs.
3. mysql2 ~> 0.3.11 may be incompatible with current MySQL client libraries without additional measures.
4. Full reproduction of search will require Solr; without it, the site may boot, but one of the user scenarios will be incomplete.
5. friendly_id must be investigated before designing haih-cms routes, as current slugs and URL rules may be part of accumulated SEO value.
6. Paperclip and the files/ directory require separate verification: we need to understand the path scheme, model bindings, and the proportion of actually used files.
7. OAuth providers belong to legacy integrations; some of them may be non-functional or unnecessary in the new version, so they should not be automatically migrated as mandatory functionality.

What to Check Next

• The actual Ruby version via lock/config/deploy files or a successful local boot.
• Gemfile.lock and exact versions of all gems.
• schema.rb and Rails models: composition of entities, associations, and Paperclip attachment fields.
• routes.rb: actual public routes, /admin, friendly_id, and legacy redirects.
• Controllers and views: actual types of public pages.
• The relationship between files in files/ and DB records.
• The use of Solr in user scenarios.
• The actual relevance of OAuth and other external integrations.

Conclusion

The project is a classic Rails 3.2 legacy monolith with separate subsystems for file storage and Solr search. For migration to haih-cms, it is critical to first reproduce the current data model, routes, and media associations, and then migrate content and functionality. Attempting to treat the site merely as a set of HTML pages will result in the loss of a significant portion of the legacy system's logic.

Clarification on Local Run Results

The local deployment of the legacy site has been successfully completed, which has made it possible to confirm some previously speculative data.

Confirmed

• The original server environment used Ruby 2.2.5 via Passenger.
• Rails 3.2.21 is compatible with running in a container on Ruby 2.2.10.
• The legacy application uses MySQL via a network connection when the host is explicitly specified.
• A newer ckeditor branch is incompatible with Rails 3.2; the working option requires pinning a compatible 4.0.x version.
• The project contains directories and files typical of Rails 5 (app/channels, app/jobs), although the main application remains Rails 3.2. This is important to consider when analyzing the source code structure: not all files in the project tree are part of the actually working legacy runtime.

Conclusion for Inventory

The project can now be explored not only statically through code and dumps, but also dynamically via a locally running copy. This allows models, routes, and content to be cross-checked against the actual behavior of the site and reduces the risk of erroneously migrating unused or historically left-over components.

The next priority is to go through public routes, check media links, search, forms, and the administrative section, comparing the observed behavior with routes.rb, models, and the DB schema.

Adjusting Inventory Boundaries

Full reverse engineering of the Ruby application is no longer the goal. The inventory must answer a practical question: which entities, fields, media, URLs, and user scenarios are actually needed for the new website and data migration.

The legacy site is used as a reference and backup. Unused parts of the old code and historical routes are only investigated if they affect data or public functionality that needs to be migrated.

Conclusion on the Internal Quality of the Legacy Website

When studying the data structure, it became noticeable that the external state of the website can greatly underestimate the real complexity of the project. To the end user, a page might look completely normal, but under the hood, content may be distributed across illogical tables and fields, and semantically identical data may be stored in different places.

A characteristic example: the main content of a regular page is stored in the description field, while the content of the main page is located within the system settings of the website. Such a structure is not obvious without studying the source code and the actual behavior of the application.

Why This Matters

Poor internal organization affects more than just maintenance costs. It affects the very willingness of the developer or owner to continue working with the website. If even a simple content change requires remembering non-standard data storage locations, legacy code features, and exceptions to the general logic, every change becomes more unpleasant and expensive.

Over time, this often leads to the website being touched less and less often, then technical updates being postponed, and eventually the project effectively becoming abandoned, even though it outwardly continues to function.

Conclusion for the New Implementation

Convenient and predictable content management mechanics are not a decorative CMS improvement, but an essential part of the website's viability. The new implementation should reduce the cost of everyday changes and make the data structure understandable without the need to investigate the internals of the system every time.

A good website should not only be convenient for the visitor, but also cause no resistance for those who maintain and populate it.