Comment and review migration: data integrity guaranteed

Migrating comments and reviews: where data gets lost

Migrating comments almost never boils down to copying a table: a comment is not text, but a node in a graph. A post has an author, a reply has a parent, a thread has an order, a review has a link to a product or page and a moderation status.

Move the rows one by one, and the graph breaks: replies are left without parents, threads collapse into a flat list, and some messages simply disappear from the output because they lost their connection to the object.

The most common point of loss is orphaned replies. If a parent comment did not pass the filter (deleted, hidden, filtered out by date), its child messages either drop out of the migration or arrive without a link and hang at the root of the discussion.

The second is identifiers: when moving to a new schema, foreign keys are rebuilt, and without an "old id → new id" mapping, replies attach to the wrong threads.

The third is duplicates on a repeat run: without idempotency, the same review comes in twice, and that is no longer cosmetic — it means distorted ratings.

A separate category is metadata. The publication date, the "purchased/verified" flag, reaction counters, attachments, and moderator service notes often live in neighboring tables and do not make it into the export of the main array.

Comments get migrated, but time-based sorting breaks, verification marks disappear, and the client sees "fresh" reviews dated the day of the migration.

Data integrity here is verified not by the number of rows, but by the tree matching: however many root messages and replies there were, that many should remain, with the same connections.

That is exactly why review migration is built around an identifier map and control reconciliations at every step, rather than around export speed. We break down how this is covered: from inventorying the connections to rollback if the reconciliation does not add up.

How comment migration preserves data integrity

When migrating comments, the main difficulty is not in the texts themselves, but in the relationships between them.

The discussion tree is stored through "parent → reply" links: if records are imported in a single pass without first building an ID map, nested replies lose their parent and turn into a flat list.

That is why the first step is to build a mapping between old and new identifiers, and only after that do we migrate the records — the discussion hierarchy remains readable at any depth.

What is preserved during managed migration

Authorship is tied to accounts, not to free text in a name field: a guest who left a review remains a guest, and a registered user remains the owner of their record.

Timestamps are migrated in the original time zone so that the order of replies does not "shift" and the feed does not look as if the discussion ran backwards.

Moderation statuses (approved, hidden, pending review, spam) are migrated as a separate field — otherwise, after the move, hidden and rejected records surface in the public feed, and moderation has to be redone manually.

Comparison of approaches

How we verify integrity

Before publication, we compare the number of records, the nesting depth, and the distribution of statuses on the copy: a discrepancy in any of these dimensions means that some relationships have been lost.

Separately, we check that replies have not "detached" from their parents and that discussion counters match the actual number of records. Such a test run catches breaks in the hierarchy before visitors see them.

WP-CLI and similar migration tools provide step-by-step import with logging — the journal shows at which record the relationship broke, and the migration is repeated without losing what has already been loaded.

Migration stages: from audit to data handover

Moving comments is not "export a table and load it into a new database." Reviews have relationships: author, product or article, parent comment, attachments, moderation statuses, reaction counters.

If you pull them separately, some threads break off, replies dangle without parents, and counters stop matching the actual number of records. That is why we work through a fixed sequence, where each stage closes the risk of the previous one.

1. Data audit. We look at where the comments actually live: the main database, cache, external service, attachment files. We count the volume, find duplicates, broken author references, orphan comments with no link to an object. The output is a source map with the number of records for each.
2. Mapping schema. We reconcile the source and target fields: what transfers one-to-one, what requires transformation, what has no counterpart and will be dropped. We lock down the rules for dates, encodings, statuses, and attachments before the transfer begins, not along the way.
3. Transfer setup. We assemble the transfer in several passes: first parent records, then replies, then reactions and attachments. The order matters — otherwise nested threads cannot find their roots. The transfer runs against a copy, while the production database stays untouched.
4. Integrity check. We reconcile the record count for each source, verify that every reply has a parent and every comment has an author and an object. We calculate checksums on key fields and reconcile reaction counters against the actual values.
5. Test run. We transfer the entire volume to a staging environment, open a sample of threads, and inspect them by eye: nesting, order, attachment rendering, moderation behavior. We make adjustments to the mapping schema here, while the data is still untouched.
6. Data handover. We transfer to the production environment during a minimal-load window, catch up on records created during the transfer, and switch reads to the new database. The old source remains available for read-only access.
7. Acceptance and rollback. We reconcile the final metrics against the baseline and record the rollback point. If the discrepancy exceeds the agreed threshold, we revert to the previous database without data loss.

This sequence delivers a predictable result: discrepancies show up at the reconciliation stage, not after launch, when users are already writing into the new system. Describe your task — we will come back with a scope estimate and a migration plan.

How is comment migration different from review migration?

These are two different data types, and the difference is visible at the structural level. A comment is a tree node: it has a parent, nesting depth, reply order, and an attachment to a specific piece of content. A review is a flat record with a rating, "pros/cons" fields, and a verification status.

Comment migration therefore hinges on preserving hierarchy, while review migration hinges on preserving attributes and aggregates: the average score, the rating distribution, and the verified purchase counter.

Relationships are the second point of divergence. A comment references an author, a discussion object, and a parent comment; during migration it is important not to lose these references and not to create "orphans" — replies whose parent was not migrated.

A review references a product or service and an order that confirms the purchase. If the link to the order is broken, the review loses its verified status and stops counting toward the rating.

Moderation rules are migrated separately from the data itself. For comments, these are stop-word filters, auto-hiding, link limits, and manual review queues. For reviews, these are publication rules, company representative replies, and reports of inaccuracy.

These rules cannot be "derived" from old records: they must be migrated as a separate configuration, otherwise after the move some content will go live without review.

Hence the practical conclusion: comment migration and review migration are different jobs with different checks. For comments, the control is the integrity of the tree and the absence of breaks in reply chains.

For reviews, it is the completeness of attributes and the correctness of recalculated aggregates. Merging them into a single migration stream is risky: an error in one data type is masked by the success of the other, and the discrepancy surfaces only in production.

Case study: migrating 1.2 million comments without losing relationships

Before the migration, comments and reviews lived in three stores: the main forum database, a separate table for product reviews, and an external service where the oldest threads had once been moved.

The relationships between a parent comment and its reply were held together by auto-increment identifiers, which were numbered independently in each store.

During the migration this produced a classic defect — orphaned replies: a reply arrives, but the thread it belonged to stayed in the old store or got a different identifier.

The share of such replies reached 6% of the total volume, and they were only found through user complaints, after publication.

What we did

First we built a relationship map: for each entity we fixed a stable key that did not depend on insertion order, and consolidated the three sources into an intermediate schema with explicit foreign keys.

The migration ran in two passes — first the parent records, then the replies with a check that the parent was already in place. Anything that failed the check went into a quarantine table with the reason for rejection, rather than into the main database.

Metrics before and after

We reduced downtime by switching reads to the new schema before writes: for a while the application wrote to both stores, and a background catch-up process picked up the discrepancies. Rollback to the previous schema remained available until the very end of the migration window.

What we ended up with

Orphaned replies are no longer a failure class — now any broken relationship is caught during the migration and goes into quarantine with a clear reason.

Comment counters and ratings were recalculated from the new data rather than migrated as-is, so there are no discrepancies with the actual number of records.

The verification schema and key-matching rules were documented — the next migration, for example when changing stores, will follow a ready-made route.

PostgreSQL

Doubts before migration: compatibility, rollback, access

Before starting, clients most often ask the same thing: whether discussion threads will "break," whether replies nested several levels deep will be lost, and whether it's possible to return to the original state if something goes wrong after the migration.

These are healthy questions — migrating comments and reviews involves live content that can't simply be re-uploaded. That's why we lock in parent-reply relationships, authorship, timestamps, and moderation statuses, and keep the source database untouched until acceptance.

What if the discussion structure is more complex than it seems? The thread tree is expanded by parent identifiers, not by row order, so replies don't "stick" to the wrong comments. What if a migration rollback is needed?

Until integrity is confirmed, the source data remains in its original storage, and reverting takes minutes, not hours. What if access is restricted? We work through a separate user with the minimum required permissions, without exporting unnecessary personal data.

Upon completion, the client receives:

• a field mapping scheme between source and target;
• migration scripts with the ability to re-run;
• a migration rollback procedure with a step-by-step order of actions;
• an access and role matrix for working with comments;
• a reconciliation report: how many records and relationships were migrated, what was verified;
• documentation for maintenance and handover of results to the client's team.

Describe your task — we'll come back with an estimate and a plan: we'll review compatibility with your storage, the rollback procedure, and the scope of documentation to be handed over.

Timeline for migrating comments and reviews by stage

Timelines depend not on the size of the database, but on how many non-standard relationships it contains: nested replies, reactions, user mentions, links to products and orders.

That is why comment migration starts with an audit, not with an export — it is during the audit that it becomes clear where integrity is at risk.

Roughly, the entire work plan fits within two to three weeks for a medium-sized database; large forums with years of history stretch out the full migration stage, because batches take longer and require pauses so as not to overload the production server.

The order of the stages cannot be changed: a mapping schema written before the audit almost always results in lost reply threads, and a trial run on a copy is the only way to catch them before the production launch.

If the source continues to receive new comments, a change-loading step is added between the trial and full runs — otherwise some of the fresh records will remain in the old system.