01 / SIGNAL
The platform is now the constraint
Apps, theme work and workarounds have accumulated around a business that needs a different level of ownership, flexibility or operational control.
01
WHEN A MIGRATION IS THE RIGHT QUESTION
A PLATFORM DECISION, NOT A RESKINReplatforming is a commercial decision before it is a technical one. A store can have a polished theme and still be constrained by an app stack, a brittle data model, a payment requirement, a policy risk or an operating process that the current platform cannot carry. Equally, a migration is not the answer to every backlog. Rebuilding a native platform because it feels familiar is expensive theatre when the real problem is ownership, prioritisation or implementation capacity.
Hollow Point leads with Shopify-to-MedusaJS and complex headless replatforming work because those are the cases where a merchant needs more control of the stack, not simply a different template. That includes restricted commerce, where payments, compliance and platform exposure can be as important as the storefront; see our restricted-commerce approach. When a platform removes a category outright, that exposure stops being theoretical: the Shopify vape ban gave merchants two weeks' notice, and we have written up what the migration options actually are. It also includes established merchants with B2B, catalogue, integration or workflow constraints that have outgrown layers of workarounds.
The assessment remains platform-neutral. We will make the case for a headless stack only where it earns its complexity. If the right answer is to improve what exists through Shopify optimisation or give the current store a senior operating owner through RUN, that should be surfaced before a build is sold.
02 / SIGNAL
The data has commercial weight
A migration is not a design reskin when product relationships, customer history, order records, content and integrations need to remain useful.
03 / SIGNAL
SEO cannot be rediscovered afterwards
URLs, internal links, metadata, canonicals and structured-data behaviour need a visible parity plan before a release window is chosen.
04 / SIGNAL
Payments or compliance shape the stack
Restricted or complex merchants may have requirements that make a rented platform, generic checkout path or unsupported integration an operating risk.
05 / SIGNAL
The business needs a reversible decision
A cutover without clear acceptance checks, monitoring and rollback conditions turns a technical release into a commercial gamble.
02
THE MIGRATION METHOD
MAP FIRST / CUT OVER SECONDMost migration failures are not caused by one dramatic technical mistake. They happen because the business discovers too late that a useful URL was omitted, a data relationship has no destination, an integration owns more of the workflow than anyone realised, or a release condition was never defined. The method below makes those dependencies explicit before the change becomes irreversible.
The work is deliberately ordered. A target stack cannot be selected responsibly until the fit is understood. Data cannot be trusted until it is mapped and validated. Search protection cannot be tested until routes and content have an intended treatment. And a cutover should not be called complete until the new store is being monitored against the baseline and the operating team can run it.
01 / METHOD
Fit assessment
We start with a free 20–30 minute platform fit call. It establishes the actual constraint: platform ownership, payments, compliance, data, integrations, performance, B2B logic or a combination. If the present platform is still the right commercial answer, that is useful information, not a failed sales call.
02 / METHOD
Paid risk assessment
Qualified work moves into a paid migration or platform risk assessment. It records the target operating model, dependencies, source-of-truth systems, data shape, critical journeys and cutover risk. The assessment is credited against a BUILD project if the work proceeds.
03 / METHOD
Parity map
Before build decisions get expensive, we map the URLs, search surface, templates, content, catalogue, integrations and customer journeys that must survive. The parity map distinguishes what is carried over exactly, what is improved deliberately and what is retired with a controlled redirect or communication path.
04 / METHOD
Data migration
Products, variants, collections, customers, orders and relevant content are treated as governed data, not a one-click export. Field mappings, transforms, validation rules and exceptions are documented so the new system is usable by the people who will operate it.
05 / METHOD
SEO and redirect protection
The 301 redirect map, canonical logic, metadata, internal links and structured-data requirements are established while the new experience is still testable. We compare staging against the parity plan, not a vague promise that rankings will sort themselves out after the move.
06 / METHOD
Staged cutover and rollback
The release runs against named acceptance checks: routes, checkout and account journeys, payment behaviour, data integrity, analytics and operational handover. Rollback conditions are agreed in advance, with a clear owner and response path if a critical check fails.
07 / METHOD
Monitoring and recovery
A launch is the start of observation, not the end of responsibility. We watch the agreed technical, search and commercial indicators after cutover, investigate gaps against the baseline and work the recovery queue while the change is still recent.
03
THE MIGRATION STANDARD
TEN COMMITMENTS / EVERY PROJECTMost migration quotes describe moving data. Products in, customers in, a theme that looks similar, live in three weeks. That is the easy half. The half that decides whether the migration was worth doing is everything attached to those records: the URLs that earn organic revenue, the payment provider that actually captures money, the eligibility checks that keep the business trading legally, the promotions customers already expect, the review history that carries social proof, and the stock ledger that must not end up counted twice.
A migration that moves the catalogue and drops the rest is not a migration. It is a rebuild with a data import, and the cost of the missing half arrives after cutover, when the old store is gone. Hollow Point runs migrations against a fixed standard. The ten commitments below ship on every MedusaJS migration we deliver, whatever the size of the store. None of them is an upgrade, an add-on, or a line item to negotiate away.
01 / INCLUDED
Catalogue migration and normalisation
Products, variants, collections, brands, options, media and alt text, migrated with source identity preserved. Catalogue defects are corrected on the way through rather than reproduced: an agreed SKU policy, typed attributes, a normalised taxonomy and product families for ranges with many editions. Exceptions are recorded in a ledger, not silently dropped.
02 / INCLUDED
Customer and order history
Customer records, addresses, order history and the relationships between them, migrated with a reconciliation report. Password hashes are never carried across; migrated customers receive a tested account-claim or reset journey. Marketing consent is captured separately from account acceptance, with source and timestamp retained.
03 / INCLUDED
URL preservation and redirect registry
A frozen manifest of every public URL before cutover. Valuable routes are preserved; where a URL must change it receives a direct one-hop 301. The registry includes query-aware matching, loop and chain detection, import tooling and a rollback path. Canonicals, robots rules, sitemaps, metadata and structured data are generated from one governed source rather than assembled per template.
04 / INCLUDED
Checkout and payments
A single controlled cart-to-order path, with ownership, totals, promotions, stock and eligibility rechecked immediately before payment completion. Full authorise, capture, void and refund lifecycle for every enabled provider, with webhook verification, idempotency and reconciliation. Only the providers confirmed as capturing live revenue during discovery are built; a provider named in a policy page is evidence to investigate, not a licence to bill for an integration.
05 / INCLUDED
Content and media
Information pages, buying guides, FAQs, policy pages and editorial content migrated with source URL, title, body, author and date where available. A governed media library with owned storage, provenance and alt text. Contradictory delivery, returns and contact information is resolved before publication rather than copied forward as approved truth.
06 / INCLUDED
Search and discovery
Product search with type-ahead, typo tolerance, synonyms and relevance tuned to the store’s own vocabulary. Facets built from cleaned, typed attributes rather than free-form tags. Shareable filter and sort URLs with a deliberate indexation policy, server-side pagination, and fallbacks that leave browsing available if the search service degrades.
07 / INCLUDED
Promotion parity
Active offers rebuilt on native platform promotions wherever core behaviour is sufficient, including multibuy, mix-and-match, minimum-spend and free-delivery rules. Storefront messaging is derived from the same rules the checkout applies, so a product or cart page can never advertise a deal that checkout will refuse.
08 / INCLUDED
Admin and operational handover
Staff use standard Medusa Admin wherever the core platform already does the job. Focused extensions are built only where core has no equivalent. Every project ends with an integration status registry, import and reconciliation history, operational documentation and a staff handover session.
09 / INCLUDED
Reconciliation and acceptance
Count-level and field-level reconciliation after every major import: variant totals, collection membership, prices, stock, customer links, order totals and URL parity. Automated tests focused on money, stock, identity, promotions, URLs and provider retries. A live-to-live pre-cutover crawl proving status, canonical, indexability and structured-data parity.
10 / INCLUDED
Staged cutover, rollback and hypercare
The new store stays password-protected and excluded from search engines until the acceptance gates are green. Cutover covers source freeze, final deltas, DNS, webhooks, payment return URLs, monitoring and a defined rollback window with named owners. Launch is followed by hypercare with revenue, payment, stock, fulfilment, error and search-visibility monitors.
04
HOW A MIGRATION IS SIZED
STORE SHAPE / NOT A DAY-COUNT TIERHollow Point does not quote from a day-count table. The work is driven by the shape of the store, not by a tier chosen before anyone has seen the data. These three profiles exist so a merchant can recognise their own situation before the first call, and so both sides know which conversations discovery needs to have. Whichever profile applies, the ten core commitments apply in full.
Profile A / STANDARD REPLATFORM
A single retail catalogue with conventional checkout and few external dependencies.
- One catalogue, one market, one currency
- Standard checkout with no eligibility, verification or approval gating
- Up to two external integrations beyond the payment provider
- Variant structure that maps cleanly without a redesign
- No gated pricing, trade accounts or subscription logic
Profile B / INTEGRATED
A standard catalogue carrying real operational weight through connected systems.
- Everything in Profile A
- Three to five integrations: ERP, WMS, POS, loyalty, marketplace or product feeds, email and CRM
- Moderate checkout and customer-journey customisation
- Stock or order data with a source of truth outside the commerce platform
- Reporting or fulfilment dependencies that must survive cutover intact
Profile C / COMPLEX / REGULATED / B2B
A store whose commercial rules, compliance obligations or catalogue scale make the migration a systems project rather than a replatform.
- Age verification, licence checks or other regulated checkout obligations
- B2B: company accounts, gated catalogues, customer price lists, purchase orders, credit terms, representatives
- Subscription or recurring billing logic
- High SKU and variant complexity, or ranges requiring a product-family architecture
- Five or more integrations, multi-region, multi-currency or a bespoke design system
Add-on modules
The core covers the migration. These are the capabilities that sit on top of it, scoped and agreed as separate modules so a merchant pays for what their business actually runs on. Modules are selected during discovery against evidence of actual use: a capability present in the current store but unused by customers is a candidate for retirement, not automatic rebuilding.
B2B and wholesale
Company accounts, multi-company user access, gated catalogues, customer-specific price lists, quantity and case rules, purchase orders, credit terms, approval workflows, sales-representative portfolios and assisted ordering.
Age verification and regulated checkout
First-class verification-provider integration, verification state stored against customer and order, silent data-match with controlled ID fallback, dispatch holds, staff override with audit trail, and an unresolved-verification queue.
Loyalty and rewards
Points, tiers, earning and redemption rules, referral behaviour, balance migration where the incumbent provider supplies a complete export, and reconciliation tooling for points liability.
ERP, WMS, POS and stock sync
Bi-directional stock, order export, fulfilment status and reconciliation against an external source of truth, built to avoid parallel stock ledgers and silent export failures.
Marketplace and product feeds
Channel feeds, marketplace listings, conversion APIs and the attribute mapping each destination requires.
Subscriptions
Recurring billing, subscription lifecycle, payment retry handling, customer self-service and dunning.
Multi-region and multi-currency
Additional regional storefronts, currencies, tax treatments, market-specific catalogue availability and localised content.
Bundles and mix-and-match
Configurable bundle builders, gift boxes and component-level stock and order behaviour.
Reviews migration
Review history preservation or provider transition, product identity mapping, invitation flows and structured data that degrades safely.
AI agent modules
First-party retrieval-backed customer support, catalogue hygiene and merchandising assistants, and internal operations agents built into the admin rather than bolted on as a third-party widget.
NOT INCLUDED / STATED UP FRONT
Scope arguments after kickoff are worse than scope arguments before it.
- Anything in the module list above. Modules are separately scoped and agreed, never assumed.
- SEO growth, content marketing or ranking expansion. The core protects existing visibility through cutover; growing it is a separate engagement.
- Editorial rewriting, brand redesign or a new design system unless separately agreed. Content migration preserves approved material.
- Native mobile applications.
- Compliance certification. Hollow Point builds to the policy the merchant confirms; it does not certify consumer-law, regulatory or health claims.
STAYS WITH THE MERCHANT
The decisions and access a migration cannot be run without.
- Approval of product data, tax and duty treatment, policies and legal or compliance wording.
- Third-party provider accounts, contracts and usage charges.
- Access to the source platform’s admin, exports and APIs during discovery and migration.
- Commercial decisions about which capabilities are worth rebuilding.
05
START WITH THE RISK, NOT THE BUILD
PAID ASSESSMENT / CREDITED AGAINST BUILDThe first conversation is a free 20–30 minute fit call. It is there to establish whether the merchant has a real migration decision and whether Hollow Point is the right operator to assess it. There is no value in producing a generic migration proposal for a business that has not yet named its source-of-truth systems, critical journeys or commercial constraint.
If the fit is real, the next step is a paid migration or platform risk assessment. It turns the unknowns into a decision-grade brief: target architecture, source-platform data and access, parity requirements, search and redirect risk, integrations, payments, operational ownership, cutover sequence and rollback conditions. It is not a PDF designed to decorate a sales process. It is the first piece of the build plan.
No public price is assigned to the assessment or the build, because scope follows the risk profile rather than a generic catalogue size band. Two stores with the same product count can be a straightforward replatform and a systems project. The assessment is credited against the build if the project proceeds.
06
WHAT THE PARITY MAP PROTECTS
DATA / SEARCH / OPERATIONS / RELEASESEARCH SURFACE
Every material URL has an intentional treatment: retain, replace, consolidate or redirect. The plan considers canonicals, metadata, internal links and structured data alongside the redirects.
COMMERCIAL JOURNEYS
The paths that make money or retain customers are tested as journeys, not merely as pages: search and navigation, account access, checkout, transactional messages and the hand-off to operations.
OPERATING DATA
Data mapping is judged by whether the team can actually run the new store: product structures, customer records, orders, content and integrations need validation, exception handling and an owner.
CUTOVER CONTROL
A release window needs a sequence, named checks, decision authority and rollback conditions. That is how the team distinguishes a problem worth observing from a problem that requires reversal.
SEO protection is a build discipline.
Redirects are critical, but they are not a substitute for route-level intent, canonical parity and a clear internal-linking model. The migration work connects naturally with ecommerce SEO: the search surface is treated as a business asset to carry forward, not a report to revisit after launch.
Headless is a means, not a badge.
For the merchants that need it, MedusaJS development provides the ownership and extension model behind the target stack. For a fuller decision framework, read the headless commerce guide before committing to complexity that the business cannot operate.
07
FLAGSHIP BUILD: SCALE UNDER VERIFICATION
PRE-LAUNCH VERIFICATION / LEDGERED EVIDENCEOur flagship vape-retail build is a relevant proof case because the migration question is operational as well as technical: data volume, catalogue behaviour, search protection, payments and the cutover controls all need to be managed as one system. Its status is deliberately clear. The work remains in pre-launch verification; production cutover has not been verified.
The figures below are scope evidence, not a claim of a completed production migration or a promise of a comparable result. Read the flagship verification record for the current evidence trail under the same verification standard.
orders included in the flagship vape-retail pre-launch verification.
line items included in the flagship vape-retail pre-launch verification.
customer records included in the flagship vape-retail pre-launch verification.
orphan records observed in the current flagship pre-launch verification.
08
COMPLEX REPLATFORMING, WITHOUT THE PLATFORM SCRIPT
SOURCE SYSTEM / TARGET DECISIONMagento, WooCommerce, BigCommerce, Visualsoft, Salesforce Commerce Cloud, custom platforms and Shopify can all create migration demand. The route name is not the plan. The relevant questions are what the business needs to own, which data and integrations carry commercial risk, what the search surface has earned, and whether the future operating team can support the target stack.
That is why Hollow Point does not sell a one-size-fits-all migration into Shopify to chase adjacent search demand. Where a merchant is leaving Shopify because of ownership, policy, payment, compliance or bespoke-workflow constraints, the decision needs a credible headless or MedusaJS path. Where a different target platform is genuinely the best fit, the assessment should document why.
Magento and Adobe Commerce
The assessment starts with catalogue complexity, bespoke modules, integrations and the current search surface. The decision is not driven by the old platform name alone.
WooCommerce and WordPress
Data, plugins, subscriptions, content relationships and performance dependencies are reviewed before deciding which parts should migrate, be rebuilt or be retired.
BigCommerce, Visualsoft and SaaS platforms
The focus is on the operating constraint, available data, integrations and the degree of ownership the merchant needs from the next stack.
Shopify to MedusaJS and headless targets
Shopify-to-MedusaJS and headless is a strong fit where ownership, extensibility, payments, compliance or bespoke workflows justify the build. It is not presented as a mandatory answer for every merchant.
09
FREQUENTLY ASKED QUESTIONS
PLAIN ANSWERS / DECISION SUPPORTWill I lose SEO rankings when I migrate an ecommerce store?
A migration carries risk, but it should not be managed as an afterthought. Hollow Point establishes the URL, canonical and metadata parity plan before cutover, implements the redirect map, then monitors the result. A short period of volatility can happen; the point of the method is to make loss visible and recoverable rather than discover it after the old store is gone.
What is included in an ecommerce migration?
Every Hollow Point migration includes ten commitments, whatever the size of the store: catalogue migration and normalisation; customer and order history; URL preservation and a redirect registry; checkout and payments; content and media; search and discovery; promotion parity; admin and operational handover; reconciliation and acceptance; and staged cutover with rollback and hypercare. None of those is an add-on. Capabilities beyond that core — B2B, age verification, loyalty, ERP or stock sync, subscriptions, marketplaces, bundles, reviews migration, multi-region and AI agent modules — are scoped as separate modules against evidence of actual use.
What is not included in a migration?
SEO growth, content marketing and ranking expansion are excluded: the core protects existing visibility through cutover, but growing it is a separate engagement. Also excluded by default are editorial rewriting, brand redesign or a new design system, native mobile applications, compliance certification, and anything in the add-on module list. Merchants keep approval of product data, tax treatment and legal wording, their own third-party accounts and contracts, and the commercial decision about which capabilities are worth rebuilding.
Do you quote migrations as fixed day-count tiers?
No. A tier chosen before anyone has seen the data is a guess with a price attached. Hollow Point sizes work by the shape of the store: a standard replatform, an integrated store carrying operational weight through connected systems, or a complex, regulated or B2B store where commercial rules and compliance obligations make the migration a systems project. The profile shapes the discovery conversation; the scope itself is written from a paid assessment against real data.
How much does an ecommerce migration cost?
Hollow Point does not publish a price band, because catalogue size is a poor predictor of migration cost. What moves the number is data quality, integration count, payments, compliance obligations and the size of the URL surface that has to survive cutover. The paid risk assessment establishes the actual work, dependencies and risk before a build is committed, and is credited against the build if the project proceeds.
How long does an ecommerce migration take?
The timeline depends on catalogue shape, data quality, integrations, SEO surface and the target operating model. Hollow Point does not publish a generic duration because a credible plan needs the parity map and risk assessment first.
Can you migrate products, customers and order history?
Those records are assessed in the data map alongside variants, product relationships, SEO metadata, content, subscriptions and integrations. What can be carried across depends on the source system and its export or API constraints; the assessment documents the treatment rather than assuming all records behave alike.
Can customer passwords be moved to the new platform?
Only where the source platform provides a compatible, secure path. Password hashes are not treated as ordinary customer data. If a direct transfer is unavailable, the cutover plan includes an account-activation or password-reset journey that is tested before launch.
What is a 301 redirect and why is it important?
A permanent 301 redirect tells browsers and search engines that an old URL has moved to its intended new home. It is only one part of SEO protection, but a missing or indiscriminate redirect map can waste established relevance, links and customer journeys. The map is reviewed before cutover, not assembled at the end.
Can we test the new store before cutover?
Yes. The build is validated in staging against the agreed parity criteria before any production traffic moves. The cutover is staged so that technical, data and journey checks can be observed in a controlled sequence.
Do you migrate stores into Shopify?
Hollow Point is platform-neutral in assessment, but this offer is led by Shopify-to-MedusaJS and other complex replatforming decisions where platform ownership, payments, compliance, data or bespoke workflows are the constraint. If native Shopify is the better answer, that should be clear in the assessment rather than manufactured into a core migration offer.
What happens if there is a problem during cutover?
The migration plan names the checks, owners, rollback conditions and communication path before the cutover window. Monitoring continues after the change so routing, indexation, data and commercial journeys can be addressed quickly rather than treated as a finished project on launch day.