Get enough experienced CTOs together, and you’ll start hearing war stories about replatforming projects gone wrong. The new platform choice is often a target of blame, but listen closely enough, and you may find a pattern: Often, the true source of the problem is data that’s incoherent across channels.
Consider how complex this can get for a modern, multichannel ecommerce brand. The order management system (OMS) maintains one version of a customer's order history. The enterprise resource planning (ERP) system holds another. The B2B portal runs on a data model that has never communicated cleanly with the direct-to-consumer (DTC) side. Meanwhile, the legacy ERP system treats SKUs as catalog items, whereas the point-of-sale (POS) system treats them as inventory units.
No data platform migration can resolve this on its own. Without deliberate intervention, brands can end up replicating data debt on newer infrastructure, leading to disappointing results from the new platform.
Data-first modernization can at first glance look like an IT project: a technology improvement that may yield incremental efficiencies. But for enterprise commerce, data-first modernization is simply a prerequisite to platform value. Commerce brands, unlike companies in other industries, have unique data and multichannel fragmentation challenges. This article will help bridge that gap.
Why generic data modernization frameworks fail commerce businesses
When a consulting firm's data-modernization playbook lands in an engineering leader's inbox, the framing tends to follow a specific pattern: Migrate to the cloud, adopt a data lakehouse design, centralize pipelines, and build a unified data platform. The advice isn't wrong for enterprise IT in general. But it can fail commerce brands when it treats data as something to store and move, rather than domain-specific realities that determine whether the business can function at all.
How the infrastructure-led framing misses the point for retailers
The infrastructure-led approach tends to assume that once data is centralized in a modern data warehouse or lakehouse, the downstream benefits will follow automatically. For a financial services firm or a logistics provider, that assumption is often fairly accurate. For an enterprise retailer simultaneously operating DTC, wholesale, POS, and B2B channels, it likely isn't.
The gap lives in the commerce data model itself. Infrastructure modernization provides better ways to store data, but it doesn't address the confusion that can arise when the DTC platform, ERP, OMS, and B2B portal each maintain their own interpretation of what a "customer" is, what an "order" is, and what constitutes available inventory. A data lakehouse built on top of four conflicting data models can’t produce a single source of truth.
What the commerce data model actually looks like
The commerce data model is more complex than many infrastructure frameworks account for. Its core entities each carry channel-specific logic that must be reconciled before unification is meaningful, including:
- Orders: DTC transactions, wholesale purchase orders, in-store POS transactions, and B2B portal orders can each carry different fulfillment logic, pricing rules, payment terms, and tax treatments. All of these need to be reconciled for unified data to be meaningful and usable.
- SKUs: For unified product information, catalog items must be reconciled across channel-specific product feeds, variant configurations, and real-time inventory counts at individual fulfillment nodes.
- Customer profiles: DTC consumer profiles and POS customer records, which may represent the same individual, need to be reconciled for teams to accurately view and serve customers.
- Inventory nodes: Warehouse stock, in-store stock, in-transit stock, and reserved stock all need to be reconciled into records which are visible across channels to avoid overselling or missed demand signals.
- Channel attribution: First-party signals from DTC browsing, in-store purchase history, B2B buyer behavior, and wholesale order patterns need to be combined to form the raw material for any personalization or forecasting model.
These entities don't exist in isolation. An enterprise retailer's data model is a web of relationships: An order references a buyer account, which maps to a customer profile, which ties to a set of first-party signals and purchase events across channels.
When those relationships exist in five different systems with five different schemas, no amount of infrastructure modernization can produce a working commerce data model. Schema conflicts must be resolved at the data-model layer before migration begins.
How data debt accumulates differently in multichannel commerce versus enterprise IT
In enterprise IT, data debt typically accumulates as duplicated systems, undocumented integrations, and technical sprawl. While it can be costly, it’s usually resolvable through consolidation efforts.
In multichannel commerce, data debt can accumulate as semantic debt: conflicting definitions of the same entity embedded in each channel's operational logic. Maybe the DTC platform identifies a "customer" by their email address, while the ERP calls that customer an "account" and identifies them by a billing code.
None of these systems’ datasets map cleanly to any other, and all of them accumulate transformation logic every time a downstream system consumes the data. By the time a platform evaluation is underway, that transformation logic represents years of operational workarounds that no migration checklist surfaces automatically.
The multichannel data fragmentation problem
The multichannel data-fragmentation problem doesn't fix itself with a better extract, transform, load (ETL) pipeline or a modern data warehouse. For enterprise retailers and brands, it is a structural problem, one that accumulates as a hidden cost, compounding quietly until a strategic initiative like an AI use case, a new channel launch, or a merger makes the cost impossible to ignore.
Data fragmentation across commerce systems
Legacy ERP and OMS architectures were typically designed for single-channel operations. Even when those systems are extended to support additional channels, the underlying data model hasn't always been updated to accommodate the multichannel commercial reality.
The result can be siloed data across DTC, wholesale, POS, and B2B portals. Each silo potentially makes sense in isolation; but together, they prevent the business from operating as a coherent commercial entity. McKinsey research shows that up to one-third of B2B transactions are still conducted via time-consuming manual methods like fax and direct mail.
That isn't a problem brands can fix by telling sales teams to behave differently. Problems like these are data architecture problems manifesting as process problems.
Why AI and ML use cases fail without unified data
The demand for AI and machine learning (ML) capabilities in enterprise commerce is clear. A Capgemini survey found 74% of executives are prioritizing AI investment, and 69% believe increased technology investment is necessary to remain competitive. The primary business cases include:
- Demand forecasting
- Dynamic pricing
- Personalization at scale
- B2B buyer intelligence
Rarely discussed, however, are the data prerequisites that underpin all of these efforts.
Every commerce AI use case is a function of data quality and data coverage. A demand-forecasting model needs SKU-level sales history across channels, real-time inventory counts across fulfillment nodes, and seasonal signals spanning multiple years of transaction data. If those signals exist in four different systems with four different schemas and refresh cycles measured in hours or days, the model produces unreliable outputs.
Case study: Belstaff
Belstaff, the century-old British apparel brand, faced a modernization challenge that many enterprise retailers will recognize: a fragmented legacy environment with data siloed across point-of-sale and ERP systems.
Navid Jilow, director of technology at Belstaff, says, "IT transformation is really about data centralization; the one platform view." Belstaff began Mission Phoenix, an initiative to resolve data architecture problems and migrate platforms. By consolidating ecommerce and POS onto a single platform and reducing the integration surface area between systems, Belstaff created the data foundation that advanced use cases now require.
As Navid describes it: "Whether we have a customer shopping in-store or purchasing online, we now have that single view. We're closing gaps in our data, enabling us to keep improving the customer experience."
Data-first vs. cloud-first
The cloud-first and platform-first approaches to modernization share a common failure mode for commerce businesses: they treat the infrastructure decision as the primary one. Data-first modernization inverts that sequence: Define the unified commerce data model first, then evaluate platforms against their ability to support it natively.
The platform selection trap
The platform selection process at most enterprise retailers follows a familiar pattern: evaluate features, conduct demos, assess integration complexity, negotiate commercial terms, and select a platform. What that process rarely surfaces is the data-model incompatibility that can emerge during implementation.
Choosing a platform before resolving the data model is putting the cart before the horse. The platform can only be as good as the data it receives. If that data is structurally fragmented across conflicting schemas, the new platform inherits the problem.
Data architecture decisions de-risk migration
The retailers and brands that have executed successful migrations tend to share one characteristic: they spent time on the data model before platform selection.
That means mapping every entity, every integration, and every transformation layer before evaluating platforms. It means defining what a unified customer record looks like across DTC and B2B. It means documenting the order data model for every channel: which fields exist, which are populated, and which fields conflict across systems. This work is completed before you even consider a platform demo.
The inaction tax
Every quarter that data architecture improvements are deferred, the cost compounds. Call it the inaction tax. An October 2025 TrendCandy survey found that manual workflows cost an average of 5% in annual revenue, with 88% of surveyed businesses saying they’d lost deals due to inefficient quote-generation and approval processes. That's where things stand today, but as AI advances, the inaction tax stands to get even worse.
Deferred AI capability is potentially the most significant component of the inaction tax. Examples include:
- Demand forecasting models that can't be trained because channel-level sales data lives in incompatible systems
- Personalization engines that can't draw on B2B buyer history because it exists in a portal schema that has never been unified with the DTC customer record
- Dynamic pricing models that can't run in real time because inventory data refreshes on a batch cycle
Then, there’s the even harder to detect opportunity cost: Which opportunities, large and small, are you failing to see and inevitably missing? These can’t appear on the balance sheet, really, until a competitor solves the problem first and takes meaningful market share. And that’s at the heart of the inaction tax: While you’re delaying the adoption of AI technologies that can automate key workflows and level up your business, your competitors aren’t waiting.
The commerce-specific AI use cases that data-first modernization unlocks
The AI use cases available to enterprise retailers and brands are defined by the specific data inputs each requires. Those inputs are only reliably available once the commerce data model is unified across channels. The following four use cases illustrate what is possible and which data each one requires.
Demand forecasting across channels
Single-channel inventory data makes ML-based demand forecasting models structurally unreliable. A model trained on DTC sales history doesn't know that a wholesale order depleted a fulfillment node three days before a seasonal peak. A model trained on in-store POS data doesn't capture the DTC browse signals that indicate pending demand.
Unified demand forecasting requires SKU-level transaction history across all channels, real-time inventory counts at every fulfillment node, and historical signal data spanning sufficient time periods to support seasonal correction. None of those inputs is available until the underlying data architecture unifies them.
The same pattern affects personalization. If data is fragmented, even a high volume of buyer information becomes more noise than signal. When data is fragmented, personalization efforts may operate on partial information, leading to results that fail to meet expectations.
Dynamic pricing and B2B fraud detection
Dynamic pricing models and B2B fraud detection have a similar data requirement: cross-channel, real-time data access.
Dynamic pricing requires current inventory levels, current demand signals, and historical conversion data by channel and price point, all continuously updated. B2B fraud detection needs behavioral patterns at the buyer account level—order frequency, purchase amounts, fulfillment address consistency, and payment method behavior—visible across every interaction channel.
Both use cases can fail when data is stale, siloed, or inconsistent. Real-time cross-channel data isn't a nice-to-have for these models. A batch-refresh architecture, no matter how well-engineered, introduces enough latency to render real-time pricing and behavioral fraud signals relatively meaningless.
Case study: Molson Coors
When Molson Coors built Ship and Sip, their DTC platform for home beer delivery in Canada, the underlying challenge was a data-architecture one: how to translate first-party consumer data from a wholesale-oriented tool into one that could work in a direct-to-consumer context.
Getting that data foundation right produced concrete results. Comparing days surrounding a holiday weekend in August to the same period in September, Ship and Sip saw sales growth of 188%, order growth of 152%, and conversion rate improvement of 109% month-over-month.
These numbers reflect the downstream value of a first-party data channel that provides a clean, direct signal from consumer to fulfillment.
Who owns the data?
When each channel has its own system, data ownership is fragmented: the DTC team owns DTC data, the wholesale team owns wholesale records, and the retail ops team owns POS data. Resolving governance is inseparable from resolving the technical architecture.
Data ownership across teams
In enterprise retail organizations, top-level data ownership typically spans three executive roles:
- The CDO owns governance and data strategy.
The CMO owns customer data activation and attribution. - The CTO owns the architectural and platform decisions that enable unified data.
The problem is that in many organizations, these roles have never needed to work from a shared data model. The consequence is that the organizational design for unified data must be built alongside the technical architecture. Deferring the governance conversation until after platform selection is another sequencing error, one that can surface as disputed data ownership during implementation and slows adoption post-launch.
Data sovereignty
Enterprise retailers selling across regions face a data sovereignty layer on top of the governance challenge. GDPR in Europe and CCPA in California and others in the growing set of regional data residency requirements impose constraints on where customer data can be stored and how it can be used for personalization and targeting.
A fragmented data architecture makes compliance even harder. When customer data spans multiple systems and regions, the compliance surface area increases. A unified commerce data model, designed with data residency requirements in mind from the start, reduces that surface area and makes compliance audits tractable.
How a unified commerce platform operationalizes data-first modernization
Data-first modernization makes platform selection more precise. Once the unified commerce data model is defined, platforms can be evaluated against a concrete specification rather than a feature list, which changes both the questions asked and the weight given to each answer.
A unified commerce data model
Every integration that a multi-platform architecture requires—between ecommerce and POS, between DTC and B2B, or between the OMS and the ERP—is a data-translation layer, each of which can introduce latency, schema drift, and maintenance costs that compound over time. A platform that natively spans those channels eliminates those translation layers at the data model level.
The downstream consequence is that analytics, forecasting, and personalization models can draw on a complete, consistent set of signals without requiring a custom data unification build. And those signals yield results: Research from Manhattan Associates found that mature unified commerce operators achieve 23% higher inventory turnover and 1.5 times higher customer lifetime value (CLV) compared to competitors.
Real-time order and inventory data
API-first, real-time data access removes the latency that can make AI commerce projects fail in production. Batch-cycle inventory data, refreshing every four to eight hours from a legacy ERP, is insufficient for real-time dynamic pricing, demand-signal detection, and behavioral fraud pattern recognition.
An architecture that consolidates order and inventory data onto a single data model and exposes it via a modern API layer closes that latency gap at a structural level rather than through custom middleware that adds its own maintenance cost and failure surface.
Case study: Skullcandy
Skullcandy replatformed to Shopify in just 90 days, migrating their US site and then launching in Canada, the EU, and the UK within weeks using the same patterns. As a result, their homepage load time dropped from 2.8 seconds to 0.8 seconds on launch day, and their top-selling product page cut load time roughly in half.
Post migration, product launches that previously required a full day of development now take under an hour. Their first full holiday season on Shopify delivered 45% year-over-year revenue growth, the strongest sales period in the brand's history.
Mark Hopkins, Skullcandy's CIO, said the team had been spending too much time "making sure that things were flowing" rather than innovating. Resolving their architecture problem therefore freed them from spending hours on maintenance, allowing them to capture opportunities rather than lose them.
Implementation speed and compounding value
The inaction tax doesn’t stop accruing costs the moment brands decide to replatform. What makes Skullcandy such a success story isn’t just the improved metrics they achieved at launch, it’s how quickly they got there. The longer it takes from decision to completion, the longer brands remain effectively in a state of inaction.
Retailers transitioning to Shopify see up to a 36% decrease in total cost of ownership (TCO) compared to major competitors, according to an independent consulting firm. The faster you can implement, the sooner you can stop paying the inaction tax.
That benefit goes in the opposite direction, too. EA retailer that resolves the data architecture in year one and begins building AI capability in year two is operating from a materially stronger position than one that selects a platform in year one and discovers the data problem in year three.
Data-first modernization for enterprise commerce: A four-stage framework
The framework below is designed as a practitioner self-assessment tool. The goal is to establish a concrete starting point for auditing your commerce data estate and defining the modernization sequence before any vendor conversations begin.
Stage 1: Audit and map your commerce data estate across all channels
The audit begins with a complete inventory of every system that holds commercial data: every DTC platform, OMS, ERP, POS system, B2B portal, wholesale management tool, and customer data platform in the current stack. For each system, document the following:
- The core entities it holds (customers, orders, products, inventory, pricing)
- The schema those entities use (field names, data types, key structures, update frequency)
- The integration dependencies (what systems it sends data to, what it receives, and in what format)
- The transformation logic that exists between systems, particularly any middleware or extract, transform, load (ETL) processes that reconcile conflicting schemas
The goal of this audit is to make visible the semantic conflicts that exist across systems. Those conflicts generate data debt, and until they're mapped, their scope is invisible to anyone writing a request for proposal (RFP) or a migration budget.
Stage 2: Define your unified commerce data model before evaluating platforms
Before evaluating any platform, define what a unified commerce data model looks like for your specific business. That means producing a canonical schema for each core entity, including:
- What constitutes a complete customer record, spanning DTC and B2B buyer contexts?
- What fields does a canonical order record require across all channel types, including fulfillment logic and payment terms?
- How is SKU identity reconciled across catalog, inventory, and channel-specific product feeds?
- What is the inventory node structure, and what data does each node need to expose in real time?
- How is channel attribution captured and maintained at the event level?
This exercise translates the abstract problem of data fragmentation into a gap analysis you can use to evaluate platforms. A team that has completed this exercise can ask a platform vendor a precise question, like, "Does your native data model support this canonical customer record spanning DTC and B2B?" rather than a broad one about feature coverage.
Stage 3: Select for native data unification capability, not platform feature lists
Many platform RFPs focus on feature coverage: Which channels does the platform support, what checkout features does it include, and how does it handle B2B pricing and buyer accounts? Feature coverage, however, is necessary but insufficient to support an informed decision.
The evaluation question that data-first modernization surfaces is different: Does this platform natively unify the data model across DTC, POS, wholesale, and B2B, or does it require custom integration work to approximate unification?
A platform that natively shares a customer record, order model, and inventory schema across channels reduces the integration surface area that produces data debt in the first place. A platform that treats each channel as a separate module and requires custom middleware to synchronize just transports the structural problem the modernization was supposed to solve.
Stage 4: Sequence AI and ML use case activation against your unified data foundation
Once the unified commerce data model is live on a platform that natively supports it, AI and machine-learning (ML) implementations can begin. The sequencing within this stage matters because starting with the highest-complexity use case against an immature data foundation can produce unreliable outputs that erode organizational confidence in AI investment.
Instead, start with projects that require the least cross-channel signal coverage, such as single-channel demand forecasting, product recommendation engines trained on DTC browse data, and basic order-anomaly detection.
Progress to more complex use cases that require unified signals, such as cross-channel demand forecasting, personalization models that draw on both DTC and B2B behavior, and dynamic pricing models that update against real-time inventory.
Reserve the highest-complexity use cases, such as B2B buyer fraud detection, multiregion pricing optimization, and predictive reorder intelligence, for when the data foundation has accumulated sufficient signal depth and proven success.
The modernization decision that happens before you pick a platform
The brands that execute successful modernizations tend to spend meaningful time before platform evaluation mapping their data estate, resolving the semantic conflicts in their existing schemas, and defining what unification actually means for their specific business. That work occurs during the architecture reviews and whiteboard sessions that precede the RFP, and it often determines how much of the implementation budget goes toward capability development rather than remediation.
The cost of getting the sequence wrong is deferred, which is why it's easy to skip; but the cost compounds. Every implementation team handed a migration project with an unresolved data model problem knows exactly what that cost looks like. And every CTO who has lived through it wishes they had spent that time up front.
Data-first modernization is the decision to spend that time before it becomes a crisis, and to treat the data architecture decision as the one that determines the long-term commercial outcome of everything that follows.
Data-first modernization FAQ
What is meant by data modernization?
Data modernization is the process of replacing legacy data infrastructure and practices with contemporary architectures that improve data quality, accessibility, and reliability. In a commerce context, it specifically includes resolving the conflicting data models across DTC, wholesale, POS, and B2B channels that prevent unified analytics, forecasting, and AI activation.
What is a data-first approach?
A data-first approach prioritizes defining and unifying the data model before making infrastructure or platform decisions. In commerce, this means mapping the canonical schemas for orders, customers, SKUs, inventory nodes, and channel attribution, and using those definitions to evaluate platforms rather than selecting a platform first and inheriting its data model.
Why does data-first modernization matter in commerce?
Commerce AI use cases like demand forecasting, personalization at scale, dynamic pricing, and B2B buyer intelligence each require specific, unified data inputs across channels. Without a unified data model, those inputs are unreliable, making AI investments non-performant. Platform migration without resolving the data model first replicates existing data debt on the new infrastructure.
What data should be unified in a commerce business?
The five core entities are: orders (spanning all channel types and their fulfillment logic), SKUs (reconciled across catalog, inventory, and channel feeds), buyer accounts (DTC and POS unified into a single customer record), inventory nodes (real-time counts at every fulfillment location), and channel attribution (first-party event data across every touchpoint).
