Describe the problem before choosing the project
“The website feels dated” is a starting observation, not a delivery brief. Identify what is difficult: finding a suitable product, understanding compatibility, managing catalogue data or keeping stock aligned with another system. Different problems lead to different scopes.
Take three representative buying journeys and list the failure points. Then ask the people managing orders and customer questions where work is repeated. Use analytics if available, but distinguish an observed drop-off from an explanation for it.
Choose a focused improvement when the foundations work
If the platform supports the business and the problem is concentrated in a few templates or interactions, a focused change may be enough. Examples include rebuilding a specification section, improving collection filters or clarifying variant selection.
This approach lets you define a smaller brief and retain working integrations. It still needs regression testing: a theme change can affect existing products, content and app behaviour. Agree which journeys must continue to work and how you will check them.
Choose a redesign when the experience needs a wider change
A redesign on the existing platform may suit a store whose catalogue structure, templates and presentation have become inconsistent. The business may need a new information architecture without needing to move its orders, customer records or integrations.
Review your existing theme, content model and customisations before committing. A new visual layer will not resolve incomplete product data or an unreliable stock feed. Include those dependencies in the plan rather than treating them as post-launch cleanup.
Consider migration when the platform is a constraint
A platform move deserves investigation when important operational requirements cannot be met reliably, maintenance has become disproportionate, or planned selling models require capabilities the current setup cannot reasonably support. Validate those constraints rather than assuming another platform will remove them.
For a move to Shopify, define the product and variant model, required checkout behaviour, markets, integrations and app costs. Catalogue, customer, order and content migration each need their own mapping and validation. Some historical data or platform-specific behaviour may need a different treatment.
- Inventory URLs and plan relevant redirects before launch.
- Test product imports, stock updates and fulfilment handoffs.
- Agree how orders placed around the cutover will be handled.
- Document launch checks, responsibilities and a recovery plan.
Compare the complete scope, not just the build quote
Include content preparation, data cleanup, licences, subscriptions, integration work, team training and post-launch support. A lower initial development quote can leave substantial work with your own team; a larger quote may include responsibilities you do not need.
Ask each proposal to name its deliverables, exclusions, assumptions and acceptance criteria. Compare those side by side. Delivery dates depend on timely access, content and decisions as well as development effort.
A decision rule you can take into a conversation
If the platform fits and the issue is narrow, investigate a focused improvement. If the platform fits but the experience is inconsistent across the store, investigate a redesign. If the platform itself blocks agreed requirements, investigate migration with a documented business case.
If you cannot yet describe the problem or its impact, start with a scoped review. The useful output is a justified next step, which may be to keep what already works. None of these options can guarantee search rankings or sales.
Want a second pair of eyes?
Tell us about your products, your current store and what needs to work better. We’ll discuss a suitable scope before you commit to paid work.
Discuss the right next step