Alberto Vena

For an enterprise brand that wants to move to Shopify, picking an agency partner that can execute a smooth migration can be challenging.

Most Shopify agencies built their expertise working with mid-market brands doing anywhere from $5M to $30M in annual GMV. They've developed processes, templates, and technology stacks optimized for that segment. When an enterprise brand approaches them, they scale up the team size and timeline but keep the same fundamental approach. The result is a migration that either goes over budget, misses the mark on business requirements, or both.

In this guide, we're going to show you the most common failure modes for an enterprise Shopify replatform, and how to identify the right partner.

## Mistake #1: Failing to Account for Enterprise Risk

The core difference between mid-market and enterprise migrations is risk. If your store goes down for two hours, what does that cost you? If a data migration error corrupts your marketing opt-ins, what's the likelihood you'll get sued? If you launch a new design that introduces friction, what's the impact on conversion rate?

Mid-market brands can absorb these risks more easily. They're smaller, more agile, and often still figuring out their optimal processes. A failed migration is painful but recoverable. For an enterprise brand doing $100M or more annually, even a small dip in conversion during a botched cutover can translate to hundreds of thousands in lost revenue in a matter of days. The math changes everything about how you plan.

**The risk mitigation that enterprise requires looks different:**

- **Longer testing cycles** with real data volumes, not sample datasets
- **Staged rollouts** that let you validate functionality before full cutover
- **Detailed rollback plans** for when (not if) something goes wrong
- **Parallel running** of old and new systems during transition periods
- **More conservative timelines** that account for organizational complexity

Agencies that treat enterprise as scaled-up mid-market skip these steps or treat them as optional. They've run dozens of migrations where you flip the switch on launch day and deal with problems as they come up. That approach works when you're doing $10M annually and have a small team that can move fast. It falls apart when you have multiple departments, established SLAs with customers, and operational dependencies that can't just pause while you fix issues.

## Mistake #2: Leading with Technology Instead of Business Outcomes

Shopify has opinions about how e-commerce should work. Many of those opinions are good. The platform's constraints force simplification, which often leads to better customer experiences and more maintainable code. But Shopify's way is not always the right way for every business.

Agencies that lead with technology start from the assumption that you should adapt your business to fit Shopify's model. If you have a complex pricing structure, simplify it. If you have custom fulfillment workflows, standardize them. If your checkout has specific fields required by your finance team, find a workaround or drop them.

For a newer brand without established processes, this can be liberating. You get to build on top of best practices rather than carrying forward legacy decisions. But for an enterprise brand with a proven value proposition and market positioning, this approach can denature the business.

The right approach balances platform constraints with business requirements. A good agency knows when Shopify's opinion should win (because it genuinely leads to better outcomes) and when you need to work around platform limitations (because your business model depends on it). They start by understanding what drives your business, then figure out how to map that onto Shopify.

This requires flexibility. Rather than having a ready-made solution that worked for the last five clients, they need to understand your specific drivers, constraints, and competitive positioning. The reassurance of a proven template is tempting, but every migration at this level has its own characteristics and needs a tailored approach.

## Mistake #3: Lacking the Technical Depth for Complex Migrations

Understanding what needs to happen strategically is different from having the technical skills to execute it. An agency might grasp your business requirements perfectly but still fail if they don't have deep technical expertise in both your current platform and Shopify's architecture.

Every e-commerce platform has different affordandces and constraints. Migrating from Magento, Salesforce Commerce Cloud, or a custom stack to Shopify requires engineers who understand both systems deeply. You need people who can look at your current data structure and understand not just what it contains, but why it's structured that way, what business logic depends on it, and how it needs to transform to fit Shopify's model.

This goes beyond general web development skills. You need specialists who have worked with:

- **Complex data migrations** at scale, handling millions of records with referential integrity
- **API architecture** across different platforms and integration patterns
- **Custom Shopify development** beyond themes (apps, checkout extensions, custom account portals)

The gap shows up in estimation and execution. Agencies without this depth will underestimate the effort required for data migration, integration work, and custom development. They discover problems late in the project when they're already committed to timelines and budgets. The result is either rushed solutions that create technical debt or delays that push back the launch date.

An agency with real depth will surface complexity you hadn't anticipated—uncomfortable questions about your data structure, your integration dependencies, your edge cases. The difference is hard to spot in a proposal and obvious six months in.

## Mistake #4: Trying to Tackle Too Much at Once

Migrations are an opportunity to fix things. That's both true and dangerous.

The temptation is to change everything at once: new platform, new design, new third-party vendors, new operational workflows, new team structure. After all, you're already disrupting the business. Why not get everything right in one go?

Because every change introduces risk and complexity. When you change multiple variables simultaneously, it becomes nearly impossible to isolate problems. If conversion rates drop after launch, is it the new platform, the new design, or the new merchandising solution? You won't know.

The discipline of a good migration is changing only what the platform transition requires. If your current design works and your team can implement it on Shopify, keep it. If your vendor relationships are solid and the integrations are feasible, maintain them. Save the redesign, the vendor consolidation, and the workflow optimization for after the migration stabilizes.

This doesn't mean never changing anything beyond the platform. It means having a strategic reason for each change and understanding the risk you're accepting. If your current design is built around platform-specific features that don't exist in Shopify, you need a new design. If a vendor doesn't have a Shopify integration and building one would take three months, you might need a new vendor. But make those decisions deliberately, not opportunistically.

## Mistake #5: Underestimating Governance Complexity

Projects at this scale are not linear. You don't gather requirements upfront, disappear for six months, and emerge with a finished product. They're iterative processes involving multiple stakeholders with different priorities, evolving requirements as you learn more, and organizational dynamics that can't be predicted from a kickoff meeting.

The challenge goes beyond technical complexity: it requires coordinating between departments that don't normally work together closely. Your e-commerce team might want to simplify the checkout flow, but finance needs specific fields for tax compliance. Marketing wants content flexibility for campaigns, but brand wants to retain visual control. Operations has workflows built around the current platform that can't just stop working.

Agencies that lack enterprise project governance try to contain this complexity by locking down scope early. They want a detailed requirements document signed off before development starts. They communicate through a project manager who shields the team from stakeholder chaos. They resist changes once the project is underway because changes threaten their timeline and budget.

This approach fails because it's impossible to collect all the context upfront. You discover requirements as you dig into the migration. Stakeholders realize implications of decisions only when they see working prototypes. Business priorities shift during a six-month project. An agency that can't adapt to these realities will either deliver something that doesn't meet your actual needs or blow up the timeline fighting scope changes.

**What good enterprise governance looks like:**

- **Continuous stakeholder communication** throughout the project, not just at milestones
- **Iterative requirement gathering** that expects to learn more as you go
- **Flexible planning** that can absorb changes without derailing the entire timeline
- **Direct access** between your team and the agency's developers and strategists
- **Transparent trade-off discussions** when requirements conflict or timelines need adjustment

The agencies that succeed at this level understand that flexibility and discipline are not opposites. You need structure to manage complexity, but that structure has to accommodate the reality that complex projects involve learning and adaptation. If an agency wants to disappear for months and only surface for status updates, they don't understand how projects of this complexity actually work.

## How These Mistakes Show Up in Practice

Let's say you're evaluating two Shopify Plus agencies for your migration. Both come highly recommended. Both have strong portfolios. But their approaches diverge in ways that reveal everything about how they'll handle your project.

**The first agency** comes prepared with a polished presentation. They've reviewed your site, identified improvements, and mapped out a six-month timeline with fixed pricing and clear deliverables. They show you similar brands they've migrated.

- **Data migration:** They have a tool that handles most of it automatically.
- **Changing requirements:** They emphasize the importance of locking down scope early.
- **Communication:** Everything flows through a project manager.
- **Vendors:** They have preferred partnerships that streamline integration.

Everything feels professional and reassuring.

**The second agency** asks more questions than they answer. What drove the decision to migrate? How is your team structured? What does your integration landscape look like? They propose a paid discovery phase before committing to a timeline or estimate.

- **Data migration:** They want to understand your data structure first because they've seen Magento migrations with custom models that don't map cleanly to Shopify.
- **Changing requirements:** They call it inevitable at enterprise scale.
- **Communication:** You'll have direct access to your design and development team.
- **Vendors:** No locked-in partnerships; they'll evaluate what fits your needs.

The contrast is telling. The first agency is selling you a solution they've refined across previous clients. Their confidence comes from pattern-matching: they're betting your requirements will fit their established approach. If they're right, you get a smooth project. If they're wrong, you discover the mismatch months in when it's expensive to change course.

The second agency is investing in understanding your specific situation before committing to an approach. The uncertainty is honest. Their discovery phase catches the complexity that a templated proposal would miss. Their flexible process accommodates the learning that inevitably happens during enterprise migrations.

The agency that makes you feel most confident during the sales process may be the one least equipped to handle the reality of your migration. Confidence is easy when you're applying a template. Look for the agency that asks harder questions, that wants discovery before committing to answers, and that treats your migration as genuinely unique rather than another variation of the last one they completed.

## Choosing the Partner Who Understands Enterprise Complexity

The mistakes outlined here share a common root: treating enterprise migrations as bigger versions of mid-market projects. Instead, these projects require a fundamentally different approach to risk, planning, technical execution, scope management, and governance. The agency that gets this right will be the one that resists the temptation to apply a proven template and instead invests in understanding what makes your business, your data, and your organization unique.

When you're evaluating partners, pay less attention to polished proposals and more attention to the quality of questions being asked. The right agency will make you slightly uncomfortable with how much they want to learn before committing to a plan. That discomfort is a sign they understand what they're getting into.

Need help navigating your migration to Shopify Plus? We'd be happy to talk through your specific situation and share what we've learned from working with enterprise brands. [Let's talk.](https://nebulab.com/contact-us)

Why Most Shopify Agencies Get Enterprise Replatforms Wrong

Nicolò Rebughini

If you've built a Shopify app with a Rails backend, you know the routine. You write a verbose GraphQL query string, fire it through the client, then start drilling into a nested hash response: `response["data"]["customer"]["defaultEmailAddress"]["emailAddress"]`. Repeat that across dozens of queries, each returning a slightly different shape, and your codebase turns into an archaeology dig site where nobody remembers which hash key lives where.

Shopify has been pushing hard toward GraphQL as the primary API surface, deprecating REST endpoints and funneling developers toward a more powerful but significantly more verbose interface. The problem is that Shopify's official Ruby tooling stops at giving you a client and an OpenStruct-style response. There's no domain modeling layer, no way to say "a Product always looks like this" across your entire codebase.

We built [ActiveShopifyGraphQL](https://github.com/nebulab/active_shopify_graphql) to fix that. 

## The Hidden Cost of Raw GraphQL Queries

The pain starts small. You write one query to fetch a product's title and price. Then another to fetch variants. Then someone needs metafields. Before long, you have query classes, query superclasses, helper methods for parsing responses, and OpenStruct wrappers that give you dot notation but still require you to know the exact shape of every response. 

Here's what a typical Shopify GraphQL interaction looks like in Ruby without any abstraction:

```ruby
query = <<~GRAPHQL
  query($id: ID!) {
    customer(id: $id) {
      id
      displayName
      defaultEmailAddress {
        emailAddress
      }
      orders(first: 10) {
        edges {
          node {
            id
            name
          }
        }
      }
    }
  }
GRAPHQL

response = client.query(query: query, variables: { id: "gid://shopify/Customer/123" })
customer = response.body["data"]["customer"]
email = customer["defaultEmailAddress"]["emailAddress"]
created_at = Time.parse(customer["createdAt"])
orders = customer["orders"]["edges"].map { |e| e["node"] }
```

This works, sure. But now multiply it by every entity in your app, and you start having problems:

- **Inconsistent object shapes.** Because GraphQL encourages fetching only what you need, the same conceptual entity (a product, a variant) ends up with different attributes in different parts of your codebase. In one place a variant has a SKU; in another, only a price. Your brain has to work overtime to track which version you're dealing with. 
- **Multiple API schemas for the same data.** If you're building a customer account portal, you might use Shopify's Customer Account API alongside the Admin API. Both can return a customer, but the email address lives at `defaultEmailAddress.emailAddress` in the Admin API and `emailAddress.emailAddress` in the Customer Account API. Same concept, different paths, different code. 
- **Maintenance burden at scale.** When Shopify updates their API version, you need to hunt down every query string scattered across your codebase, update field names, fix response parsing, and update all the tests. That time goes into maintaining plumbing instead of shipping features. 

At Nebulab, we deal with the GraphQL API every day, so we set out to solve the problem once and for all.

## What ActiveShopifyGraphQL Does

The gem lets you define Shopify entities as Ruby model classes with typed attributes, path mappings, and associations. It then auto-generates GraphQL fragments from those definitions, executes queries, and maps responses back to your model instances. No hand-written query strings for standard reads.

Here's the same customer interaction from above:

```ruby
class Customer < ActiveShopifyGraphQL::Model
  graphql_type "Customer"

  attribute :id, type: :string
  attribute :name, path: "displayName", type: :string
  attribute :email, path: "defaultEmailAddress.emailAddress", type: :string
  attribute :created_at, type: :datetime

  has_many_connected :orders, default_arguments: { first: 10 }
end

customer = Customer.includes(:orders).find(123456789)
customer.name       # => "John Doe"
customer.email      # => "john@example.com"
customer.created_at # => 2024-03-15 14:30:00 UTC
customer.orders     # Already loaded, no additional query
```

A few things are happening automatically here:

- The `path` option tells the gem where to find a value in the GraphQL response, so `defaultEmailAddress.emailAddress` gets mapped to a simple `email` attribute on your model.
- Type coercion handles the conversion (strings stay strings, `createdAt` becomes a Ruby `Time` object). 
- camelCase to snake_case conversion is automatic: you define `created_at`, and the gem knows to request `createdAt` from the API.

The `graphql_type` declaration is optional when your class name matches the Shopify type. A class called `Product` will automatically map to the `Product` GraphQL type, but you can override it when Shopify's naming diverges from yours, which happens more often than you'd expect!

### The Query API You Know and Love

If you've used ActiveRecord, the query interface will feel immediately familiar:

```ruby
# Find by GID or numeric ID
customer = Customer.find("gid://shopify/Customer/123456789")
customer = Customer.find(123456789)

# Filter with hash syntax
Customer.where(email: "john@example.com")

# Or Shopify's search query syntax for wildcards
Customer.where("email:*@example.com")

# Chain methods
Customer.where(email: "@example.com")
        .order(sort_key: "CREATED_AT", reverse: true)
        .limit(25)

# Select specific fields to reduce API cost
Customer.select(:id, :name).find(123)
```

The `where` method accepts either a hash (which gets auto-escaped and formatted into Shopify's search syntax) or a raw query string for more complex filtering. Error handling works too: if you query on an unsupported attribute, the gem surfaces Shopify's validation error rather than silently failing. 

Pagination is cursor-based under the hood, as Shopify's GraphQL API requires. The gem handles this transparently:

```ruby
# Automatic pagination up to a limit
ProductVariant.where("-sku:''").limit(100).to_a

# Batch processing with explicit page control
ProductVariant.where("sku:FRZ*").in_pages(of: 50) do |page|
  page.each { |variant| process(variant) }
end

# Lazy enumeration
Customer.where(email: "@example.com").each { |c| puts c.name }
```

### Using Connections and Eager Loading

GraphQL connections (the `edges { node { ... } }` pattern) are one of the most tedious parts of working with Shopify's API. ActiveShopifyGraphQL models them as associations:

```ruby
class Product < ActiveShopifyGraphQL::Model
  attribute :id, type: :string
  attribute :title, type: :string

  has_many_connected :variants,
    class_name: "ProductVariant",
    default_arguments: { first: 10 },
    inverse_of: :product
end

class ProductVariant < ActiveShopifyGraphQL::Model
  attribute :id, type: :string
  attribute :sku, type: :string
  attribute :price, type: :string

  has_one_connected :product, inverse_of: :variants
end
```

By default, connections are lazy loaded. Calling `product.variants` triggers a separate GraphQL query only when you actually access the variants. But when you know you'll need them, `includes` lets you eager load everything in a single query: 

```ruby
# One query fetches the product AND its variants
product = Product.includes(:variants).find(123)
product.variants.each { |v| puts v.sku }  # No additional queries
```

The `inverse_of` option enables bidirectional caching. When you eager load a product with its variants, each variant already knows its parent product without making another round trip: 

```ruby
product = Product.includes(:variants).find(123)
product.variants.first.product  # Returns cached parent, no query
```

This matters because Shopify's GraphQL API has rate limits measured in query cost points: every unnecessary round trip burns through your budget. Eager loading and inverse caching let you get more data in fewer, cheaper queries.

### Bridging the GraphQL API with Your ActiveRecord Models

Most Shopify apps store some data locally in a relational database while pulling other data from Shopify's API.

ActiveShopifyGraphQL includes a `GraphQLAssociations` module that bridges the two worlds:

```ruby
class Rating < ApplicationRecord
  include ActiveShopifyGraphQL::GraphQLAssociations

  belongs_to_graphql :product
  # Expects a `shopify_product_id` column in your ratings table
end

rating = Rating.find(1)
rating.product  # Loads Product from Shopify via GraphQL using shopify_product_id
```

The convention follows a `shopify_{association_name}_id` pattern for foreign keys, but you can override it with `foreign_key:`.

Oh, and going the other direction works too: a GraphQL model can declare `has_many :ratings` to query your local database for associated records.

### Switching Between Admin and Customer Account APIs

One of the trickiest aspects of Shopify development is dealing with the Admin API and Customer Account API simultaneously. They return the same conceptual entities but with different response structures. 

ActiveShopifyGraphQL handles this with the `for_loader` block: 

```ruby
class Customer < ActiveShopifyGraphQL::Model
  graphql_type "Customer"

  attribute :id, type: :string
  attribute :name, path: "displayName", type: :string

  # Admin API: email lives here
  for_loader ActiveShopifyGraphQL::Loaders::AdminApiLoader do
    attribute :email, path: "defaultEmailAddress.emailAddress", type: :string
  end

  # Customer Account API: email lives here instead
  for_loader ActiveShopifyGraphQL::Loaders::CustomerAccountApiLoader do
    attribute :email, path: "emailAddress.emailAddress", type: :string
  end
end

# Same model, different data sources
admin_customer = Customer.with_admin_api.find(123)
account_customer = Customer.with_customer_account_api(token).find(123)

admin_customer.email    # Works
account_customer.email  # Also works, different underlying path
```

Your application code doesn't need to care which API the data came from. A `Customer` is a `Customer`. The cognitive load drops significantly when your team can reason about stable domain objects instead of tracking API-specific response shapes. 

### Loading Metafields and Custom Data

Shopify merchants rely heavily on metafields for custom product data. The gem provides a dedicated `metafield_attribute` method that handles the query generation and response parsing:

```ruby
class Product < ActiveShopifyGraphQL::Model
  attribute :id, type: :string
  attribute :title, type: :string

  metafield_attribute :boxes_available,
    namespace: "custom",
    key: "available_boxes",
    type: :integer

  metafield_attribute :seo_description,
    namespace: "seo",
    key: "meta_description",
    type: :string

  metafield_attribute :product_data,
    namespace: "custom",
    key: "data",
    type: :json
end

product = Product.find(123)
product.boxes_available  # => 24
product.product_data     # => { "weight" => "2.5kg", "origin" => "Italy" }
```

For more complex scenarios like metaobjects (Shopify's custom data models), the gem also supports raw GraphQL injection with custom transforms. This is the escape hatch for when the standard attribute mapping can't express what you need. 

### Setting Up a Shared Base Class

ActiveShopifyGraphQL allows you to configure a base class that your models will inherit from.

At Nebulab, we use this to standardize ID handling across all our models. Shopify uses GIDs (Global IDs like `gid://shopify/Product/123`), but you often need the numeric part for database lookups or URL construction:

```ruby
class ApplicationShopifyRecord < ActiveShopifyGraphQL::Model
  attribute :id, transform: ->(gid) { gid.split("/").last }
  attribute :gid, path: "id"
end

class Product < ApplicationShopifyRecord
  attribute :title, type: :string
  attribute :vendor, type: :string
end

product = Product.find(123)
product.id   # => "123" (numeric part only)
product.gid  # => "gid://shopify/Product/123" (full GID)
```

This eliminates the constant GID-to-numeric-ID conversion that plagues Shopify codebases, especially when you need to compare IDs coming from Liquid themes (numeric) with IDs from GraphQL (GIDs). 

Of course, you can also use the shared base class for custom helpers and any other logic you don't want to duplicate.

## Where the Gem Is Headed

Right now, ActiveShopifyGraphQL is read-only. Mutation support is on the roadmap but presents some challenges due to how inconsistent Shopify mutations are.

The roadmap also includes metaobject modeling as first-class models, a caching layer, advanced error handling with retry mechanisms, and rate limit management.

We'll keep building these features as the need arises in our client projects, so stay tuned for updates!

## Ready to Put the Joy Back Into graphQL?

Raw GraphQL in a growing Shopify app creates a maintenance burden that compounds over time: inconsistent object shapes, duplicated query logic, manual type coercion, and the constant mental overhead of tracking which hash key lives where.

ActiveShopifyGraphQL replaces that with stable domain models, typed attributes, and an interface that Rails developers already know.

The library is production-tested, available as a [Ruby gem](https://badge.fury.io/rb/active_shopify_graphql), and ready to drop into your existing Shopify app. Give it a try, open an issue if something breaks, and let us know what you'd build on top of it!

And if you're building a Shopify app or custom storefront and drowning in GraphQL boilerplate, we've been there. [Let's talk!](https://nebulab.com)


ActiveShopifyGraphQL: The Library That Puts The Joy Back into Shopify's GraphQL API

Andrea Vassallo

Every week, the same tension fills boardrooms across the DTC landscape. As the week closes, the gap between projected and actual revenue widens, and the instinct is always the same: sacrifice price to force volume.

Blanket discounting becomes the business model. It starts as a temporary fix (a 30% off site-wide sale to bridge a revenue gap) but quickly metastasizes into a long-term dependency. While the immediate revenue spike provides short-term relief, the hangover is severe. Margins erode, brand equity dilutes, and most dangerously, customers are trained to wait.

Strategic discounting is a powerful lever for growth; panic discounting is a slow-motion liquidation of brand value. But if your business has real discount dependency, you already know that simply stopping isn't an option. You cannot turn off the tap without crashing cash flow.

The solution isn't to stop discounting overnight. The solution is to transition strategically. This guide outlines exactly why you are stuck and provides a phased operational roadmap to recover your pricing power without destroying your business.

## The Anatomy of Brand Erosion

To build the internal case for change, you must articulate the full cost of your current strategy. It goes beyond simple margin loss; it's about the structural degradation of your business model.

### Customer Conditioning

You are training your customers to be price-sensitive. Reference price theory explains why discounts work so well in the short term: customers enter with a price expectation shaped by the market, and when your offer undercuts it, the deal feels like a win. They buy.

But here's the trap: that discounted price becomes their new anchor. The next time they see your product at full price, it doesn't feel like the actual price. It feels like a markup. You won the acquisition and lost the customer's willingness to pay.

The pattern is consistent across the DTC brands we work with: customers acquired on deep discounts buy less often, churn faster, and generate significantly lower lifetime value than full-price cohorts. You aren't just acquiring cheaper customers; you're acquiring worse ones.

### Margin Math

The math of discounting is punishing. Consider a product with a $100 price point and $55 cost of goods (a healthy 45% gross margin). At a 30% discount, the selling price drops to $70 but the cost of goods stays at $55, compressing gross profit from $45 to $15 per unit. To maintain the same gross profit dollars, you now need to sell three units for every one you used to sell at full price.

At first, discount-driven audiences are large, cheap to reach, and fast to convert. The CAC looks great on a dashboard. But you've just tripled your volume while cutting your margin per unit by two-thirds, and you've filled your customer file with buyers who were attracted by price, not by your brand. They'll wait for the next sale, and the next one, and the next one. In the meantime, your CAC will keep rising as you exhaust your in-market audience, compressing your margins more and more until you're actually losing money, not making money.

## The Alternatives to Discounting

If blanket discounts are bleeding your margins, what's the alternative? You've likely tried some of these tactics before. The difference comes down to execution discipline, not the tactics themselves. These three strategies work when applied systematically, not as one-off experiments.

### Strategy 1: Lock Cash into Your Ecosystem

Instead of giving customers 30% off that they can take anywhere, give them that value back in a form that requires them to return to your brand. This means loyalty points or store credit.

The mechanics are simple: a customer who would have received a 30% discount instead receives equivalent value as points in a loyalty program or as a credit applied to their account. The cost to you is lower due to breakage (not everyone redeems), and you maintain your reference price. A $100 product stays $100; the customer just has $30 in their account to use on the next purchase.

Store credit works particularly well for win-back flows and cart abandonment. Instead of sending a percentage-off coupon, send a $20 credit. It maintains pricing integrity and typically increases AOV, as customers often spend more to use up the credit rather than letting it expire.

Loyalty points offer similar mechanics but with more flexibility in how customers redeem. Cash-back points are the default, but you can also allow redemption for other benefits depending on your program structure. The key advantage over direct discounts is breakage and the psychological commitment to your brand that comes with an account balance.

### Strategy 2: Add Value Instead of Cutting Price

Shift the offer from price reduction to value addition. The principle is simple: give customers something that feels valuable but costs you less than a percentage-off discount.

This includes tangible additions like free shipping, extended returns, or gifts-with-purchase using slow-moving inventory. But it also includes access and exclusivity: early access to new drops, exclusive products, VIP experiences, or priority support. These carry high perceived value at a fraction of the cost of a cash discount.

Value-adds work best when the perceived value is high but the actual cost is low. Free shipping on orders over a threshold costs you the shipping subsidy but increases AOV. An extended return window costs you nothing unless the customer actually returns something. Early access costs you nothing but makes customers feel special. A GWP using dead stock turns a sunk cost into a conversion driver.

### Strategy 3: Improve Your Discount Targeting

If you're going to offer cash discounts, stop broadcasting them. The damage comes from giving discounts to people who would have paid full price. Narrow targeting protects your full-price buyers while still giving you a tool for acquisition and reactivation.

This means retiring site-wide promotional codes and homepage sale banners. Instead, send discounts only to specific audiences via email or SMS: lapsed customers who haven't purchased in 6+ months, cart abandoners, first-time visitors who didn't convert. Use unique, single-use codes tied to the recipient so the offer can't leak to your full-price audience.

The key is channel discipline. Discounts sent via direct channels (email, SMS, retargeting ads) stay contained. Discounts displayed on-site or in social posts get shared, screenshot, and distributed to people who didn't need the incentive. If a customer is already on your product page ready to buy, don't show them a discount. If they abandoned their cart or haven't returned in months, that's when the offer goes out.

Narrow targeting also gives you attribution clarity. When every offer uses a unique code, you know exactly which customers are discount-dependent and which aren't. That data becomes the foundation for further refinement.

## Pulling the Plug on Discounts

With your alternative toolkit in place, you can begin the transition. This is not about flipping a switch overnight; it's about systematically replacing blanket discounting with targeted offers and alternative mechanisms that protect margin while maintaining revenue.

### Measure the Problem

Before you change anything, you need to understand how deeply discounting has penetrated your business model. Pull 12 months of order data and calculate three metrics:

1. **Discount penetration rate**: What percentage of total orders used a discount code? This tells you how normalized discounting has become in your customer experience.  
2. **Revenue at risk**: What percentage of total revenue came from discounted orders? If the majority of your revenue required a promotional code to convert, you have a structural dependency problem.  
3. **Average discount depth**: Across all discounted orders, what was the average percentage off? A brand running 15% average discounts has a different problem than one running 35% average discounts.

These three numbers determine your transition timeline. Brands with 70%+ discount penetration and deep average discounts typically need 12 to 18 months to fully recover pricing power without cratering revenue. Brands under 40% penetration can move faster, sometimes within a single quarter. The key is matching your pace to your dependency level.

### Execute the Transition

The transition is conceptually simple: stop giving discounts to people who don't need them, and change what you give to people who do. In practice, this means progressively applying your three strategies (narrow targeting, ecosystem lock-in, and value-adds) to replace blanket promotions.

Here's what that looks like over a typical quarter:

1. **Audit your promo calendar.** List every discount you're running: site-wide sales, email blasts with promo codes, homepage banners, cart abandonment offers, welcome discounts. Calculate how much revenue each one drives. This is your baseline.  
2. **Start tightening the screws.** Remove discount messaging from your homepage. Retire one site-wide sale and replace it with targeted offers sent only to lapsed customers via email using unique codes. Swap percentage-off codes in your cart abandonment flow for store credit. Test early access against cash discounts for engaged customers.  
3. **Measure the impact and iterate.** If revenue drops too much, you moved too fast. Stabilize and try a smaller change. If revenue holds or margins improve without significant volume loss, continue tightening.

Over time, your promotional architecture shifts. Lapsed customers get aggressive win-back offers via email, but never on-site. Cart abandoners get store credit, not percentage-off codes. Loyal customers get early access and exclusive products. New visitors see full price with strong brand storytelling.

As this happens, expect revenue to stay flat or dip slightly in the short term. You're replacing low-quality volume with full-price purchases, and that's a slower build. But the composition of that revenue changes fundamentally: gross margin dollars grow because you're no longer giving away significant percentages of every other transaction, and customer quality improves as your file tilts toward buyers who don't need a coupon to convert.

## What It Looks Like on the Other Side

Eighteen months into a disciplined transition, the business looks fundamentally different. Discount penetration drops from 70% to under 30%. Gross margin per order increases by 15 to 20 percentage points. Customer cohorts acquired at full price show 2x to 3x higher LTV than legacy discount cohorts.

But the hardest part isn't the tactics. The hardest part is the internal conversation. Finance sees short-term revenue risk. Marketing sees CAC spike as you stop subsidizing acquisition with margin-destroying discounts. The executive team has to hold the line while the business rebalances.

Need help planning and building the infrastructure to execute this transition? [We can help!](https://nebulab.com/contact-us)

Stop Killing Your Margins: A Guide to Smarter E-Commerce Discounting

Alessandro Desantis

First, a disclaimer: this is NOT a feature recap. If that's what you're looking for, Shopify's [Editions site](https://www.shopify.com/editions/winter2026) is the place to be. Instead, what we're doing here is what we've done with every Edition for the last few years: analyzing what these updates actually mean for upper-midmarket and enterprise brands, where Shopify created genuine value, and what they could have done better.

In the Winter 2026 Edition specifically, AI stole the spotlight. Sidekick now generates admin apps! It generates theme sections! It supports Skills and third-party integrations! If you read the product announcements, it all feels like success is just one carefully engineered prompt away.

And truth be told, there is substance behind the hype. Shopify Magic, and Sidekick specifically, are powerful tools that are only getting more powerful. Agentic Storefronts are putting every Shopify brand in front of hundreds of millions consumers using LLMs to shop, all with a click of a button. And much-needed infrastructure improvements and platform additions (e.g., A/B testing and theme rollouts) are making life easier for merchants, developers, and consumers.

But when you evaluate these evolutions through the lens of an upper-midmarket brand moving serious volume, there are some nuances to consider. In this article, we're going to talk about those nuances, highlighting some of the biggest opportunities that still lie ahead for the Shopify ecosystem.

## Sidekick's Code Generation Is Powerful But Requires Governance

Sidekick's code generation capabilities, for both themes and custom apps, represent an interesting leap forward in operational velocity, but they're not the cure-all some industry pundits are making them out to be.

In our experience, Sidekick excels at rapid theme prototyping. It gets you to about 80% visual accuracy fast, which is valuable when testing concepts or exploring ideas quickly. But when you think about long-term maintenance, you'll run into challenges such as:

- Excessive configuration options for settings that you'll never use.
- Isolated CSS and JavaScript that doesn't use existing utilities or patterns.
- No consideration whatsoever for the build system used by your theme (if any).

Admin app generation comes with similar benefits but also similar challenges.

The app store is littered with low-quality apps solving simple problems for $9.99/month, and we're all happy to see a few of those go away. If merchants can generate custom solutions they actually own, that's a genuine win.

But without a clear governance framework, your stakeholders will start generating apps that solve very similar problems in very different ways, with no consideration of existing patterns or cross-app interactions. As this functionality expands to storefront-facing features, which seems inevitable given the direction Shopify has taken with AI code generation, the stakes will get even higher. While admin apps affect operational efficiency, storefront apps affect revenue.

Moving forward, we'd like to see Shopify invest not just in AI code generation, but also in stronger primitives and better development guidelines that guide the AI, so it can be more considerate of its surroundings and the long-term impact of its output. Shopify should also educate its merchants on proper stewardship of AI-generated functionality, helping them answer questions such as:

- Which challenges are good candidates for AI-assisted solutions and which are not?
- How do we ensure that generated code integrates with existing patterns rather than creating islands of functionality?
- When should we hand off an AI-generated solution to our engineers for polish and maintenance?

At Nebulab, we're starting to establish such processes with our clients and getting the best of both worlds: the speed of AI prototyping combined with the discipline of human oversight and integration.

Without clear handoff processes and governance frameworks, you accelerate the accumulation of technical debt rather than evolution of your store.

## Sidekick's Data Analysis Lacks Integration

Sidekick's business intelligence capabilities now come in two forms: the conversational chatbot that answers questions about your store data, and the new Pulse feature where Sidekick proactively suggests business initiatives. Unfortunately, both face the same fundamental limitations around data access and context.

For a $5M brand with a small team and straightforward operations, these tools can provide valuable direction. The suggestions might be generic, but generic advice often works when you're just starting out, your business model is simple, and your data lives primarily within Shopify.

For a $50M operation managing 1,500 SKUs across wholesale, marketplaces and DTC, coordinating 60 employees, and balancing a multi-year positioning shift against quarterly revenue targets, the calculus changes entirely. At this scale, context matters _a lot_. Generic optimization suggestions that ignore your specific constraints only create noise that your team has to filter through.

Sidekick can't tell you whether increasing email frequency will increase sales or damage your brand perception. It can't factor in that your warehouse is already at capacity and can't support that new sales channel. It doesn't know that your bestselling product line is being phased out next quarter and you should start weaning customers off of it.

More fundamentally, Sidekick is limited to the data that Shopify has. For businesses that integrate data from ERPs, warehouse management systems, customer service platforms, marketing attribution tools, and financial systems, Sidekick's view is necessarily incomplete. It sees transactions and customer behavior within Shopify, but lacks the full picture.

This is our problem with platform-specific chatbots and agents: they all only have a small piece of the truth and a small set of all the tools they could use, which prevents them from orchestrating larger business processes.

While Shopify is nice for smaller brands, we'd also like to see Shopify invest in better data portability—through official partnerships with ETL providers, data warehouses, BI tools, and external LLMs—so that the data can be integrated as part of larger operational workflows. Give enterprises the ability to bring Sidekick's analytical capabilities into environments where it has access to the full context, not just Shopify's limited view.

Without that broader integration, Sidekick is useful for surface-level insights but inadequate for strategic decisions.

## SimGym and A/B Testing: A Missed Opportunity

Shopify launched two experimentation features in the Winter '26 Edition: native A/B testing and SimGym.

Native A/B testing is new and useful. You can now natively split traffic between theme variations and measure performance differences directly within Shopify. For smaller brands without dedicated experimentation infrastructure, this means you don't have to use external experimentation platforms and lowers the barrier to entry significantly (although you will still need enough traffic to power your tests).

Still, we were disappointed that Shopify didn't launch an API that other tools could ubuild upon, like they did for example with the Subscriptions API. Instead, external A/B testing solutions will continue to use the same client-side hacks they've always relied on.

This is a shame because large-scale brands doing serious experimentation (multiple treatments, custom metrics, audience exclusions) will never be able to use Shopify's native A/B testing. Allowing third-party tools such as Shoplift or Intelligems to build upon Shopify's offering would have dramatically improved the experimentation experience for merchants (through a more seamless experience) and consumers (through faster page loads).

In addition to native A/B testing, Shopify launched SimGym, which takes a very different approach: rather than testing with real users, it uses AI to generate synthetic user behavior and predict experiment outcomes. The concept is interesting: in theory, brands could use synthetic data to run tens of experiments and move iterate much faster on their UX.

Unfortunately, research from Nielsen Norman Group and other UX practitioners has found that [synthetic users exhibit idealized behavior](https://www.nngroup.com/articles/synthetic-users/), lack the messiness of human decision-making, and produce overly optimistic results. AI-generated participants are overly agreeable and to miss the contextual nuances that shape actual behavior. In short, they're unreliable for concept testing and business decisions.

This may be a bit far-fetched, but we think Shopify missed a broader and much more interesting opportunity here.

Instead of generating synthetic predictions, imagine if Shopify had opened its A/B testing framework to third parties and then systematically collected and surfaced anonymized data about tests across its entire merchant network. With enough context about the business and the ability for the AI to understand what's being tested (i.e., not just surface metrics, but the strategic intent behind the test) Shopify could offer an invaluable best practices playbook to smaller brands and a sophisticated A/B testing engine to larger ones.

For example, a brand testing a new product page layout could receive insights like: "Among premium skincare brands with AOV above $75, similar layout changes increased conversion by 8-12% when combined with trust signals, but decreased conversion by 3-5% when the change removed product ingredient details." That's actionable intelligence grounded in real behavior seen in similar contexts.

This would have been a win-win-win for Shopify, third-party A/B testing apps, and merchants. The data would have been much more reliable than synthetic predictions and it would have been a true competitive moat for Shopify—proprietary insights that no other platform could match. Instead, we got synthetic predictions of uncertain value and a basic testing framework that doesn't serve the needs of more sophisticated merchants.

## Whatever Happened to Hydrogen?

Clearly, Hydrogen is not a focus at Shopify anymore.

If you haven't followed the story, Shopify has made some big moves in the headless space between 2021 and 2024:

- In 2021, they launched Hydrogen, their React-based framework for headless commerce experiences, and Oxygen, their platform to host Hydrogen storefronts.
- In 2022-2023, they acquired Remix and used it to rewrite Hydrogen from scratch, positioning it as a major advancement in their headless commerce strategy.
- In 2024, they announced the Hydrogen Visual Editor, an entry-level alternative to more sophisticated solutions like Sanity and Contentful.

At some point around 2024, Shopify quietly started shifting their focus from headless commerce to AI as the next big thing:

- Hydrogen's GitHub repository has seen minimal activity in the last few months. Most of it was API version updates and dependency maintenance
- The Hydrogen Visual Editor never made it past the early access phase. As far as we can see, the initiative was killed before seeing the light of day.
- The Winter 2026 Edition includes exactly _zero_ Hydrogen announcements.

Our own conversations with Shopify sources confirmed our suspicions: Shopify is discouraging brands from going headless unless they have a very strong reason to do it. In fact, they are telling Hydrogen brands to move back to Liquid.

This is not the disaster it seems. Hydrogen has always been plagued by a number of problems, most of them tied to the dynamics of the Shopify and JavaScript ecosystems rather than the framework itself:

- Most of Shopify's app ecosystem assumes that merchants use Liquid. Brands using Hydrogen often need to implement their own integrations (assuming the tool they're integrating with is kind enough to offer an API).
- While Hydrogen offers an excellent developer experience, the JavaScript ecosystem is famous for being extremely fragmented. It was not uncommon for development teams to ignore Hydrogen in favor of their preferred framework.
- Most Shopify product announcements would make it into Liquid way before making it into Hydrogen, which was a source of endless annoyance.

None of this is to say that you shouldn't go headless, if your brand is complex enough to need it. But you should know that, in 2026, headless is not the default choice anymore. Before going off the beaten path, make sure you have evaluated the pros and cons of doing so. We'll publish a much deeper dive about this in the next few weeks!

## Where To Focus Your Attention

If you're running an upper-midmarket brand, here's what actually matters from this release:

- **Use Sidekick for rapid prototyping**, but establish clear handoff processes before your team generates a dozen isolated apps solving similar problems in different ways. The speed is real, but so is the technical debt if you don't have governance in place.
- **Double check the AI's insights.** Sidekick is useful for quickly extracting raw numbers from Shopify, but it still hallucinates every now and then and it lacks important context about your business. Don't any results or conclusions at face value.
- **Adopt native A/B testing if you're only starting out**. It's a solid foundation for brands just starting to build experimentation capabilities. If you're already running complex tests with custom metrics and audience segmentation, you'll still need third-party tools.
- **Ignore synthetic data**. Synthetic user predictions are interesting in theory but unreliable in practice. If you have the traffic, run real tests with real customers. If you don't have the traffic, stick to e-commerce UX best practices until you do!
- **When it comes to headless, thread lightly**. Shopify's investment has clearly shifted elsewhere. Unless you have compelling architectural reasons to go headless, the default path is Liquid.

As always, if you need help sorting through adopting the new features or understanding what they mean for your business, [let's talk.](https://nebulab.com/contact-us)


Shopify's Winter 2026 Edition: The Needle Movers and the Missed Opportunities

Andrew Vathanakamsang

If you're running NetSuite as your ERP and Shopify as your storefront, you've probably encountered Celigo. Maybe you're new to the team and you've spotted "integrator.io" in the Shopify apps. You're wondering: how exactly does this sync orders, inventory, and customer data between our systems?

For some brands, Celigo is infrastructure that just works. For others, it's a annual expense that creates as many problems as it solves. The difference comes down to understanding what Celigo actually does, what it costs beyond the sticker price, and whether your operation genuinely needs it.

Here's how to make that call.

## What Celigo Actually Does

Celigo is an integration platform as a service (iPaaS) designed to move data between applications without writing custom code. Think of it as centralized plumbing for your tech stack—instead of building separate integrations between Shopify and NetSuite, Shopify and Klaviyo, NetSuite and your warehouse management system, you manage all those connections in one place.

The platform works through **flows**—automated processes that move data from a source endpoint to a destination endpoint. A flow might listen for new orders in Shopify via webhook, transform that data into the format NetSuite expects, and create a sales order record. Another flow might sync product data from NetSuite to Shopify every hour, ensuring your website inventory stays current.

Celigo provides several tools to build these flows:

- **Pre-built connectors** for popular applications (particularly strong for NetSuite + Shopify)
- **Visual mapping tools** to transform data from one schema to another
- **Filters and branching** to route data based on conditions
- **Lookup functions** to enrich data from additional sources
- **JavaScript hooks** for custom logic when visual tools aren't sufficient
- **Error handling and monitoring** with audit logs and alerting

The interface resembles Shopify Flow—visual, configuration-driven, accessible to non-developers. The difference is scale and sophistication. While Shopify Flow handles simple automation within the Shopify ecosystem, Celigo manages complex, bi-directional data flows across enterprise systems.

## The NetSuite Advantage

Celigo's strongest use case is NetSuite integration. The company has deep ties to NetSuite (their offices are reportedly close to each other), and their marketplace includes pre-built integration bundles for NetSuite + Shopify that handle common scenarios out of the box: order sync, inventory sync, customer sync, and fulfillment updates.

These pre-built integrations are both Celigo's biggest strength and a potential limitation.

On the strength side: they work well for standard use cases, getting you operational quickly without custom development. A typical flow might sync product data managed in NetSuite to your Shopify storefront, or push new Shopify orders into NetSuite for fulfillment. The integration handles the heavy lifting—API authentication, rate limiting, data transformation, error handling—without requiring deep technical expertise. And Celigo maintains these integrations as APIs change, which means you're not scrambling to fix broken integrations every time Shopify or NetSuite releases an update.

On the limitation side: these pre-built integrations are black boxes. You install an app, configure settings, and trust that the underlying logic works correctly. You don't have full transparency into how data flows or how edge cases are handled. When you need customization beyond what the pre-built integration supports—and most brands eventually do—you're layering custom code on top of an abstraction you don't fully control.

For brands running standard NetSuite + Shopify operations, this trade-off often makes sense. The pre-built integration handles 80% of requirements immediately, and you can customize the remaining 20% as needed. For brands with complex, highly customized workflows where the integration itself is a competitive advantage, the black box becomes a constraint.

## The Real Costs Beyond the Price Tag

Celigo's pricing is a function of the number of endpoints (applications you connect) and flows. Connect Shopify, NetSuite, Klaviyo, a CRM, and a marketplace, and you're looking at multiples of that base price.

Beyond licensing costs, there's operational overhead that doesn't appear on the invoice but directly impacts whether Celigo delivers value:

- **Ownership and expertise.** Despite marketing that positions Celigo as a no-code solution for business users, complex integrations still require technical expertise. You need someone who understands API rate limits, data transformation, error handling, and the quirks of each connected system. That person needs to read documentation, debug cryptic error messages, and make architectural decisions about data flow. The visual UI makes simple things easier, but it doesn't eliminate the need for technical competence. You're not avoiding development work—you're doing development work in a different interface.
- **Testing limitations.** Unlike custom code with unit tests and CI/CD pipelines, testing Celigo flows is primarily manual. You can use sandbox environments and clone flows for testing, but you're essentially testing in production. When you embed JavaScript hooks within flows—a common pattern as integrations grow more complex—that code typically isn't covered by automated tests. For teams accustomed to test-driven development and code review processes, this feels like a step backward. The ease of making changes in a visual interface means changes happen without the rigor you'd apply to custom code.
- **Change management and sprawl.** The ease of building flows is a double-edged sword. When anyone can create a new flow to solve a problem, flows multiply without oversight. Someone builds a new flow, the old flow gets turned off but never deleted, and six months later nobody remembers why either exists. Without discipline around documentation, review, and cleanup, Celigo becomes a sprawl of undocumented integrations that's harder to maintain than well-structured custom code. And because you're charged per connection, unused flows that remain active are literally costing you money for nothing.
- **Vendor lock-in.** The more flows you build in Celigo, the more committed you become to the platform. Migration costs grow with every integration. This isn't unique to Celigo—it's true of any iPaaS—but it's worth considering upfront. You're not just buying a tool; you're committing to an ecosystem. If Celigo's pricing changes, if the platform doesn't scale with your needs, or if you need capabilities Celigo can't provide, extracting yourself becomes expensive and time-consuming.

## When Celigo Is the Right Choice

Despite these considerations, Celigo is the right choice for many e-commerce brands. You'll know you're a good fit if:

- **You're using NetSuite.** If your ERP is NetSuite and you need to sync data with Shopify, Celigo's pre-built integrations are hard to beat. The alternative is building and maintaining custom NetSuite integrations, which is expensive and time-consuming. NetSuite's API is powerful but complex, and keeping integrations current as both platforms evolve requires ongoing development effort. Unless you have highly specialized requirements that the pre-built bundle can't accommodate, Celigo will get you operational faster and cheaper than custom development.
- **You have multiple integration points.** The value of a centralized integration platform grows with the number of connections. If you're syncing data between Shopify, NetSuite, Klaviyo, a CRM, multiple marketplaces, and a warehouse management system, consolidating those integrations in one place provides real operational value. Monitoring, error handling, and maintenance all happen in one interface instead of scattered across multiple systems. When an integration fails, you have one place to check. When you need to understand how data flows through your stack, you have one source of truth.
- **You have budget and dedicated ownership.** Celigo isn't a casual purchase, but for brands doing $50M+ in revenue where integration failures directly impact operations, the cost is justifiable. Equally important: you need someone to own the platform. This doesn't have to be a full-time role, but it needs to be someone's responsibility to maintain flows, review changes, monitor errors, optimize connections, and audit what's actually being used. Without ownership, Celigo becomes expensive shelfware that creates more problems than it solves.
- **Pre-built connectors exist for your stack.** Celigo's marketplace includes over 700 application connectors. If the vendors in your tech stack are well-represented—particularly if you're using popular e-commerce tools like Klaviyo, NetSuite, various marketplaces, and common CRMs—you benefit from pre-built integrations that Celigo maintains. If you're connecting to niche systems or building everything with universal HTTP connectors, you're doing custom development anyway. At that point, the value proposition diminishes significantly.

## When Custom Integration Makes More Sense

Conversely, Celigo is probably the wrong choice if your requirements, team structure, or workflows don't align with what the platform does best:

- **Your integration needs are simple.** If you're only syncing data between two or three systems with straightforward requirements, custom integrations or lighter-weight tools may be more cost-effective and easier to maintain. Paying for infrastructure you could build and maintain with a few hundred lines of code doesn't make economic sense.
- **You have strong in-house development capability.** Teams comfortable building and maintaining API integrations, implementing queue-based job systems, and writing comprehensive tests may find custom integrations more flexible and easier to reason about than visual flows with embedded JavaScript. If your engineering culture prioritizes code quality, test coverage, and version control, Celigo's visual interface and limited testing capabilities will feel like a constraint rather than an enabler.
- **Your workflows are highly customized.** Pre-built integrations work best for standard use cases. If your business processes are differentiated and complex—if the way you handle orders, inventory, or customer data is a competitive advantage—you'll end up customizing so heavily that you're essentially building custom integrations within Celigo's framework. At that point, the framework becomes overhead rather than value. You're paying for abstraction that gets in your way.
- **Testing and code quality are non-negotiable.** If your engineering culture requires comprehensive test coverage, code review, and version control for all business logic, Celigo's primarily manual testing approach and visual interface won't meet your standards. The JavaScript hooks you embed in flows aren't easily testable. Changes to flow configuration don't go through pull requests. You're trading control and rigor for convenience, and that trade-off may not be acceptable.

## Making Celigo Work For You

If you decide Celigo is right for your operation, success depends on treating it like critical infrastructure rather than a set-it-and-forget-it tool. Apply the same rigor you'd use for custom code:

- **Establish ownership.** Assign someone—whether an internal team member or an external partner—to own the platform. This person reviews all changes, maintains documentation, monitors errors, and ensures flows follow consistent patterns. Without ownership, Celigo becomes a free-for-all where flows proliferate without oversight.
- **Implement change management.** Don't let the visual interface create a culture where anyone can modify production flows without review. Require review before flows go live, maintain documentation for each integration, and create regular backups using Celigo's snapshot feature. Treat flow changes like code commits—document what changed, why it changed, and what the expected impact is.
- **Audit regularly.** Review active connections quarterly. Disable flows that aren't being used. Delete deprecated integrations. Connection count drives cost—keeping unused connections active is literally paying for infrastructure you don't need. We've worked with brands running 40+ active flows where only 12 were actually necessary. The rest were duplicates, abandoned experiments, or workarounds that outlived the problems they solved. Each represented both technical debt and unnecessary licensing costs. Regular audits prevent this waste.
- **Plan for testing.** Accept that testing will be more manual than with custom code. Use sandbox environments where possible, clone flows for testing changes, and maintain detailed runbooks for validating integrations after updates. When you embed JavaScript in flows, test that code in isolation before deploying it. Recognize that you're essentially testing in production, and plan your deployment process accordingly.
- **Monitor proactively.** Configure alerts for critical flows. Review error logs regularly. Integration failures are often silent—data stops syncing but no one notices until inventory is wrong or orders are missing. Proactive monitoring catches issues before they impact operations. Set up notifications for flow failures on mission-critical integrations like order sync or inventory updates.

## Making the Build-vs-Buy Decision

The build-versus-buy decision for integrations isn't primarily technical—it's strategic. Celigo works best when your competitive advantage lies elsewhere. If data synchronization is necessary infrastructure but not a differentiator, buying a platform lets you focus resources on what actually distinguishes your brand in the market.

But if your integration requirements are unique, if your workflows are a competitive advantage, or if you have the capability to build and maintain custom integrations efficiently, Celigo may add complexity without commensurate value.

The wrong answer is choosing based on what seems easiest in the moment or because NetSuite + Shopify brands just use Celigo. The right answer requires understanding your actual requirements, your team's capabilities, your budget constraints, and your long-term technical strategy.

Trying to decide whether Celigo's annual fixed cost and ongoing maintenance cost makes sense for your operation? Dealing with flow sprawl in an existing implementation? Or evaluating whether custom integration would serve you better? We help e-commerce brands make this evaluation based on their actual requirements, team capabilities, and strategic priorities. [Let's talk!](https://nebulab.com/contact-us)


Before You Buy: What Shopify Brands Need to Know About Celigo

I want to start with a confession. As a consultant, there is nothing easier than saying yes.

When a stakeholder comes to us with a tight deadline and a massive feature list, saying yes makes everyone smile. The contract gets signed, the kick-off meeting is a celebration, and the adrenaline starts pumping. It feels like momentum.

But over the years, I’ve learned that a quick yes is often the precursor to a slow, painful failure.

We work with some of the most ambitious consumer brands in the world. I talk to the stakeholders and C-level executives every day, and believe me—I know the pressure you are under. You have board members asking about Q4 projections, competitors launching new features, and a team that is already stretched thin. When you come to an agency, you aren't looking for friction; you are looking for relief.

However, the industry is full of Yes-Men agencies that will agree to impossible timelines and flashy solutions just to close the deal. They solve your immediate anxiety, but they often create a much bigger problem down the road: a fragmented customer experience, spiraling maintenance costs, and a website so bogged down by technical debt that innovation becomes impossible.

At Nebulab, we take a different approach. It’s an approach that often surprises our clients initially, but it’s also the reason they stay with us for years.

## Who's Running Your Website?

In too many brands, the digital experience is everyone's playground and no one's responsibility. The idea of a dedicated "CEO of the Website" who orchestrates this entire dance sounds great in theory, but in practice, that role is often split across five people who already have full-time jobs.

Here's what a typical week can look like when working with a fast-paced brand:

- Monday morning, the CMO pushes for a site-wide redesign of product pages—cleaner layouts, bigger imagery, more white space to elevate the brand's premium positioning.
- Tuesday, the CRO proposes an A/B test to add "Frequently Bought Together" modules and size recommendations to those same product pages to boost AOV.
- Wednesday, the CEO comes back from a board meeting: "We need to integrate our new virtual try-on tool on product pages before the investor update. They want to see us innovating with AI."

Each request makes perfect sense from the perspective of each executive. But what's completely missing is a systems-wide view of the website.

That's where we step in. Rather than jumping head-first into design and coding, we ask, "Does this ladder up to a coherent digital strategy?".

## The Trap of the Big Redesign

Let’s look at a concrete example of where a Yes-Man agency can hurt you.

Clients often come to us asking for a redesign. Perhaps their conversion rate is not where they'd like it to be, or a competitor just launched a brand new website and the FOMO is eating them alive.

For a typical agency, this is the holy grail of projects: huge scope, fat retainer, flashy portfolio piece.

Unfortunately, redesigns are also terrible for your risk profile: the more you change, the more you increase the chances that something will go wrong. And with no data to understand the impact of individual changes, it's very hard to understand what's causing the underperformance.

So, when a client asks for a new website, we lead with curiosity instead. We dig into the data, we talk to stakeholders, we talk to their customers.

What we often find is that uprooting their existing experience is too expensive and unnecessarily risky. In such cases, we advocate for a more scientific approach where we shift your budget from a high-risk gamble to a series of incremental experiments.

While certainly more boring, this approach minimizes risk while maximizing your shots-on-goal, and often yields better ROI than a six-month redesign.

## Pushback is Love

This brings me to the core of how we work. For us, consultancy is the art of benevolent pushback.

But let me be clear: this isn't about being obstructionist, and it certainly isn't about taking control of your company. You are the decision-maker. Our job is to ensure you make those decisions with your eyes wide open.

When we challenge a request, we are laying out the trade-offs:

* We warn you if a shortcut creates "technical debt" that will slow you down next year.
* We highlight if a feature bloat distracts from your core value proposition.
* We advise against rigid plans when the market data tells us to pivot.

But once we have presented the risks and offered our best counsel, it's still up to you to make the call.

And should you still decide to move forward with your original plan, well... We're happy to disagree and still commit. There's a time to challenge and there's a time to execute.

## Stewards, Not Vendors

I understand why C-levels are wary of agencies. You’ve likely been burned by vendors who over-promised and under-delivered, or who required so much hand-holding that it felt like you were working for them.

We aim for the opposite. In fact, we want to be stewards of your business.

When you hire Nebulab, you aren't just hiring a pair of hands to design pixels and write code. You are hiring a partner who will lose sleep over your conversion rates. You are hiring a team that has the experience to look you in the eye and say, "I know how much you want this feature, but if we rush it, it will break your Black Friday sale. Let’s postpone it instead."

It takes humility to serve, but it takes courage to lead. We strive to do both.

If you are looking for someone to just say "Yes," there are plenty of other agencies out there who will happily oblige. But if you are looking for someone to help you navigate the chaos, clarify your vision, and build a resilient business—[we should talk.](https://nebulab.com/contact-us)


What Your E-Commerce Agency Won’t Tell You, But Should

Michela Frecchiami

Would you buy a $2,000 cashmere sweater without understanding how the fabric drapes on your body? Would you commit to a $5,000 handbag if you couldn't see the grain of the leather or how it sits on your shoulder? For most customers, the answer is no—and that's the fundamental challenge luxury brands face online. A poorly rendered material or unrealistic fit doesn't just lose a sale—it damages brand perception in ways that take years to rebuild. 

AI-driven virtual try-on is changing this equation. Augmented reality technology has existed for over a decade, but it's only now—thanks to its combination with advanced AI—that it's reached a quality level suitable for luxury. What's changed is that recent advances in AI, particularly generative models and diffusion algorithms, have transformed AR from a novelty into a genuinely useful tool. Today's systems can render materials with near-perfect accuracy, understand body types and movements, and account for real-world lighting conditions. 

But here's the critical insight: only a seamless, intuitive, and realistic experience can actually deliver benefits. The key is **realism over perfection**—virtual try-on needs to look authentic, not artificially polished. When rendering feels too perfect or synthetic, it triggers skepticism. AR models that slow down navigation, feel clunky to use, or produce artificial-looking results create a boomerang effect—damaging brand perception instead of enhancing it.

## The Business Case: Numbers That Actually Matter

Luxury and jewelry e-commerce typically sees conversion rates of around 1.0%–1.2%, which is significantly lower than the global average of 1.4%, according to Shopify's 2024 benchmarks. Yet retailers implementing AI-powered virtual try-on and 3D/AR experiences see consistent improvements: Shopify reports show that interacting with a 3D model increases purchase likelihood by 27%, while AR interactions can drive up to a 65% lift in conversion rates. 

More importantly, returns decrease measurably—Shopify case studies report 5–10% lower return rates on products using AR visualization, while third-party aggregated studies note reductions of up to 30–40% in specific categories. For a brand selling €800 shoes or €3,000 handbags, this doesn't just reduce logistics costs—it preserves inventory value and the ability to resell items at full price. 

Consider a brand doing €50M in annual e-commerce revenue. A 40% conversion lift on a 1.0% baseline brings you to roughly 1.4%—that's potentially millions in additional revenue. A 20–35% reduction in returns on high-ticket items can save hundreds of thousands of dollars in reverse logistics and preserve margins by ensuring products are sold at full price instead of being returned, reprocessed, and potentially discounted.

## How Leading Brands Are Implementing Virtual Try-On

The brands getting this right understand that virtual try-on must embody the same principles of realism over perfection that define their physical products. Here's how leading luxury houses are approaching implementation.

![](https://cdn.sanity.io/images/kqgmf0g2/production/ac99fdc24e43fdd74d8305bb7676cff3de11dc95-1999x1070.png?fit=clip)

**Gucci** has enabled sophisticated try-on across sneakers, accessories, watches, and beauty products with meticulous attention to material authenticity. Their AR rendering accounts for ambient lighting in real-time without looking artificially perfect—the leather on a Gucci loafer reflects light differently across its surface, just as it would in person. For beauty, Gucci offers virtual try-on of lipsticks and makeup through its dedicated beauty VTO platform on mobile devices.

**Chanel** focuses on beauty and accessories, enabling customers to virtually apply lipsticks and eyeshadows with remarkable color accuracy across different skin tones and lighting conditions. This is realism over perfection in practice: Chanel's renderings preserve real skin texture rather than over-smoothing it into synthetic perfection. For eyewear, their try-on feature captures a precise fit for different face shapes—critical in a category where how frames sit on your nose bridge or temples can make or break a purchase decision. 

**Luxottica** has explored multiple angles across its eyewear portfolio, including mobile apps, in-store kiosks, and smart glasses partnerships. Eyewear is particularly well-suited for virtual try-on, as customers need to see how frames complement their face shape, skin tone, and personal style. Their in-store kiosks let customers rapidly try on dozens of frame styles, demonstrating that digital try-on doesn't replace physical retail—it enhances it.

## What It Takes to Implement Successfully

The brands that succeed with virtual try-on share three non-negotiable principles: material fidelity that captures how products actually behave, interface design that feels native to the brand, and seamless integration across the entire customer journey. These aren't optional refinements—they're the foundation that separates implementations that strengthen brand equity from those that damage it.

Rendering quality separates successful implementations from those that damage brand perception. This requires extensive 3D modeling using photogrammetry techniques that capture products from hundreds of angles. Creating these digital assets properly requires significant upfront investment: specialized equipment, skilled 3D artists, and weeks of work per product line. The goal isn't perfection—it's fidelity. 

![](https://cdn.sanity.io/images/kqgmf0g2/production/9539e7101760bf9573222e41c2f94e2d9a5301dd-1600x1052.jpg?fit=clip)

Over-polished lighting, uniform textures, and idealized proportions tend to look synthetic. Imagine a cashmere sweater rendered with perfectly even lighting and no variation in the knit—it looks like CGI, not luxury. Strong implementations capture how products behave in the real world: the way leather reflects light differently across its surface, the natural movement of knitwear on the body, and the visible nuance of shades across different skin tones. That credibility is what distinguishes luxury-grade virtual try-on from mass-market implementations.

These digital assets become valuable inventory that can be reused across try-on, product pages, and marketing campaigns. However, there's no shortcut—low-quality 3D models produce experiences that are worse than having no try-on at all.

### Interface Design Must Align with Brand Language

High-quality 3D assets are necessary but insufficient. The interface itself must translate brand codes into interaction patterns that feel native to the luxury experience—not bolted on as an afterthought.

The interface should translate brand codes into the practical mechanics of try-on:

- **For minimalist brands**: Restrained UI with discreet prompts, few controls, and visual focus on the product
- **For more expressive houses**: Editorial layers and styling context, provided they don't distract from the core decision
- **Path to action**: One-tap camera activation, effortless switching between sizes, colors, and finishes, and simple save-to-wishlist or share-to-consultation flows
- **Continuity with the rest of the site**: Typography, tone of voice, motion, and microcopy should all feel native
- **Interaction patterns**: Mirror what customers already know from your PDPs and checkout to reduce cognitive load
- **Trust signals**: Explicit permissions for camera access, visible loading feedback, and gentle haptics that confirm key actions without breaking immersion

Above all, be selective: features like social sharing or gamification should only appear when they advance the brand's intent. In luxury, sophistication is often about what you remove; keeping the surface area clean allows the craftsmanship, materials, and fit to take center stage, making the experience feel effortlessly premium.

### Mobile Performance Is Mission-Critical

Mobile drives the majority of luxury e-commerce traffic. Performance is non-negotiable. Virtual try-on on mobile presents unique challenges: smaller screens, varied device capabilities, inconsistent camera quality, and suboptimal lighting conditions. The experience must be even more refined on mobile than on desktop, with rendering quality that cannot degrade—a luxury customer browsing on an iPhone expects the same material fidelity they'd see on a desktop.

Mobile-first design means rethinking the entire flow:

- Load times under two seconds
- Seamless camera access
- Flawless one-handed navigation
- Fewer steps to activate the camera
- Larger touch targets
- Simplified controls
- Aggressive optimization for bandwidth constraints

Most implementations fail here—the technology works beautifully in controlled desktop environments, but feels clunky and slow in real-world conditions on actual mobile devices.

### The Customer Journey Must Be Unified

Virtual try-on doesn't exist in isolation—it needs to connect seamlessly across every touchpoint where customers make decisions or seek reassurance.

Virtual try-on should sit exactly where decisions are made and then carry through the journey without friction:

- **On product pages**: Entry point should be prominent but unobtrusive, with states and preferences saved to wishlists so customers can resume their shopping later or discuss their purchases with a sales associate
- **During virtual consultations**: Associates should be able to reference the same try-on view to offer precise fit and styling advice, recreating the intimacy of a boutique experience at a distance
- **In-store**: Pre-built shortlists from at-home sessions can accelerate fittings and boost confidence
- **Behind the scenes**: Tying try-on engagement to personalization, size guidance, and CRM—always with explicit consent—turns a single interaction into a coordinated, cross-channel experience that feels like a natural extension of the brand

### Accessibility Is Non-Negotiable

Credible try-on must perform consistently across diverse customers—not just the narrow demographic often used in technology testing. This isn't just ethical; it's essential to building confidence and reducing returns across your entire customer base.

Requirements for inclusive virtual try-on:

- **For beauty**: Rigorous shade and undertone modeling that accounts for different lighting and camera conditions, with calibration that avoids over-smoothing and preserves real texture
- **For eyewear and jewelry**: Precise scaling, fit guidance, and clear, non-technical explanations that help users understand how size and proportion translate from screen to real life
- **Multiple modes**: Camera-on self try-on, try-on on models with similar features, and accurate static previews for customers who prefer not to use live AR
- **Navigation support**: Ensure each mode can be navigated with keyboard and screen-reader support
- **User control**: Transparent controls to adjust lighting, skin tone matching, and fit markers, so users can fine-tune results to their context rather than accept a one-size-fits-all output

Investing here is both the right thing to do and good business: it reduces friction, broadens reach, and builds trust with audiences often underserved by generic experiences, while improving confidence in purchase decisions and, ultimately, lowering return rates.

## Measuring Success Beyond Conversion Rates

Evaluating the success of virtual try-on requires a connected narrative that ties commercial impact to experience quality and brand equity. In luxury, it can be the right trade-off to accept slightly lower short-term conversions if the experience feels more authentically premium and strengthens brand equity over time. This is the most important tension to understand: **brand perception and conversion aren't always aligned, and in luxury, brand perception often matters more.**

Start with the financials to confirm tangible value—conversion rate lift, return-rate reduction, and AOV growth—then use experience signals to explain why those outcomes occur. Post-interaction surveys should assess whether the experience elevated brand perception, not just whether it drove conversions. 

Track the metrics that reveal whether virtual try-on is reinforcing your luxury positioning:

- **Engagement depth**: Time spent in try-on, number of products and variants explored, completion of key actions such as saving to wishlist or adding to cart
- **Downstream behaviors**: Do users who engage with try-on have higher LTV, lower return rates, or greater repeat purchase frequency?
- **Cross-channel continuity**: In-store visits that reference an at-home try-on shortlist demonstrate how digital confidence translates into physical conversion
- **Brand outcomes**: Pair pre/post brand perception scores (quality, innovation, trust) with sentiment from social and customer service that explicitly references try-on
- **Material authenticity correlation**: Analyze whether improvements in perceived fit and material authenticity correlate with reduced returns and higher AOV

When these layers align—stronger brand scores, deeper engagement, and better unit economics—you have the connective tissue that shows virtual try-on is not merely lifting conversion, but reinforcing the luxury positioning that sustains pricing power and long-term value.

## Technology Should Serve the Brand, Not Define It

AI-driven virtual try-on isn't a trendy feature—it's a tool to increase customer confidence, reduce returns, and strengthen brand positioning. But only when implemented with the same attention to detail that luxury brands apply to every other customer touchpoint. The brands succeeding with virtual try-on share a common principle: technology should serve the brand experience, never define it. The technology should feel invisible, allowing the product and brand to remain center stage. 

The gap between leaders and followers will only widen as technology continues to evolve. Brands that invest strategically now in high-quality implementations will establish competitive advantages that become increasingly difficult to replicate. But implementation quality matters far more than speed. A poorly executed virtual try-on can do more harm than not having one at all. 

The key is finding the right balance between innovation and brand integrity, between cutting-edge technology and timeless luxury values. When you strike that balance, virtual try-on becomes more than a feature—it becomes an extension of what makes your brand special. 

**Need help implementing a virtual try-on experience that actually serves your brand?** Let's discuss creating an experience that maintains your luxury positioning while delivering tangible business results.

Why Luxury Brands Are Betting on AI-Powered Virtual Try-On

Massimiliano Lattanzio

For a DTC brand, a well-designed customer portal directly impacts whether customers stay or churn. [Self-service portals can resolve 40-70% of support tickets](https://www.richpanel.com/blog/customer-self-service) without agent intervention, and customers using portals report [68% fewer delays](https://read.spryker.com/rise-of-self-service-portals-in-b2b-aftersales) compared to those relying on traditional support channels. When customers can manage subscriptions, track orders, update preferences, and handle returns without friction, they're more likely to stay engaged with your brand.

Unfortunately, the Shopify customer portal landscape is fragmented. You're choosing between three competing approaches—Shopify's native Customer Accounts with UI Extensions, app-provided portals from your subscription and loyalty vendors, or a custom-built solution. Each comes with different technical constraints, maintenance costs, and UX limitations. Choose the wrong approach, and you're either locked into a fragmented experience that erodes trust, or committed to a custom build that requires ongoing investment without clear ROI.

From our work building customer portals for mid-market and enterprise DTC brands, we've seen how this decision plays out. Below, we'll walk through each approach—what it offers, where it falls short, and which business models it actually serves—then give you a framework for choosing the right one based on your retention strategy, technical resources, and growth stage.

## Shopify's Native Approach: Low Maintenance, Limited Control

Shopify's Customer Accounts and Customer Account UI Extensions offer the most "Shopify-native" way to build a customer portal today. [Launched in January 2023 and opened to app developers in December 2024](https://gadget.dev/blog/understanding-new-customer-accounts-what-they-are-and-how-to-build-with-them-as-a-developer), this approach represents Shopify's strategic shift toward extensibility—the same philosophy behind Checkout UI Extensions. Instead of letting merchants hack together solutions with Liquid code and app embeds, Shopify is creating a controlled, composable environment where functionality comes from modular blocks.

This approach lets you extend Shopify's own customer account area by adding custom pages and blocks, either built by your team or provided by apps. You can mix native Shopify features—like order history, self-serve returns, and account details—with custom-built extensions that enhance the experience. Think of it as Shopify providing the foundation and letting you furnish the rooms.

<figure>
  <img src="https://cdn.sanity.io/images/kqgmf0g2/production/83b029500d7b7e40498513ec3986255954318df6-3054x1548.png?fit=clip">
  <caption>The Customer Account portal with some custom blocks</caption>
</figure>

**Pros:**

- **Shopify-native UX:** Your portal inherits Shopify's secure, modern interface and authentication system, including passwordless login via Shop Pay (already familiar to [150+ million users](https://www.shopify.com/blog/introducing-customer-account-extensions)).
- **Built-in functionality:** Includes order tracking, self-serve returns, and address management out of the box.
- **Easy integration with apps:** Apps that have built UI extensions plug directly into this framework with no custom integration work.
- **Lower maintenance overhead:** Less need to handle authentication, hosting logic, or security updates—Shopify manages the infrastructure.

**Cons:**

- **Limited design flexibility:** You're constrained by Shopify's layout and component structure. [You can't override CSS](https://shopify.dev/docs/api/customer-account-ui-extensions/latest) or create truly custom interfaces.
- **Incomplete app ecosystem:** This is the real challenge. While Shopify is clearly investing in this architecture, many apps still rely on legacy customer portals. If you're using Recharge for subscriptions, Yotpo for loyalty, and Loop for returns, you'll need to wait for each vendor to build UI Extensions—or accept that parts of your customer experience will still live outside this unified system.
- **Migration complexity:** If you're already using legacy app portals, switching to Customer Account UI Extensions means either convincing every app vendor to rebuild their integration or abandoning apps that won't migrate. This isn't a flip-the-switch upgrade.

**Best for:** Merchants who want a low-maintenance, secure, and scalable solution that stays aligned with Shopify's roadmap, and who can accept design constraints in exchange for reduced technical overhead. This works especially well if you're building a new store or using apps that have already adopted UI Extensions.

## App-Based Portals: Fast Setup, Fragmented Experience

Many Shopify apps—subscription managers like Recharge, loyalty programs like Yotpo, returns systems like Loop—offer their own customer portals. These can be embedded in your theme as standalone pages, theme blocks, or even full-page portals hosted by the app.

Each app manages its own UI and logic, often linking back to Shopify data via APIs. This approach is quick to set up and requires minimal coding, since most apps handle their own authentication and interface. For brands with a single dominant use case—say, a subscription business where 80% of customer portal activity is managing subscriptions—this can work well.

<figure>
  <img src="https://cdn.sanity.io/images/kqgmf0g2/production/6426d83b66f28ee54d2d46b860280e2a550c0651-3054x1992.png?fit=clip">
  <caption>An example of the Customer Portal offered by Loop, a popular returns app. Everything is configurable from the app itself, without the need for custom integrations</caption>
</figure>

**Pros:**

- **Fast and easy setup:** You can launch a customer portal experience within hours or days, not weeks.
- **Low technical overhead:** App developers handle updates, security, and UI improvements. You're essentially renting functionality.
- **Modular flexibility:** You can add or remove apps without major rework, though this comes with trade-offs (see cons).

**Cons:**

- **Fragmented experience:** This is the killer. Each app renders its own UI, often with different design patterns, navigation structures, and even login flows. A typical DTC brand using Recharge, Yotpo, and Loop might send customers to three different portals, each with different visual styles and interaction patterns. One might use a sidebar navigation, another a top nav, and a third might be a full-page takeover. **Your customer has to learn three different interfaces just to manage their relationship with your brand.**
- **Limited branding control:** Most app portals offer basic theming—colors, logos, fonts—but you can't deeply customize the layout or UX. You're working within the app's design system, not yours.
- **Customization challenges:** If you want to modify these experiences beyond what the app allows, you're either stuck or you're adding brittle workarounds (custom CSS injections, JavaScript hacks) that break when the app updates.

**Best for:** Brands that prioritize speed and simplicity over control, especially small to mid-sized stores using multiple apps that already provide customer-facing features. This is also a strong fit for brands with a single dominant use case—like subscription management—where one app portal handles 80%+ of customer needs and fragmentation is less of an issue.

## Custom Builds: Total Control, Ongoing Investment

The third option is to build your own custom customer portal, either as part of your Shopify theme or as a standalone web application.

This approach involves creating a bespoke interface that connects to Shopify's Storefront API, Admin API, or third-party app APIs. It can live within your existing theme or as a separate site (for example, a subdomain like `account.yourstore.com`) that shares your brand's design system.

For example, you might use Shopify's APIs to fetch customer order history, connect with Recharge for subscription management, integrate with a loyalty program through their API, and layer on custom features—all inside one unified dashboard that looks and feels like your brand.

<figure>
  <img src="https://cdn.sanity.io/images/kqgmf0g2/production/596588599489991f20af764f6fd490ad424dad89-3054x1992.png?fit=clip">
  <caption>The custom customer portal we built for Cometeer. It connects with Recharge APIs to manage subscription data and exposes several custom-built functionalities, including a bespoke coffee box management experience powered by their proprietary recommendation algorithm.</caption>
</figure>

Cometeer needed a custom portal because their business model demanded it. **They required a completely bespoke coffee box management experience that would leverage their custom recommendation algorithm—something no off-the-shelf app could provide.** They also found Recharge's out-of-the-box portal too slow and cumbersome for their customer experience standards. [Read the full Cometeer case study](https://nebulab.com/case-studies/cometeer) to see how a custom portal became a competitive differentiator.

**Pros:**

- **Total flexibility:** Design and implement every interaction, layout, and integration exactly how you want. Your portal becomes an extension of your brand, not a compromise.
- **Unified experience:** Bring data from multiple apps and systems into one branded interface. Your customer sees one cohesive experience, not a patchwork of app UIs.
- **Full ownership:** Control your roadmap, UI, and data flows. You're not waiting for app vendors to add features or fix bugs—you build what you need, when you need it.
- **Performance optimization:** You can optimize load times, interactions, and mobile experiences in ways that app-based portals don't allow.

**Cons:**

- **Higher development cost:** Building a custom portal requires significant upfront investment in design, development, and testing.
- **Integration complexity:** You depend on whether each third-party app exposes the APIs you need. You're betting that Recharge, Loop, or your other vendors will maintain stable APIs and won't sunset features you've built against.
- **Maintenance overhead:** Every API update, Shopify version change, or app deprecation can require adjustments. You need ongoing developer resources—either in-house or via an agency—to keep the portal running smoothly.

**Best for:** Brands with strong technical resources (in-house or via an agency) who see the customer portal as a strategic differentiator and want a fully unified experience across all post-purchase touchpoints. This is especially relevant for subscription businesses or brands with products that require rich after-care and ongoing customer education.

## How to Choose the Right Approach

Choosing how to build your customer portal comes down to balancing control, complexity, and cohesion. But more fundamentally, it comes down to how you think about retention.

If your products are typically one-time purchases with minimal post-sale engagement, you probably don't need a sophisticated portal. The app-based or Shopify native approach will serve you fine, and you can scale to nine figures and beyond with a standard experience.

But if you're running a subscription business, selling products that require ongoing education or support, or competing in a category where retention is the primary growth lever, then your customer portal is a retention engine, not just a commodity. In those cases, the investment in a custom or hybrid solution often pays for itself through reduced churn and increased lifetime value.

Here's a practical framework:

| Your Situation | Best Fit |
| --- | --- |
| You want to launch quickly with built-in features and minimal technical overhead | Shopify Customer Accounts + UI Extensions |
| You're using multiple apps, want minimal coding, and can accept some fragmentation | App-provided portals |
| You need a cohesive, fully branded experience and have technical resources | Custom-built portal |
| Your business model depends heavily on retention, subscriptions, or ongoing customer education | Custom-built portal |
| You want flexibility with lower maintenance than a full custom build | Hybrid approach (UI Extensions + custom theme work) |

In our experience, the app-based approach works well for early-stage brands or those with simple needs, but because of the poor and fragmented UX it creates for the customer, it's rarely a long-term solution for brands where retention is a primary growth driver 

## Your Portal Strategy Reflects Your Retention Strategy

As you've seen, there is no universally right approach to building your customer portal in Shopify:

-  Shopify's native Customer Accounts offer a secure, low-maintenance foundation that will get richer as Shopify continues investing in extensibility. 
- App-based portals provide speed and simplicity but often at the cost of fragmentation. 
- Custom builds deliver total control and unified experiences but require ongoing investment.

The right choice depends on your business model, your technical resources, and how central post-purchase experience is to your retention strategy. The only wrong answer is ignoring the decision until customer complaints force your hand.

If you're unsure which approach best fits your brand, or if you need help evaluating the trade-offs and implementing a customer portal that turns retention into a competitive advantage, [let's talk](https://nebulab.com/contact-us). We can help you design a customer account experience that delivers results and exceeds your customers' expectations.

Customer Portals in Shopify: Understanding Your Options

Your potential customers are beginning to have conversations about your products with AI assistants like ChatGPT, Gemini, and Perplexity. When someone asks “What are the best wireless earbuds under $200 for running in all weather?” they’re getting instant recommendations complete with comparisons, specs, and reasons why.

[Nearly 60% of consumers](https://news.darden.virginia.edu/2025/06/17/nearly-60-use-ai-to-shop-heres-what-that-means-for-brands-and-buyers/) now use AI to help them shop, with [over half of Gen Z already using AI for product discovery](https://www.salesforce.com/news/stories/consumer-shopping-ai-trends-2025/).

This shift creates a new challenge for e-commerce brands: Generative Engine Optimization (GEO), the discipline of increasing your visibility within AI-powered discovery tools. Unlike traditional SEO, where you can pull up Search Console and see exactly where you rank, AI discovery is opaque. There’s no dashboard tracking how often ChatGPT mentions your brand, and no confirmed ranking factors. In other words, no one really knows what makes one brand show up over another.

Yet some brands consistently appear in AI responses while others don’t, and the industry is starting to make educated guesses about why that is.

In this post, we’ll focus on the high-level strategies for improving your AI visibility across platforms. We’ll explore the foundational tactics that work today and are most likely to continue to work tomorrow, regardless of how AI commerce evolves.

(Note: We’ll dive deeper into ChatGPT’s Instant Checkout feature and what it specifically means for Shopify brands in a separate, more technical post soon—stay tuned!)

## Setting Realistic Expectations About AI Commerce

Before diving into tactics, it’s important to understand where AI-powered commerce actually stands today versus where industry hype suggests it might be.

While nearly 60% of consumers report using AI to help them shop, usage doesn’t yet translate to transactions. A [comprehensive study of 973 e-commerce websites](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5585812) analyzing 12 months of data (August 2024 — July 2025) with $20 billion in combined revenue reveals that organic LLM traffic currently:

- **Represents less than 0.2% of total e-commerce traffic**—roughly 200 times smaller than Google’s organic search
- **Converts at lower rates than all traditional channels except paid social**, including underperforming organic search, paid search, email, and direct traffic
- **Generates lower revenue per session** than established channels across the board
- **Shows favorable engagement signals** (like bounce rate, indicating relevance) but **shorter session durations and fewer page views**, suggesting users are still learning to trust AI recommendations

**The good news:** The same research shows conversion rates from AI traffic are improving over time, suggesting the channel is maturing even if slowly. The performance gap is narrowing, though [projections indicate it won’t reach parity with organic search within the next 12 months](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5585812). This is a trend that will only accelerate with ChatGPT’s recent release of Instant Checkout.

In other words, GEO should be viewed as a long-term investment in future discoverability, not an immediate revenue channel. You’re building positioning for when—not if—AI-powered shopping reaches mainstream adoption. The brands that establish authority now will have significant advantages when the channel matures, but don’t expect meaningful traffic or conversion impact in 2025.

Think of this as 2005-era SEO: the fundamentals you build today will compound as the channel matures. The brands that act now—while the channel is still developing and the playing field is relatively open—will likely dominate their categories once adoption reaches critical mass.

## Measuring Your Share of Answer

Before you can improve your AI visibility, you need to understand where you currently stand. But unlike with Google’s Search Console, there’s no dashboard showing how often your brand appears in AI responses.

The solution is a surprisingly trivial “Share of Answer” approach. Here’s how it works.

Start by creating a comprehensive list of 25-50 prompts that represent how customers discover and research products in your category. If you’re struggling to generate this list, consider enlisting an LLM to help: you can provide context about your product category, target audience, and typical customer journey stages, and ask it to generate relevant queries. These should span different stages of the shopping journey:

- For product discovery, include queries like “Best laptop for graphic design students” or “What mattress should I buy for back pain?”
- For comparison and research, test prompts such as “[Brand A] vs [Brand B] comparison” or “Alternatives to Popular Product X.”
- For problem-solution matching, try “What helps with back pain while working from home all day?” or “How to choose the right standing desk.”

Once you’ve built your query set, it’s time to test your LLM by asking it each of the queries you’ve come up with. We recommend testing with ChatGPT, which [holds over 60% of the AI assistant market](https://gs.statcounter.com/ai-chatbot-market-share) and [ranks among the top 10 most visited websites globally](https://www.similarweb.com/website/chatgpt.com/). While it’s worth periodically checking other platforms like Gemini, Perplexity, and Claude to understand the broader landscape, your measurement and optimization efforts should center on where your customers actually are—and right now, that’s predominantly ChatGPT.

Calculate your Share of Answer score: the percentage of relevant queries where your brand receives at least one mention. The scoring breaks down like this:

- **Below 20%:** You’re invisible to the AI. Most queries in your category don’t mention your brand at all.
- **20-40%:** Limited presence. You appear occasionally, but competitors dominate most conversations.
- **40-60%:** Competitive visibility. You’re in the mix, showing up regularly alongside other established players.
- **60-80%:** Category leadership. You appear in most relevant queries, often with favorable positioning.
- **Above 80%:** You dominate AI discovery and are the go-to reference in your space.

When testing each prompt, don’t just check whether your brand appears. Document where it appears in the response, how it’s described, which competitors are mentioned alongside you, and what sources the AI cites. Context matters because it shapes how people perceive your brand.

This baseline becomes your benchmark. Without it, you’re making changes without knowing what’s working. With it, you have a clear starting point and a way to track progress over time.

## Prioritize Product Information Completeness

AI systems strongly prefer brands with detailed product specifications, clear imagery, accurate pricing and availability, comprehensive size guides, and compatibility information. Products with incomplete information are frequently skipped entirely, even from well-known brands.

Think of product data as table stakes. Without structured, complete information, LLMs have a much harder time understanding or recommending your products. To fix that:

- **Complete your specifications.** Every product should have comprehensive details covering dimensions, materials, compatibility, and performance characteristics. Include all details that help customers (and chatbots!) make confident decisions. As an example, if you sell a a standing desk, that means not just height range, but weight capacity, motor type, noise level, and cable management features.
- **Improve your imagery.** High-quality images showing products from multiple angles and in use help both customers and AI systems understand what you’re selling. Include lifestyle shots that demonstrate use cases, detail shots that highlight key features, and size comparison images that provide context.
- **Ensure pricing transparency.** Accurate product pricing, taxes, shipping costs, and availability clearly stated helps AI systems recommend products that customers can actually purchase.
- **Add detailed size and fit information.** For apparel, furniture, and any product where fit matters, comprehensive size guides are essential. Include measurements, fit guidance, and ideally customer photos showing the product on different body types or in different spaces.

Start with an audit of your top products. Where are the gaps? What information is missing or outdated? Prioritize fixing the products that drive the most revenue or that represent your brand in competitive searches. Then expand systematically across your catalog.

## Create Educational Content That Demonstrates Expertise

Educational content demonstrates genuine expertise in ways that product pages can’t. When you publish in-depth guides, detailed comparisons, and thoughtful how-to content, you signal to LLMs that you understand your space deeply, and you’re more likely to show up in long-tail queries.

- **Write comprehensive buying guides.** Address the real questions customers have when choosing products in your category. Not just “which product is best” but “what should I consider?” and “how do different features impact performance?”
- **Answer technical questions thoroughly.** If customers in your category wonder about compatibility, installation, maintenance, or optimization, create content that addresses these topics with real depth. Surface-level answers won’t do, as LLMs tend to prioritize sources that go deep.
- **Create comparison content.** Develop honest comparisons that help customers understand tradeoffs between different product types or approaches. When you can fairly compare alternatives in your category, you build credibility with both humans and machines.
- **Document use cases and applications.** Show how products work in real situations. Case studies, setup guides, and application-specific content help AI systems understand not just what you sell, but how and when customers should use it.

Start with your most frequently asked questions. What do customers want to know before buying? What problems are they trying to solve? What comparisons do they make? Create content that answers these questions comprehensively, and you’ll naturally build the educational foundation that AI systems look for.

## Build Authority Through Authentic Engagement

The tough truth about GEO is that your website is just one data point. What matters more is what the rest of the internet says about your brand.

LLMs train on and reference content from across the web. Even though [ChatGPT is citing Reddit less nowadays, ](https://www.investors.com/news/technology/reddit-stock-chatgpt-advertising-google/?utm_source=chatgpt.com) Reddit content is likely to still carry heavy weight in core model training. The same goes for YouTube videos showing your products in action, or social media content that demonstrates real customer satisfaction with your brand.

When your brand shows up consistently across Reddit, YouTube, industry publications, social platforms, and other sources, ChatGPT notices. It’s looking for patterns of trust across multiple sources. One mention is just noise. Ten consistent mentions across different platforms are signal.

- **Encourage authentic customer sharing.** Make it easy and natural for satisfied customers to share their experiences. Send post-purchase emails with prompts like “How are you using your new standing desk? We’d love to see your setup!” Include shareable moments in your product experience—unique unboxing, thoughtful packaging notes, or surprising product features that make people want to post.
- **Participate meaningfully in community discussions.** Find where your customers congregate online (e.g., industry forums, Reddit communities, Facebook groups) and find ways to amplify those channels. In some cases, this might mean contributing directly. In others, it will mean fostering the organic contributions that already happen (e.g., Reddit is notoriously hostile to brands hijacking the conversation).
- **Create shareable resources.** Develop tools, calculators, guides, or templates that others want to reference and link to naturally because they’re genuinely useful. An ergonomic desk setup calculator, a home office lighting guide, or a remote work productivity toolkit: these resources get shared, cited, and linked to organically, building the distributed presence that LLMs will recognize.

In other words, focus on building genuine value where your customers already spend time. The visibility will follow naturally.

## Monitor Your Progress and Iterate

Just like SEO, GEO isn’t a one-time project, but rather an ongoing practice that requires regular measurement and iteration. The AI landscape evolves quickly, and what works today may need adjustment tomorrow:

- **Re-run your Share of Answer analysis quarterly**. Track how your optimization efforts are actually impacting AI visibility. Use the same query set you established in your baseline, but don’t be afraid to add new queries as customer behavior evolves or as you expand into new product categories.
- **Track quality, not just quantity.** Look not just at whether your Share of Answer score is improving, but at how the nature of your mentions is changing. Are you appearing earlier in responses? Are the descriptions more accurate? Are you being mentioned alongside stronger competitors?
- **Test new approaches systematically.** When you hear about a new tactic or strategy, don’t just implement it everywhere. Test it on a subset of products or categories, measure the impact on your Share of Answer, and expand only if you see positive results. A disciplined approach prevents wasted effort on unproven tactics.
- **Document what you learn.** Keep a log of changes you make, results you observe, and patterns you notice. Over time, you’ll build institutional knowledge about what works for your specific brand, category, and customer base. This documentation will be invaluable when new team members join or when you need to justify continued investment.

Rather than implementing every possible tactic, you’ll want to systematically improve your Share of Answer score over time while building assets that serve customers across all discovery channels.

## Building AI Visibility Is Building Future-Proof Discovery

As covered in the expectations section above, AI-powered product discovery is still early-stage but showing clear momentum. The trajectory is undeniable: [Gartner predicts that traditional search engine volume will drop 25% by 2026](https://www.gartner.com/en/newsroom/press-releases/2024-02-19-gartner-predicts-search-engine-volume-will-drop-25-percent-by-2026-due-to-ai-chatbots-and-other-virtual-agents), and conversion rates from AI traffic are [steadily improving over time](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5585812).

This creates a strategic window. The brands that build AI visibility now—while the channel is still developing—will likely dominate their categories once adoption reaches critical mass.

To do that, start with your baseline measurement, then systematically work through product data completeness, educational content creation, and authentic engagement. Finally, monitor quarterly and iterate based on what you learn. The approach is straightforward, but it requires commitment—a trait that is quite rare in an industry that tends to be very short-term oriented.

Need help navigating this transition? At Nebulab, we work with mid-market and enterprise e-commerce brands to build the technical infrastructure that drives visibility across all discovery channels—including emerging AI channels. We take a pragmatic, data-driven approach to GEO that balances long-term positioning with near-term ROI from your core acquisition channels. We can help you measure your baseline, prioritize optimization opportunities, and build a systematic approach to GEO that integrates with your broader e-commerce strategy. [Get in touch](https://nebulab.com/contact-us/) to discuss how we can help your brand show up in the conversations that matter most.

The Early Mover’s Guide to AI Product Discovery

Replatforming is one of those moments that can either unlock a step-change in organic growth—or erase years of SEO equity overnight. 

A new commerce stack can improve speed, flexibility, and long-term maintainability. It most likely also breaks URL structures, buries content, and confuses search engines at scale. A 20–40% traffic dip in the first months after launch isn’t unheard of when fundamentals are missed, and the revenue impact can be painful. The upside, though, is equally real: treat SEO as a first-class citizen throughout the migration and you can come out with faster pages, cleaner architecture, and a stronger growth engine than you started with. 

As we repeat as a mantra, and it applies to every aspect of a migration, especially with SEO, to try to change as few things as possible during the migration, and patiently wait until the improvements are easy and safe to implement.

This guide blends hard-won lessons from complex e-commerce migrations with practical checklists you can use right now. We’ll cover the technical foundations *and* the organizational dynamics that make or break replatforms. Because SEO fails less often in code editors than in project plans.

## Pre‑Migration Audit & Benchmarking

### Establish a Baseline Before You Move Anything

If you can’t describe exactly how your site performs today, you can’t diagnose what changed tomorrow. Start with a thorough SEO audit and a shared benchmark doc that the stakeholders agree to protect.

At minimum, benchmark:

- **Traffic & revenue baselines:** Segment by channel (organic/non-brand vs. brand), device, market, and key templates (home, category/PLP, product/PDP, content hubs, blog, help center). Tie organic sessions to revenue where possible.
- **Rankings and visibility:** Track head terms and long-tail queries per template, Capture average ranks and note which terms drive conversions.
- **Crawl data & index footprint:** Export from your crawler and Google Search Console. Inventory indexable vs. non-indexable pages, canonicalized duplicates, parameterized URLs, pagination, and index bloat.
- **Top-performing pages and link equity:** Identify the top 10–20% of URLs that drive 80% of organic value. Map internal links to these pages and log external links you must preserve.

Document technical debt you plan to fix on the new stack: render-blocking scripts, slow templates, thin content, overlapping intent, and legacy parameters. Include dates on every report to ensure post-launch comparisons are apples-to-apples.

## URL Mapping & Redirect Strategy

### One-to-One Redirects Are Non‑Negotiable

Your URL structure is your site’s skeleton. Change it without a precise redirect plan and the body collapses. For any URL that changes, implement **one-to-one 301 redirects** from the old canonical to the new canonical. Avoid chains and loops; every additional hop dilutes signals and slows users down.

**Homepage and category dumps are rank-killers.** Blanket-redirecting old PDPs to the homepage (or to their parent category) is a fast path to irrelevance. Search engines treat irrelevant redirects like soft 404s—you don’t preserve equity, and users bounce because intent isn’t met.

### Practical Tips for Redirect Excellence

- **Build the map early.** Start from your top-value URLs and work down. Include query parameters that resolve to unique content (e.g., `/size=xl` may be ignorable; `/color=navy` may map to a canonical color page if that’s how your new platform works).
- **Normalize everything.** Decide on trailing slashes, case sensitivity, and default file extensions. Enforce consistently to prevent duplicate paths.
- **Keep UTMs safe.** When implementing your redirects, be sure you are not removing UTMs (or any other query params) from the URLs, otherwise you might compromise attribution tracking.
- **Test before launch.** Validate your redirect file in staging with a crawler. Check for 200/301/404 distributions, chains, loops, and relevancy (old product → closest new product or guide).
- **Deploy at the edge.** If possible, run redirects at your CDN/edge layer for speed and reliability.

### Treat Content as the Oxygen of SEO

During migrations, content gets “cleaned up” or rewritten. That can be good—but accidental pruning is common. Titles, H1s, product descriptions, and alt text are easy to strip when templates change. Structured data is often left behind or auto-generated with gaps. If there are content mistakes that can be addressed along with the migration, stop doing it and take a note for later. Again, it’s better not to change too many things together; otherwise, it will be hard to understand where SEO issues originate. 

### What to Preserve—and Improve

- **Metadata parity:** Ensure title tags, meta descriptions, H1s, and canonical tags carry over. Where templates change, confirm variables resolve correctly (e.g., brand + model + key attribute).
- **On-page copy and attributes:** Preserve unique product copy, comparison tables, FAQs, and reviews. Standardize units and naming conventions to avoid duplicate content from near-identical variants.
- **Media and alt text:** Maintain image URLs where feasible, or redirect them. Keep descriptive alt text for accessibility and image search.
- **Structured data:** Recreate JSON-LD for Product, Breadcrumb, Review, Article, FAQ, and Organization. Validate with Google’s Rich Results Test and ensure parity with visible content.

**Manual review is mandatory.** Pick the top 50–200 URLs by organic value across templates and review them page-by-page in staging. Look for lost copy chunks, missing schema, and new UX that hides or defers critical information. If something feels “lighter,” it probably is.

## Technical Considerations

### Replatforming Is a Chance to Upgrade, Not Just Replicate

Perfect preservation isn’t realistic. Your new platform will bring its own SEO opinions, often better than what you had before, and some of them are non-negotiable. Shopify’s URL structure, as an example, is fixed. That’s not a threat; it’s a constraint you can leverage. Treat these standards as a built-in upgrade path: use the move to clean up crawl paths, modernize rendering, and lift Core Web Vitals where possible. The key here is balancing touching only things that have a real impact or are in a no-risk zone. Some examples:

**Robots & index controls:**

- Align **noindex** and **canonical** rules to your new architecture. If you consolidate filters or change pagination, update rel=“prev/next” strategies and canonicals accordingly.

**Sitemaps:**

- Generate clean, modular XML sitemaps (≤50k URLs per file) by template and locale. Exclude noindex/redirecting/404 URLs. Host them on the primary host and reference them in `robots.txt`.

**Rendering & performance:**

- Prefer SSR or SSG for content-critical templates; hydrate interactivity progressively. Ensure your SPA routes are indexable and expose canonical, meta, and schema on initial HTML;
- Use the migration to improve **Core Web Vitals**. Compress and lazy-load media, reduce JS bundle size, and adopt modern image formats. Measure template-by-template rather than sitewide averages.

**Internationalization:**

- If you operate in multiple locales, validate `hreflang` across the new structure. Misaligned language-region pairs or missing return tags can throttle international visibility.

## Pre‑Launch Testing

### Treat Staging Like Google

Your staging environment is where good intentions meet reality. Crawl it with enterprise-grade tools and with Googlebot-like settings. The goal: catch anything that could impair discovery, understanding, or measurement. 


> In Shopify, crawling a store has been historically a problem, as the platform was failing to distinguish genuine and controlled crawls and malicious bots. They recently released an update to allow SEO specialists to use [Web Bot Auth](https://datatracker.ietf.org/doc/html/draft-meunier-web-bot-auth-architecture) to authorize tools to crawl the website and complete audits. 

**What to QA before launch:**

- **Canonical tags:** Are they self-referential and stable? Watch for environment URLs sneaking into canonicals.
- **Meta and headers:** Confirm `noindex`, `nofollow`, and caching headers are correct by template.
- **Structured data:** Validate JSON-LD at scale. Check Product offers/prices/availability match the page.
- **Internal links:** Ensure navigation, breadcrumbs, related products, and in-content links point to production paths (not staging) and use consistent trailing slash rules.
- **Pagination & filters:** Verify canonical strategies and indexability of facets. Decide which filters deserve indexation and which should be `noindex`.
- **Analytics & tags:** Confirm GA/GTM (or your stack), conversion events, and ecommerce schema fire correctly. Deduplicate events to avoid inflated revenue.
- **Sitemaps & robots:** Generate production sitemaps from staging, then disable staging in `robots.txt`. Dry-run the production `robots.txt` to avoid surprises.

## Post‑Launch Monitoring

### The First 4–6 Weeks Are the Danger Zone

Launch day isn’t the finish line; it’s when the real work begins. Search engines will revisit, recrawl, and reinterpret your site. Tiny issues can compound into big problems if you’re not watching closely.

**Daily (and weekly) checks:**

- **Crawl errors:** Monitor 404/5xx spikes in logs and Search Console. Prioritize legacy URLs with external links.
- **Redirect health:** Watch for chains and high-latency routes. Patch mismapped redirects quickly.
- **Indexation & coverage:** Track valid vs. excluded pages. Investigate sudden swings in “Duplicate, Google chose different canonical” or “Crawled – currently not indexed.”
- **Rankings & traffic:** Compare to pre-migration baselines by template and market. Watch non-brand first—brand often masks issues.
- **Sitemaps:** Ensure new URLs are submitted and rising in “Indexed” count. Remove retired sitemaps.
- **Core Web Vitals:** Check for regressions by template. Tracking scripts and A/B tools often bloat JS unexpectedly.

## Ongoing Optimization

### The Migration Is the Beginning of a New SEO Cycle

With the new stack live, resist the temptation to “set and forget.” The best-performing teams set a 90-day post-launch roadmap to convert the migration into momentum.

Focus on:

- **Internal linking refinement:** Use crawl and click data to push equity toward high-value pages—new collections, seasonal hubs, or evergreen guides. Revisit nav and breadcrumbs with real user behavior.
- **Backlink reclamation:** Outreach to update important external links that still point to redirected URLs. Every updated link removes a hop and strengthens relevance.
- **Content re-optimization:** Compare pre- and post-launch rankings. Refresh thin or underperforming pages. Expand FAQs based on emerging queries. Build content around new capabilities the platform unlocks (e.g., better comparison components or dynamic bundles).
- **Schema enrichment:** Add missing structured data types and test eligibility for new SERP features.
- **Technical hardening:** Keep pruning parameter cruft, improve caching, and continue shrinking JS. Treat Core Web Vitals budgets as part of your web performance SLOs.

## Final Takeaway: Paranoia and Precision Protect SEO

Replatforming is equal parts engineering project and change-management exercise. The teams that win keep SEO at the table from discovery to post-launch, blend caution with ambition, and treat baselines as a contract with the business. Precision in redirects, content parity, and technical configuration prevents avoidable losses. Paranoia—healthy skepticism and relentless verification—catches the edge cases that otherwise compound.

Most importantly, view replatforming as the start of a stronger SEO engine. Take advantage of all these tasks to clearly understand what’s needed to fix crawl waste, speed up templates, consolidate content, and build richer experiences once you are on the other side. Done right, you won’t just protect your rankings—you’ll future‑proof your visibility and open new lanes for growth.

If you’re planning a replatform or recovering from one and want an experienced partner to guide the process, **let’s talk**: [https://nebulab.com/contact](https://nebulab.com/contact).

How to Ensure SEO Integrity During a Replatform

We are the full-service eCommerce agency behind some of the world’s most innovative digital brands. Let's talk about your project.

The Nebulab

Why Most Shopify Agencies Get Enterprise Replatforms Wrong

Subscribe to our newsletter

ActiveShopifyGraphQL: The Library That Puts The Joy Back into Shopify's GraphQL API

Stop Killing Your Margins: A Guide to Smarter E-Commerce Discounting

Shopify's Winter 2026 Edition: The Needle Movers and the Missed Opportunities

Before You Buy: What Shopify Brands Need to Know About Celigo

What Your E-Commerce Agency Won’t Tell You, But Should

Why Luxury Brands Are Betting on AI-Powered Virtual Try-On

Customer Portals in Shopify: Understanding Your Options

The Early Mover’s Guide to AI Product Discovery

How to Ensure SEO Integrity During a Replatform

Are you ready to explore the
new commerce frontier?

The Nebulab

Why Most Shopify Agencies Get Enterprise Replatforms Wrong

Subscribe to our newsletter

ActiveShopifyGraphQL: The Library That Puts The Joy Back into Shopify's GraphQL API

Stop Killing Your Margins: A Guide to Smarter E-Commerce Discounting

Shopify's Winter 2026 Edition: The Needle Movers and the Missed Opportunities

Before You Buy: What Shopify Brands Need to Know About Celigo

What Your E-Commerce Agency Won’t Tell You, But Should

Why Luxury Brands Are Betting on AI-Powered Virtual Try-On

Customer Portals in Shopify: Understanding Your Options

The Early Mover’s Guide to AI Product Discovery

How to Ensure SEO Integrity During a Replatform

Are you ready to explore the new commerce frontier?

Are you ready to explore the
new commerce frontier?