Here is the reframe that makes a building-supply migration make sense: the web store was never the system. The system is the ERP and the counter, where the item master, the contract pricing, the credit decisions, and thirty years of product knowledge actually live. Whatever sits on the web today, an aging Magento install, a WooCommerce site held together by pricing plugins, an ERP vendor's web module, or nothing at all, is an outpost. Replatforming to Shopify is not about moving the outpost. It is about building a better one against the systems that were always in charge.
Quick answer: A supply-house migration to Shopify runs on three rules. The ERP stays the system of record, accounts receivable, credit, contract pricing, and the item master never move. The storefront is rebuilt against the ERP rather than ported from the old web store, because the old store's data is a stale copy of truth that lives elsewhere. And cutover happens by account cohort rather than big bang, because the counter keeps working throughout, which is a luxury retail migrations do not have and supply houses should use.
What Migrates, and What Never Should
Sorting the data by where its truth lives clarifies the whole project.
Never moves: AR balances, credit limits, payment terms, contract pricing records, and the item master. These live in the ERP and stay there. The storefront reads them through the sync; it does not own them. A migration plan that includes "move pricing to Shopify" as a line item has already made the mistake the project exists to fix.
Moves from the old web store, if one exists: customer logins and their mapping to ERP account numbers, order history worth surfacing to buyers, content pages, and the URL patterns that carry whatever organic traffic the old site earned.
Gets rebuilt, not moved: the product catalog's storefront representation (how the ERP's item master becomes navigable products with real units and variants), the pricing display layer, and the ERP integration itself. Old integrations were shaped by the old platform's limitations, and porting them forward preserves the workarounds along with the connection.
The one thing to resist is loyalty to the old store's data. If the web pricing and the ERP pricing ever disagreed, the ERP was right, and the migration is the moment to stop maintaining the copy.
Two Starting Points, Two Different Projects
The legacy web store. Some supply houses are on a real ecommerce platform that aged out: a Magento build whose trade-pricing customizations hardened into unupgradeable extensions, a WooCommerce site whose plugins nobody dares update, or an ERP vendor's bundled web module that technically works and practically converts nobody. This is a true replatform: web-side data migrates, URL equity gets redirected, and the ERP sync gets rebuilt properly, following the same discipline as the general replatforming checklist, with Magento being the most common departure point in this industry.
The counter-first business. Just as many supply houses have no real store to migrate from. Orders run through the counter, the phone, and a shared inbox; the "web presence" is a brochure. Calling this a migration is only half wrong, because the data migration is real, it just runs from the ERP and from people's heads instead of from a database export. The item master needs storefront modeling it never needed before. And the product knowledge that lets a counter veteran answer "what do I need for this" has to be captured as product data, relationships, and content, or the online store launches knowing less than the counter does, and buyers notice.
Both roads converge on the same destination: the storefront capabilities a contractor portal has to deliver to keep trade orders digital.
The Data Work That Decides the Outcome
Three workstreams carry most of the risk, and none of them is platform setup.
Item master modeling. The ERP's item master was built for operations, not navigation. Turning it into a storefront catalog means deciding what becomes a product versus a variant, carrying real units and conversions, the dimensional and variable-unit logic lumber demands, and structuring the technical attributes buyers filter by. For made-to-order lines, windows, doors, millwork, the modeling extends into configuration rules, which is its own build with its own quoting flow.
Pricing and account architecture. Contract rates, trade tiers, and job pricing map onto Shopify's company accounts, catalogs, and price lists per the contractor pricing architecture, fed by the ERP through the sync patterns the building-materials ERP guide covers in depth: mirror the stable layers, keep conditional pricing ERP-side, and push commodity repricing on events rather than batches. Account provisioning belongs here too, deciding which ERP customers get logins at launch, with what roles, mapped to which price lists.
Tribal-knowledge capture. The least glamorous workstream and the one most often skipped. The counter knows which products substitute for which, what always sells together, and which SKU the contractor actually means when they ask for the colloquial name. Interviewing that knowledge into product relationships, search synonyms, and buying guides is what makes the new store feel like the counter instead of a database with a checkout.
Sequence: The Counter Is Your Safety Net
Retail migrations are high-wire acts because the old site is the revenue and the cutover is a cliff. A supply house has a gentler option, and should take it.
Integration before storefront. Stand up the ERP sync first, items, pricing, inventory, accounts flowing into Shopify, and validate it while nobody is watching. A storefront built on a proven sync launches honest; one built in parallel with its sync launches hopeful.
Pilot cohort. Open the store to a handful of friendly trade accounts whose buying you know well. Their orders exercise the pricing, UOM, and terms logic against reality, and their complaints arrive by first name instead of by churn.
Cohort cutover. Invite accounts in waves, by branch, by trade, by rep relationship, while the counter keeps serving everyone as it always has. There is no cliff. Orders shift channel at the pace trust builds, and the counter absorbs whatever the portal is not ready for yet. The old web store, if there was one, retires only after its accounts have somewhere better to be, with redirects preserving whatever search equity it accumulated.
The pattern's proof at scale: ULE Group runs its building materials business on Uncap's Shopify Plus platform, with more than one million SKUs synced from Epicor to the storefront, an ERP-first architecture of exactly this shape.
Where Uncap Fits
Uncap has been a Shopify Platinum Partner since 2013, with more than 380 B2B commerce projects delivered for manufacturers, distributors, and wholesalers, and Shopify migrations for operations whose truth lives in an ERP are among the deepest patterns in that portfolio. The full build context for this vertical is on the building materials and construction industry page.
Talk to Our Experts if you want a read on your starting point, legacy store or counter-first, and what the sequence would look like for your accounts.
Frequently asked questions
What actually migrates when a building supply house moves to Shopify?
Web-side data, if a legacy store exists: customer logins, order history, content, and redirect-worthy URLs. The ERP's data, AR, credit, contract pricing, the item master, never moves; the new storefront reads it through a rebuilt sync. The catalog's storefront representation and the integration itself are rebuilt rather than ported.
Can a supply house with no real web store still "migrate" to Shopify?
Yes, and it is common. The migration runs from the ERP and from staff knowledge rather than a database export: item master modeling, pricing and account architecture, and capturing the counter's product knowledge as data. The project is greenfield on the storefront side and very much a migration on the data side.
Why cut over by account cohort instead of all at once?
Because the counter keeps working, so nothing forces a cliff. Waves of accounts, by branch, trade, or rep, let pricing, units, and terms logic prove out on friendly volume before the whole book depends on it, and the counter absorbs anything the portal is not ready for.
Should pricing from the old web store be migrated?
No. Web-store pricing was always a copy of the ERP's truth, usually a stale one. The new storefront mirrors pricing from the ERP through the sync, and the migration is the right moment to retire the copy rather than preserve it.
