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-Medusa/headless and complex 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. 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
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.
First BUILD projects are typically £30k–£50k, subject to scope and complexity. The assessment is credited against the build if the project proceeds. No public price is assigned to the assessment because its scope follows the risk profile rather than a generic catalogue size band.
04
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, Medusa 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.
05
GREY HAZE: SCALE UNDER VERIFICATION
PRE-LAUNCH VERIFICATION / LEDGERED EVIDENCEGrey Haze 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 Grey Haze verification record for the current evidence trail under the same verification standard.
orders included in Grey Haze pre-launch verification.
line items included in Grey Haze pre-launch verification.
customer records included in Grey Haze pre-launch verification.
orphan records observed in current Grey Haze pre-launch verification.
06
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 Medusa 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.
Headless, Medusa and custom targets
Medusa/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.
07
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?
The scope is established through a fit call and paid migration or platform risk assessment. Typical work covers the target architecture, data mapping, catalogue and customer migration, integrations, SEO and redirect protection, staging QA, staged cutover, rollback preparation and post-cutover monitoring.
How much does an ecommerce migration cost?
First BUILD projects are typically £30k–£50k, subject to scope and complexity. The paid risk assessment is used to establish 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-Medusa/headless 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.