How THE OUTNET Replatformed Its Storefront on Shopify Hydrogen
How THE OUTNET established an independent Shopify Hydrogen storefront with Weaverse, using clear system ownership, visual editing, page-level SEO controls, and reconciled migration workflows.

Client context
THE OUTNET is an online destination for past-season luxury fashion. Its storefront combines a distinct editorial identity with the application behavior and operating systems required by an international commerce business.
The challenge
After the sale of the assets powering THE OUTNET platform, the business needed to separate the storefront from systems tied to its previous operating environment and establish a commerce foundation it could operate independently. This was more than a front-end redesign. The new foundation had to preserve THE OUTNET's customer-facing identity while giving the business clear control over the application, content workflow, commerce configuration, and service integrations. Storefront architecture, visual content, product discovery, localization, customer accounts, historical commerce data, integrations, testing, and production cutover each needed an owner and its own evidence of readiness.
The brief covered:
- custom design and routing behavior;
- market-aware shopping, search, and category browsing;
- customer accounts and editorial merchandising;
- historical records and connections to supporting commerce services; and
- a visual content workflow connected to the storefront's component system rather than operating as a disconnected page layer.
Weaverse delivered the reviewed Hydrogen storefront implementation and historical-order migration tooling as part of the wider delivery program. Client-side teams prepared migration inputs, made metadata and content choices, governed publication, and executed the production cutover.
Why Hydrogen and Weaverse fit the operating model
Hydrogen provided the application model for a custom storefront. Weaverse Studio supplied the visual composition workflow within that model, so content editing and the storefront's approved component boundaries remained connected.
The resulting stack uses Shopify as the commerce core, Hydrogen as the application framework, and Oxygen as the runtime. Weaverse Studio provides visual content and page-management tools. Constructor handles search and collection browse, while Shopify Customer Accounts supplies the customer-account experience.

The solution
Clear responsibilities across the storefront stack
A multi-system storefront is easier to operate when every concern has an explicit home. The reviewed implementation established these responsibilities:
- Shopify holds commerce data and market context.
- Hydrogen controls storefront application behavior, routing, and the integration layer around the customer experience.
- Oxygen hosts the Hydrogen application.
- Weaverse Studio manages visual page composition and selected content workflows through components defined by the storefront implementation.
- Constructor powers search and collection browse, integrated into the Hydrogen experience.
- Shopify Customer Accounts provides the account system used by the storefront.
The account direction changed during delivery. The final implementation used Shopify's native customer-account system rather than maintaining the separate identity direction considered earlier in the project. That kept customer-account behavior aligned with the commerce platform and removed an additional identity system from the storefront architecture.
These boundaries also helped teams place changes correctly. Market behavior belonged in commerce configuration or application logic. Visual page composition belonged in Weaverse. Search behavior belonged in Constructor and the Hydrogen integration around it. Customer-account behavior belonged with Shopify Customer Accounts and the storefront code that exposed it.
Visual content inside a custom Hydrogen storefront
Editorial stories, campaigns, navigation, landing pages, collection narratives, and product presentation change on a different schedule from application code. The content workflow therefore needed to respect THE OUTNET's custom design system without forcing every visual update through a code deployment.
Developers defined reusable sections and application behavior in Hydrogen. Content teams used Weaverse Studio for selected page, navigation, and localized-content updates. Editors composed pages from approved components in a visual preview, while developers retained control of component behavior, data requirements, and application boundaries.
This creates a shared operating model rather than removing engineering from every content task. Editors can work visually within the capabilities exposed by the implementation. Developers remain responsible when a change requires a new component, data integration, routing rule, or correction to preview and publishing behavior. Weaverse continued platform support after launch where those boundaries met.

Managing page-level SEO through Weaverse
Page metadata works best when it stays close to the page it describes. For the Home page and custom pages managed in Weaverse Studio, the content team can open the relevant page and manage its title, description, and keywords alongside the visible content.
Keeping those fields in the page workflow lets editors review metadata in the context of the content it describes before publication.
A practical page workflow is therefore:
- Select the Home page or a custom page in Weaverse Studio.
- Review the visible content and update its title, description, and keywords.
- Review the metadata with the visible content for consistency.
- Send the page and metadata through the client's content governance and publication decision.
The division of responsibility remains explicit. Weaverse provides page-level controls within the page workflow. Developers own the storefront implementation beneath them. The client content team owns the metadata choices, review, governance, and publication decision.
These controls do not replace the storefront's full technical SEO stack. Redirects, structured data, sitemap behavior, crawlability, rendering, and other application-level concerns still require separate implementation and verification. Page-level controls support metadata management; they do not establish ranking or traffic outcomes by themselves.

Localizing one storefront
Market context affects routes, currency, sizing, availability, navigation, content, and checkout. In the delivered storefront, Hydrogen consumes market context from Shopify. Weaverse supplies the corresponding visual-content layer, while Constructor receives the locale and catalog context needed for discovery.
That separation lets application rules stay in code while editorial and merchandising content stays in the visual workflow. Content teams can work with localized fields and preview context without moving market routing or commerce rules out of the application.
Localization readiness still requires coordination. Commerce configuration, application behavior, content, discovery, and checkout must agree on the active context. The architecture provides a place for each concern; it does not turn every variation or integration into the same kind of publishing task.

Search and collection browse within merchandising
Shoppers reach products through search, category pages, filters, facets, sorting, collections, and editorial links. THE OUTNET's implementation treats those paths as part of the broader merchandising experience rather than as a separate search surface.
Constructor is integrated into Hydrogen for search and collection browse. The integration connects discovery to the storefront's market and locale context, while Hydrogen controls the surrounding application experience. Weaverse-managed editorial content can then lead into the same product-discovery paths without taking ownership of search behavior itself.
This boundary keeps responsibilities clear: Constructor supplies discovery capabilities, Hydrogen integrates them into the storefront, and client teams govern merchandising choices. Current catalog coverage, search performance, and vendor-operating outcomes require separate production evidence and are not claimed here.

Making historical migration auditable
Historical commerce migration can report technical job completion without proving that relationships inside the data are correct. THE OUTNET's migration workflow therefore treated import as a sequence of validation decisions, with source reconciliation defining readiness for review.
Catalog readiness came first because historical line items needed to connect to the correct products and variants. During joint validation, client-side data owners confirmed the authoritative linkage key. Weaverse then updated and validated the importer before expanding the migration workflow.
The team tested representative records in small batches. Checks covered account association, product linkage, order state, and unintended customer-facing behavior. Once the mapping and workflow were stable, the migration moved from a record-by-record API path to Shopify bulk import operations.
Reconciliation compared the destination with the source population. Exceptions were recorded separately, allowing the final review to distinguish migrated records from unresolved source cases without exposing customer information or treating queue status as proof of correctness.
The ownership boundary remained important throughout. Weaverse owned the reviewed importer implementation and migration tooling. Client-side teams prepared source data, identified authoritative business keys, reviewed exceptions, and made governance decisions about the records. That division prevented tooling success from being mistaken for client acceptance of the underlying data.

Cutover and post-launch support
Production readiness reviews covered account behavior, market routing, content, search, privacy controls, analytics, redirects, checkout, service ownership, and rollback planning. Verified behavior remained separate from unresolved work so each workstream could be evaluated on its own evidence.
The client executed the production cutover. Weaverse then verified public storefront availability and continued targeted post-launch support. Remaining items stayed visible after launch rather than being absorbed into a general statement of completion.
That distinction matters. Public availability demonstrates that the storefront reached customers. It does not prove that every transaction path, integration, market behavior, or operational handoff reached the same state at the same moment.
Result: an independent Hydrogen foundation
THE OUTNET now runs a Shopify Hydrogen storefront on Oxygen, with Weaverse Studio and Constructor serving their defined roles in the live stack. The architecture supports market-aware application behavior, Shopify customer accounts, visual content work, page-level metadata management, and continued iteration across content and code.
The migration method provides a reusable pattern for complex historical data: map dependencies, validate the business identifiers, test representative records, expand only after relationships are verified, reconcile against the source, and keep exceptions visible for review.

Practical lessons for enterprise replatforms
Assign architectural ownership early. Shopify holds commerce and market context; Hydrogen handles application behavior; Weaverse manages visual composition and page workflows; Constructor handles search and browse; Shopify Customer Accounts owns the account system. A named boundary makes changes and defects easier to place as the program evolves.
Keep content flexibility inside implementation boundaries. Visual editing is most useful when editors work with approved components and developers retain control of application behavior, data access, and new capabilities.
Manage page metadata with the page, but verify technical SEO separately. Weaverse brings Home and custom-page titles, descriptions, and keywords into the editorial workflow. Redirects, structured data, crawlability, and the rest of the technical SEO system remain separate engineering concerns.
Define migration completion through evidence. Representative tests, relationship checks, source reconciliation, and exception review reveal more than an import job's terminal status.
Separate platform delivery from client decisions. Implementation, data preparation, governance, content choices, cutover, and publication belong to different owners. A clear record of those decisions produces a more accurate readiness review and a more maintainable operating model.
Related resources
- Visit THE OUTNET
- Official SEC filing on the sale of the assets powering THE OUTNET platform
- Shopify Hydrogen and Oxygen fundamentals
- Deploying Hydrogen storefronts on Oxygen
- Internationalization with Shopify Markets in Hydrogen
- Shopify Customer Account API
- Shopify bulk import operations
- Navigating Weaverse Studio
- Constructor product discovery
Never miss an update
Subscribe to get the latest insights, tutorials, and best practices for building high-performance headless stores delivered to your inbox.