A Dry Run for Renaming Product Categories Without Moving Products

Renaming a category sounds harmless. Yet a bulk edit that mixes new names with changed parents, merged duplicates or reassigned products can quietly change what shoppers see under each heading. This article proposes a dry run you could use to preview label-only edits separately from membership changes. It is a design suggestion, not a description of any particular platform.

Separate the two kinds of change

A label change alters only display text, and possibly the web address built from it. A membership change alters which products sit in a category, or where the category sits in the tree. Put them in two different lists and never approve them together. If your request contains both, split it first.

The label-change preview

Build a table with one row per category:

category_id: the stable identifier, never the name
current_label
proposed_label
parent_id before and after
product_count before and after
product ID list fingerprint before and after (for example a sorted list of IDs, or a hash of it)
address_changes: yes, no, or unknown
classification: label-only, or membership change

Fill the before columns from the live data. Fill the after columns from a copy of the data with the edit applied, never from the live data. The dry run is the comparison between the two.

The invariants checklist

For every row classified as label-only, all of these should hold:

category_id unchanged.
parent_id unchanged.
Product count unchanged.
Product ID fingerprint unchanged.
Sort position among siblings unchanged, unless stated.
Proposed label is not identical to a sibling label, ignoring case and surrounding spaces.
If the address changes, an old-to-new redirect decision has been made.

One failed invariant moves the row out of the label-only list. It is not rejected, only reclassified for separate review.

Branching choices

If the edit would change addresses, decide whether the old address keeps working. If you cannot say, mark unknown and stop that row. If two categories would end up with the same label, decide whether this is a deliberate merge, which is a membership change, or a typing mistake. If the new label is longer, check the menu and filter layouts in the preview, since long names can wrap or truncate.

Hypothetical worked example

A small shop proposes three edits. Category 14 changes from Mugs to Mugs and Cups. Category 22 changes from Tea to Loose Tea. Category 31 changes from Gifts to Gift Sets, and its parent changes at the same time.

The dry run shows categories 14 and 22 with identical counts and fingerprints, so both pass and are labelled label-only. Category 31 fails invariant 2 because its parent differs. It is reclassified as a membership change and withdrawn from this batch. Category 22 shows address_changes as yes, so the team records a redirect decision before approving it.

Stop conditions

Stop the whole run if any category_id in the request is missing from the live data, if the before counts do not match what the live catalogue reports at the moment of review, or if the dry run copy cannot be shown to be a faithful snapshot. Stop a row if its address behaviour is unknown.

Acceptance checks

Every approved row has all seven invariants ticked, with the before and after values visible.
No row appears in both lists.
After the real edit, recompute counts and fingerprints and compare them with the preview; any difference triggers a review of that row.
Spot-check three categories by opening them as a shopper would.
Keep the preview table with the change record so the old labels can be restored.

The point of the dry run is simple. A rename should leave every product where it was, and the table gives you a way to check that claim before and after the edit.