Task: Design and execute data import from legacy DB to haih-cms
Design and execute data import from legacy DB to haih-cms
Prepare a reproducible, one-time import of required data from the legacy MySQL project into the target haih-cms model.
Objective
Perform a controlled and verifiable migration of structured data from legacy MySQL to the new haih-cms model. This is a separate technical phase independent of the further operation of the Ruby application.
What to do
- Based on the inventory and target model, determine the tables, fields, and relations involved in the import.
- Prepare the legacy → haih-cms mapping.
- Define conversion rules for slugs, dates, statuses, HTML content, and relations.
- Prepare the import so it can be re-run on a test environment without manually editing each record.
- Handle duplicates, missing relations, and invalid legacy values.
- Separately link record import with the subsequent migration of media.
- After the import, generate a count reconciliation and a spot check of the content.
Result
A reproducible import transfers a consistent set of data from legacy MySQL to haih-cms with a clear report on skipped or transformed records.
Definition of Done
- Mapping of source and target entities is documented.
- Import runs independently of any running Ruby application.
- Necessary relations and significant fields are preserved.
- Repeated test runs are predictable.
- Completeness check and an exception list are available.
Constraints
Dumps, credentials, personal data, and other sensitive information from the source DB are not published in this open task.
Ворклоги
Progress: import approach confirmed via collapsing legacy fields
The target pattern is already practically implemented for the admin_experiences import: multiple specialized fields of the old record (customer, problem, solution, result, review, comment, etc.) are used as source data, but are not converted into identical fields of the new schema. Instead, they are compiled into a single primary Concept content.
The historical URL is served by a separate RedirectRule when necessary, meaning route compatibility does not pollute the content model.
The next stage is to apply the same principle to the remaining content legacy tables and then launch a separate AI-driven process to refine the created Concepts.