Westrow brokers perishable food into every major Canadian retailer. We rebuilt the system that connects their client, their retail customers, and every product spec in between, retiring a legacy database and a wall of spreadsheets for a single source of truth.
One platform now connects 135 clients, 165 retail customers, and every product spec in between — entered once, accurate everywhere.
Westrow sits between food Clients and Canada's largest retailers. Every product carries dozens of moving details: case pack, package size, barcodes, compliance memberships, sales terms, lead times by province, ship to depots. That detail lived split across a legacy MySQL system and a wall of spreadsheets, re keyed by hand at every handoff. A stale or dropped detail isn't a typo here. It's a rejected order, a compliance gap, or margin quietly leaking.
Three pain points
Detail split
across a legacy DB and spreadsheets, re keyed at every handoff
No single source of truth
for any client, customer or item
Errors surface downstream
rejected orders, compliance gaps, margin leak
We didn't digitise the old forms. We modelled the business the way it actually runs. Three connected records: the Clients Westrow represents (clients), the retailers they sell into (customers), and the items that link the two, each carrying its own packaging, codes and ship to detail. Onboard a client once, and every customer, item and sales term hangs off that one record. Enter a detail once and it's right everywhere.
A clean platform from scratch was the easy half. Built ground up on a new stack with no existing codebase to lean on. The real work was getting fifteen plus years of legacy data, much of it free typed and inconsistent, to land cleanly in a normalised system without losing a record.
Migration pipeline
Extract
(pull from legacy MySQL)
Clean
(normalise phones, postal codes, free text)
Transform
(map to PostgreSQL schema)
Load
(with exception capture)
Audit
(exported exception reports)
Re runnable
(safely reprocess failures)
Migrating MySQL to PostgreSQL was the hard part. Legacy data was inconsistent and free typed: invalid phone numbers and postal codes, mixed values in single fields, non standard quantities like "1 pail" or "6x2", missing or duplicate identifiers. We built a custom ETL and data cleaning layer plus an exception reporting system to track and fix every failed record. A production incident on the first deployment reshaped the migration strategy and made it far more robust.
We kept scope deliberately tight.
Where preserving the legacy mess fought clean data, we chose normalisation.
Migration correctness. Data this inconsistent broke automated checks, so we leaned on custom audit reports of exported exceptions, manual verification of edge cases, and re runnable scripts. The second front was safe production deployment of the migration steps: health checks and rollback readiness validated before every cut over.
Run the whole brokerage from one place. Every Client, retailer and item lives in a single record, entered once, accurate everywhere. New clients onboard through one structured flow instead of a spreadsheet relay. The legacy system and the side spreadsheets are retired.
The legacy plus spreadsheet patchwork retired in a single migration. Onboarding, customer ship tos and item specs now live in one structured system the team works in daily. Outcome KPIs are still maturing. The signal so far is operational: one source of truth, in real use.
A high end household and estate staffing agency was running its pipeline across spreadsheets, email, and WhatsApp. We replaced it with a two sided, stage gated platform where each side sees only the view it needs.
