Commerce Catalog Migration

MY CONTRIBUTION

My responsibility wasn’t simply moving catalog data from one system to another. I was responsible for understanding and protecting the commerce experiences that already depended on the old catalog. That meant tracing existing features and dependencies, identifying what would be affected by the migration, and coordinating changes across the teams responsible for the surrounding products. Some dependencies only required adapting to a new source. Others needed different mappings or behavior. A few exposed assumptions that had quietly become part of the existing product over the years. I worked closely with a junior Product Manager from the internal apps team who focused on the new catalog platform, while I focused more heavily on the commerce side: what depended on the catalog, what needed to change, what needed to be rebuilt, and most importantly, what customers should never notice had changed at all.

PROBLEM

The biggest risk wasn’t losing 80,000 products. It was discovering too late that something else had quietly depended on the old catalog. Over the years, the legacy platform had become connected to many parts of the commerce experience. Some relationships were obvious and documented. Others existed mostly because the system had behaved that way for years. This meant we couldn’t rely on a clean specification describing everything that needed to migrate. We had to reconstruct that understanding ourselves. And replacing the source wasn’t always enough. Some integrations behaved differently. Some expected different information. Some frontend and backend behaviors had grown around assumptions from the legacy system. Some capabilities available in the old environment didn’t yet exist in the new one. The migration therefore became less about transferring products and more about uncovering hidden dependencies before they became production issues.

OUTCOME

After roughly six months of discovery, mapping, redevelopment, testing, and coordination across multiple teams, the catalog migration was completed with around 80,000 products moved to the new internally managed platform. The customer-facing commerce experience continued operating with minimal disruption while the underlying catalog foundation changed. More importantly, the migration gave us a much clearer understanding of dependencies that had accumulated around the legacy system. Once the new platform stabilized, that understanding also gave us an opportunity to revisit several legacy behaviors and gradually simplify implementations that no longer made sense.

IMPACT

This project changed how I think about migrations. Before this, I mostly saw migration as moving something from an old system to a new one. Now I see it more as an exercise in discovering everything people have forgotten the old system was responsible for. The data is often the visible part. The real risk lives in dependencies, assumptions, edge cases, and years of behavior that have quietly become part of the product. It also taught me that migration isn’t finished when the cutover succeeds. A new system needs to become understandable to the people operating it before it can genuinely replace the old one.