Redesign, move platforms or fix what you have: how to choose

A new design will not fix traffic or the offer, and neither will a new platform. There is a fourth route, hiring someone in-house, but it is about who does the work rather than what the store needs, so it comes last. Below is how to tell the routes apart, using the table from our redesigns page, and what each route costs with us. If you end up with a build either way, the launch checklist post covers what gets checked before it goes live.

An owner on r/ecommerce put the question plainly in March 2026: “Will migrating from Woo to Shopify guarantee a CVR boost?” CVR is the conversion rate. In the replies they explained why they wanted to move. They had spent most of the past year with their developer fixing things that kept breaking, and it was their third store on WordPress with the same problems. Several replies pushed back: the breakage, they said, came from how the stores had been built, and any gain from a move would come mostly from what changed alongside it, rarely from the platform on its own. Platform or build: that question is what separates a redesign from a move. Settle it before anyone quotes you for either.

The short answer

There are four sensible ways to deal with a store that has fallen behind, and each one is right for somebody.

First, find out which problem you have

A store that is not selling can have three kinds of problem, and only one of them is the store itself.

Traffic, the offer, or the store?

• Traffic. Too few of the right people arrive. A redesign shows a better store to the same small crowd.
• The offer. People arrive and look, but the product, the price or the terms do not persuade them.
• The store. People arrive and want the thing, and the store gets in the way: the answer they need is hidden, the page is slow, the button is hard to hit on a phone.

Before you decide which, check that your numbers are real. Broken or missing tracking is one of the six things a quick-fix sprint usually fixes, and a store that cannot see what sells cannot tell a traffic problem from a store problem.

Then ask three questions, in this order:

1. Are enough of the right people arriving? If not, start with traffic.
2. When they arrive, can they find what they need to buy: what it is, the fit, the material, delivery, returns and the price? If they can and still do not buy, look hard at the offer.
3. If they cannot, or the store is slow or awkward on a phone, the problem is the store, and the rest of this post applies.

For a quick first look at the store side, our free store checkup reads one page of your store in a few seconds: search tags, AI crawler access, structured data, scripts and trust pages. It is automated, and it is not a speed test.

Six places a store quietly loses orders

These are the six things our store review looks at, in the review page’s words:

1. How the store works on a phone. Where the phone layout makes buying harder than it should be.
2. What the first screen says. Whether a new visitor can tell what you sell, and why yours.
3. What the product page answers. Fit, material, delivery and returns, and where they are hidden.
4. How the store looks next to the product. Whether the store makes the price feel right.
5. What slows the pages down. The apps and scripts that load before anything appears.
6. Whether your tracking can be trusted. Whether the numbers you look at are the real ones.

Where the problems sit points to the route. A short list of faults, each of which can be fixed without breaking another, is the first row of the table. A product page or a first screen that needs rethinking rather than adjusting is a redesign. The fourth item is not on a sprint’s list: when the store makes a good product look cheap, the fix is the design itself.

When fixes are enough

Fixing in place is right when the problems are few, and nothing else breaks when one is fixed. It stops being right when every fix breaks something else, or nobody knows any more what each app does. The owner on Reddit was describing something close to that first sign: a year of repairs that did not stay repaired. More patching at that point pays for the same problems twice.

That is a reason to stop patching, not yet a reason to move. The sections on redesigns and moves, below, tell a rebuild from a move.

With us, fixing in place is a quick-fix sprint: the fixes from your review that pay off fastest, done in one to two weeks, from $700. After it comes monthly work, if you want fixes shipping every month. Can you start monthly work without a project first? Our answer on that page is short: “Yes, if the foundation is sound. The store review tells you whether it is.”

What a sprint fixes, and what it does not

A sprint usually fixes these:

• Product pages that hide fit, delivery and returns below the fold
• A first screen that does not say what you sell
• Slow pages caused by apps nobody uses any more
• Broken or missing tracking, so you cannot see what sells
• Buttons and menus that are hard to use on a phone
• Titles and product data that search engines and AI assistants cannot read

It does not include a redesign of the whole store, new features or new apps, or work after the sprint, which is monthly work. The line between a sprint and a redesign is the one on the sprint page: “A sprint fixes what is there. A redesign rebuilds the page types themselves. If the review shows the foundation is the problem, we will tell you a sprint is not enough.”

If slow pages are your main complaint on Shopify, the post on app scripts goes through the ones that load before anything appears.

When a redesign is the right spend

A redesign is right when the platform is sound, but the store sells worse than the product deserves. Sound means the platform does what the business needs: it takes payment the way your customers pay, holds your catalogue and talks to the systems around it. The trouble is in the pages, not underneath them.

A redesign on your platform leaves the data where it is. Products, customers, orders and reviews stay put, so most of the work goes into the page types themselves: the home page, the collections, the product page, the cart.

It is the wrong spend when traffic is low or the offer is not landing. A better-looking store shows the same offer to the same number of people.

With us a redesign starts at $1,500 and runs over 4 to 8 weeks. That price is for a typical project: a redesign of the page types you already have, on a catalogue of a few hundred products. What moves a redesign’s price has its own post.

When to move platforms

A move is right when your platform holds you back, and keeping it running costs more every year. It is wrong when your business depends on something only your current platform does. Check both halves before you price a move.

“Holds you back” has a simple test: would the problem follow you? Replies in that Reddit thread pointed at piles of plugins, cheap hosting and no copy of the store to test changes on. Those are faults in how a store is built, and a rebuild on the same platform can remove them without moving any data. If the problem is something the platform cannot do, and the cost of keeping it running keeps climbing, a move is worth pricing.

We work on the platform your store needs. So the answer to “which platform?” comes after the review, not before it.

What a move does not change

A move takes the same products, the same prices and the same visitors onto new software. If the product page hid delivery and returns before the move, the move alone does not bring them into view; someone has to design the new page to show them. A new platform does not fix the offer or the traffic.

Google’s guide to site moves, as of October 2026, has a rule that matters here: change only one thing at a time. Its example names a new domain, a new content management system and a new layout, and says to make those changes one after the other. A move with a new design makes two of them at once. If sales or search traffic change afterwards, it is hard to tell which change did it.

What makes a move cost more than a redesign

Moving the data and keeping your search rankings is the expensive part. Customers, orders and every old URL have to be brought across, and each kind of data has its own catch. Shopify’s guides and Google’s spell some of them out (as of October 2026):

• Addresses are likely to change. Shopify’s migration guide warns that its link structure is likely different from your old platform’s, so old links to specific pages “likely won’t load for customers” unless you set up redirects.
• Some data does not move cleanly. Shopify’s WooCommerce guide says you can’t export or migrate reviews from WooCommerce to Shopify, and that they can be imported by hand with a third-party app. It also warns that Shopify allows only 3 product options, and that its Store Migration app, in early access, does not import the options of a product that has more.
• Search takes time to settle. Google says that for a medium-sized site it can take a few weeks or more before results show the new addresses instead of the old ones, and to keep the redirects for as long as possible, generally at least a year.

A redesign on the same platform skips most of this, because the data stays where it is.

When a project is a move, the Moving platforms pack of our checklist applies: 16 checks for customers, balances, reviews and every old address brought across, the old store switched off cleanly, and a way back if the switch goes wrong. Three of them, as the checklist words them:

• Every old address with visits or links is mapped to one new page before the move.
• Every unspent gift card and store credit balance is recreated and reconciled to the old total.
• The old store is stopped from taking orders, proved by trying to check out on it.

If the move you are weighing is WooCommerce to Shopify, the post on moving without losing search traffic covers how that move is checked.

When to hire someone in-house

Hiring is right when there is enough work to keep a developer busy every week. It is wrong when you need one rebuild done well, then light upkeep.

Hiring does not answer the first question. An in-house developer still has to decide whether the store needs fixes, a redesign or a move, and faces the same table. So decide the route first, then decide who does the work.

The test is the calendar. List the store work of the last few months. If it would fill a working week, every week, hire. If it comes in bursts around a launch or a season, a project and then monthly work fit that shape better. We sell the second, so weigh our view with that in mind.

Five questions to answer before you decide

1. Is the problem traffic or the offer? If it is, none of the store routes comes first.
2. When you fix one thing, does something else break, and does anyone still know what each app does? If fixes hold and the list is short, fix in place.
3. Is the platform sound, with the store selling worse than the product deserves? Redesign on your platform.
4. Does the platform hold you back, with the cost of keeping it running rising every year, and does nothing in your business depend on something only it does? Then a move is worth pricing.
5. Is there a developer’s worth of work every week? If so, hire. If you need one rebuild done well and then light upkeep, do not.

What each route costs with us

• Store review: free. A 15-minute call about your store, then written notes on what is costing you orders and what to fix first.
• Quick-fix sprint: from $700, one to two weeks, at a fixed price.
• Redesign on your platform: from $1,500, over 4 to 8 weeks. What moves that price has its own post.
• Move to another platform: from $2,000.
• Larger builds: from $5,000.
• Hire in-house: a salary, plus the months it takes to hire. We do not sell this one.

Every project is priced individually. These are starting points, and the pricing page says what moves each one.

If you are not sure which problem you have, that is what the store review is for. It is free, and the notes are yours whatever you decide.