A ground-up database and front-end rebuild that became the foundational data architecture for the Amazon–Whole Foods item catalog integration — and for other teams' own modernization work.
ICON, Whole Foods' system of record for item and pricing data, underwent a ground-up database and data architecture upgrade — introducing two new item-grouping concepts, SKU and Price Line, as new hierarchy types. This wasn't a lift-and-shift: it meant standing up a new MSSQL database, building an ETL pipeline to migrate data from the legacy schema, and rebuilding the front end in React to manage the new grouping model. This upgrade was the foundational architecture and it became the base other initiatives were built on, including the Amazon item-catalog integration and, separately, the data warehouse team's own migration from Teradata to Amazon Redshift.
I managed the program as Project Manager — aligning development timelines and coordinating QA across every parallel track — and I personally ran go-live itself, along with the cutover runbook. The data-model architecture belonged to a solution architect; building the database, migration, and front-end work into a program that landed safely across 17 systems belonged to me.
Two new hierarchy types, modeled and published
SKU and Price Line were implemented as new single-level Hierarchy Types in ICON, each with system-generated sequential IDs. Once created, groupings were published downstream via the enterprise service bus's global item and hierarchy messages, plus batch exports — the same mechanism ICON already used for its existing hierarchy concepts, extended to cover two new ones.
Groupings created on the fly
Unlike ICON's existing hierarchy concepts (e.g., Brand), SKU and Price Line groupings didn't need to be pre-defined before an item could be assigned to one — a grouping could be created dynamically at the moment an item was created.
Primary-item flagging for downstream consumers
Each grouping required one item flagged "primary" — the reference record that catalog integrations like Amazon's would key off of, and that pricing systems would aggregate around.
New database, migration, and front end — built together
Supporting the new hierarchy types required a new MSSQL database, an ETL pipeline to migrate data out of the legacy schema, and a React rebuild of the front end used to manage groupings. None of these could ship independently — the data model, the migration, and the UI all had to land in the same release.
That flexibility was the point of the design, but it meant 17 systems now depended on data that could appear unpredictably rather than on a fixed schedule — exactly the kind of decision that raises the integration-testing bar. It also gave other teams a foundation to build on: the data warehouse team used this new model as the basis for migrating their own analytics environment from Teradata to Amazon Redshift.
Standing up a new database, migrating into it, and rebuilding the front end all in the same release didn't leave much room for testing surprises — and integration testing at this scale surfaced a few. Early on, the QA environment drifted from the production build it was meant to mirror, which meant some of that testing wasn't fully representative of the real cutover. Later, cutover rehearsals surfaced sequencing issues in the migration steps themselves, and a downstream team submitted a change request that needed approval before testing could close out.
None of these were architecture flaws — they were the kind of integration risk you'd expect when a new database, a data migration, and a UI rebuild all have to land together while 17 downstream systems adjust to the new model at the same time. Rather than hold the original go-live date and absorb that risk, I built in an additional cutover rehearsal to re-validate the corrected sequencing before committing to go-live.