← Selected work
02 / PLATFORM MIGRATION

Moving a live commerce ecosystem without losing what made it work.

A domain and platform transition spanning storefront infrastructure, redirects, search indexing, analytics, customer access, and connected buying experiences.

Sana CommerceHubSpotCloudflare
RoleProduct / Project Lead
FocusMigration strategy · risk · technical delivery
Previous environment

calloneonline.com

Indexed URLsCustomer accountsCommerce pathsMicrositesProcurement access
MigrationPreserve continuity
New environment

calloneinc.com

RedirectsSearch indexingAnalyticsProduct visibilityCustomer continuity
Connected systems
Sana CommerceCloudflareHubSpotBusiness CentralAriba + Coupa

The visible domain change was only one part of the migration. Customer, search, commerce, and infrastructure dependencies also had to move safely with it.

01 / Situation

Changing the domain was the easy part. Preserving everything connected to it was harder.

The transition from calloneonline.com to calloneinc.com affected far more than the public-facing website.

The commerce environment supported customer accounts, customer-specific product experiences, branded microsites, procurement workflows, marketing infrastructure, analytics, redirects, and thousands of existing URLs.

That meant the migration had to be approached as a dependency problem. A successful launch was not simply whether the new site loaded. Customer access, search visibility, integrations, and downstream systems all needed to continue behaving correctly after the move.

02 / Risk map

The biggest risks lived outside the visible page.

A migration could look successful in the browser while quietly breaking search visibility, customer access, commerce behavior, or connected services.

Before treating the domain transition as a launch task, I mapped the systems and behaviors that depended on the existing environment. That gave the team a clearer picture of what actually needed to survive the move.

02
Customer continuity

Login, customer accounts, company relationships and customer-specific storefront behavior.

DOMAIN MIGRATIONcalloneonline.com
calloneinc.com
03
Commerce continuity

Product visibility, assortments, pricing, procurement paths and storefront access.

04
Infrastructure + measurement

Routing, domains, Cloudflare, analytics, HubSpot and connected web services.

03 / Migration strategy

I treated launch as the midpoint, not the finish line.

The migration needed a plan for both moving the experience and validating what happened after the switch.

Some dependencies could be tested before launch. Others — including search behavior, indexing, redirects, and production integrations — only became fully observable once the new domain was live.

I structured the work around reducing uncertainty in stages: understand the dependency chain, prepare the environment, execute the transition, validate critical paths, and continue investigating anything that behaved differently in production.

01
Discover

Map dependencies

Identify the domains, storefront behavior, customer paths, integrations, indexed URLs, and connected services affected by the move.

02
Prepare

Build the transition path

Prepare domain configuration, redirects, platform settings, tracking, and the technical conditions needed for the new environment.

03
Launch

Move the experience

Transition the live environment while watching the customer experience and the systems that depended on the previous domain.

Midpoint
04
Validate

Test critical paths

Confirm redirects, customer access, product behavior, analytics, search signals, and other high-risk dependencies in the live environment.

05
Stabilize

Investigate what changed

Monitor production behavior, isolate unexpected symptoms, and distinguish configuration issues from normal migration lag or platform behavior.

Delivery principleReduce uncertainty before launch. Increase observability after it.
04 / Troubleshooting

Post-launch symptoms didn’t point to one obvious cause.

Search visibility became one of the clearest examples of why migration validation had to continue after the site was live.

Google Search Console initially reported problems fetching the sitemap. Later, the sitemap was accepted — but reported zero discovered pages while thousands of URLs remained outside the index.

Instead of treating each signal as an isolated SEO issue, I worked backward through the migration: sitemap generation, configured domains, redirects, crawl accessibility, and the platform behavior producing those signals.

Post-launch investigationSearch visibility
Symptom
Sitemap accepted.0 discovered pages.

Thousands of existing URLs were still not indexed.

What could produce this signal?
01Sitemap output

Was the sitemap exposing the URLs and domain we expected?

02Domain configuration

Was the commerce platform still referencing its previous or default domain?

03Redirect behavior

Were old URLs resolving cleanly into their intended destinations?

04Crawl access

Could authentication or storefront behavior affect what search engines were able to reach?

Trace the platform behavior
Finding

The configured platform domain still mattered after the visible site had moved.

Sitemap output revealed that Sana's domain configuration could continue influencing the URLs exposed to search engines. That made platform configuration part of the indexing investigation — not simply an infrastructure detail.

This did not imply that one configuration issue explained every indexing delay. It narrowed the investigation and exposed another dependency that needed to be validated.

Reasoning trail
Observe

Search Console showed conflicting signals after launch.

Question

Determine whether the issue lived in Google, routing, access, or platform configuration.

Trace

Follow sitemap and URL generation back into the commerce platform.

Narrow

Separate confirmed configuration dependencies from symptoms that still required observation.

05 / The work

The migration work crossed infrastructure, search, and customer experience.

Each layer needed a different kind of validation. Routing had to preserve destinations, search needed to understand the new environment, and customers still needed to reach the correct commerce experience after the move.

Domain + redirects

Preserve the path, not just the homepage.

The domain transition affected more than a single entry point. Existing URLs, customer links, campaign destinations, and connected experiences all carried assumptions about where the site lived.

Redirect planning focused on preserving meaningful destinations wherever possible rather than sending every legacy URL back to the new homepage.

Simplified routing model
Legacy domaincalloneonline.com
/products/.../resources/.../customer-path/...
301Routing logicPreserve intended destination
Primary domaincalloneinc.com
/products/.../resources/.../customer-path/...
SEARCH VALIDATIONPost-launch
SitemapAccepted
Discovered pages0
01Search ConsoleObserve crawl and sitemap signals
02Sitemap outputInspect generated URLs
03Platform configTrace domain dependency
Observed signal

A successful sitemap submission did not necessarily mean that Google was discovering the intended URLs.

Search + indexing

Validate what search engines actually see.

Search Console became part of the post-launch feedback loop. Sitemap submission, discovery, indexing, redirects, and the platform's configured domain all provided clues about how the migration was being interpreted externally.

Rather than treating indexing as a single pass/fail check, I used those signals to trace dependencies and narrow where configuration needed closer inspection.

Customer continuity

The new site still had to resolve the right customer experience.

A successful migration also meant that authenticated customers could still move through the commerce logic that shaped their experience.

Validation extended beyond page availability into the customer path: authentication, company context, product visibility, pricing, and the resulting storefront.

Critical customer pathMigration validation
01LoginCustomer authenticated
02Company contextAccount relationship resolved
03Commerce rulesAssortment + pricing applied
04StorefrontCorrect experience delivered

Authentication

Product visibility

Pricing behavior

Customer navigation

06 / Outcome

The new environment launched — and the migration became easier to observe.

The transition established calloneinc.com as the primary experience while giving the team a clearer view into the technical dependencies that needed continued validation after launch.

Some migration work ended at launch. Other work shifted into monitoring: search discovery, indexing, redirects, platform configuration, and customer-specific paths all remained important signals of migration health.

01
A new primary domain

The public experience transitioned from calloneonline.com to calloneinc.com, creating the new foundation for the company's digital presence.

02
Broader continuity checks

Migration validation expanded beyond page availability into customer access, product behavior, routing, integrations, analytics, and search.

03
More observable migration health

Search Console, sitemap behavior, redirect validation, and platform configuration became part of the post-launch feedback loop.

04
Hidden dependencies surfaced

The migration exposed how platform-level settings could continue influencing downstream behavior even after the visible customer experience had moved.

Post-launch reality

Search indexing did not resolve into a single instant success state. Thousands of URLs still required monitoring and investigation after the transition, reinforcing that migration stabilization was part of the project rather than an exception to it.

07 / Reflection

A migration is successful when the invisible things survive it too.

Moving a website reinforced something I had already learned from managing complex commerce products: the interface is only the visible edge of the system.

Search engines, customer identities, product rules, integrations, analytics, procurement paths, and infrastructure all carry assumptions about where the product lives and how it behaves.

The more of those assumptions I could make visible before launch, the easier it became to identify risk, ask better questions, and understand unexpected behavior afterward.

What this changed about how I manage products
Map the assumptions before the move.Treat observation after launch as part of delivery.