MIGRATION · OPERATIONS · 4 FEBRUARY 2025 · 7 MIN READ
Migrating a store mid-season, and why you usually should not
Replatforming is a project you finish, then watch. Launching into your trading peak removes the watching part.
Launch a replatform at the start of your quietest trading period, and give yourself at least one full crawl cycle plus a complete order-to-fulfilment cycle before your next peak. For most northern-hemisphere retail that means launching between January and early spring, or in mid-summer — and never between October and December. The reason is not launch risk itself but observation: the weeks after a migration are when you find the URLs nobody inventoried and the integration that fails on an edge case, and you need trading volume that is high enough to reveal problems and low enough to survive them.
IN SHORT
- The risk is not launch day. It is the four weeks afterwards, when real traffic finds what testing did not.
- You need one full crawl cycle to know whether your redirects held, and that is weeks, not days.
- Launch before peak only if the gap is long enough to fix what peak would otherwise expose expensively.
- A phased cutover by template is usually available and almost always safer than a single switch.
- The old store stays live and publishable until DNS moves. Rollback should be a DNS change, not a project.
What actually goes wrong, and when
Migrations rarely fail on launch day. The data moved, the theme works, checkout takes an order. The team goes home.
What goes wrong happens over the following month. A collection that used to rank stops ranking, because one URL pattern was missed and nobody noticed until the weekly report. An integration handles ninety-eight percent of orders and errors on the ones with a gift message. A tax rule is wrong for one region. A discount behaves differently because the logic moved from one system to another.
Every one of those is findable and fixable. All of them need real traffic to surface and real time to correct. That is the window you are protecting when you choose a launch date.
Why not into peak
Launching in October means the four weeks when problems surface are the four weeks when every problem is most expensive and your team has least capacity to fix it.
It also removes your baseline. After a migration you need to know whether a drop in a metric is the migration or the season, and during peak everything moves at once. If revenue per session falls in November you will not be able to say whether that is your new product template or your promotional mix.
And it compounds: the code freeze that protects peak trading is exactly the thing you cannot have when you have just launched a new platform and need to ship fixes daily.
The gap you need before peak
If you are launching before a peak rather than after one, the question is how much runway you need. Two things set it.
A full crawl cycle. Search engines re-crawl a site at a rate that depends on its size and authority; for a mid-market catalogue you are looking at several weeks before you can say with confidence whether redirects held and rankings moved. Launching four weeks before peak means finding out during peak.
A full order lifecycle. Order placed, picked, shipped, delivered, returned, refunded. The back half of that is where integrations break, and you do not see it until real returns start arriving — which is thirty to sixty days after launch for most categories.
Add them together and the honest minimum before a major peak is about a quarter. Less than that and you are betting that nothing needs finding.
When mid-season is the right call anyway
There are cases, and they share a shape: the cost of staying is higher than the cost of the risk.
- The current platform is end-of-life with a fixed date, and the date is inside the peak window.
- A licence renewal is due and the cost of one more year is a material part of the migration budget.
- The current store cannot handle the peak you are expecting, which makes staying the risky option.
- The business is seasonal in the other direction — a swimwear brand is quiet in November, and "peak" for them is a different quarter entirely.
If you have to, reduce the blast radius
A single cutover is not the only option, and it is rarely the best one. Most migrations can be phased by template or by market.
Move the lowest-risk templates first — content pages, then collections, then products, then checkout last if the platform allows it. Or move one market before the others, which limits exposure to a share of revenue rather than all of it. Each phase gets its own observation window, and each can be rolled back on its own.
Whatever the shape, keep the old store live and publishable until DNS has moved and stayed moved. Rollback should be a DNS change made by one person in an afternoon, not a project that needs a meeting.
The calendar, plainly
For a northern-hemisphere retail business with a Q4 peak: January to March is the best window, with the whole year ahead of you to observe and improve. June to July is the second-best, quiet enough to be safe and far enough from peak to recover. April and May are workable. August and September are tight. October to December is not a launch window — it is a freeze.
If your trading pattern is different, the rule is the same shape: launch into your quiet period, and make sure the next peak is at least a quarter away.
Questions this raises
When is the best time of year to replatform an ecommerce store?
Immediately after your peak, or in your quietest mid-year period. For most northern-hemisphere retail that is January to March or June to July. The aim is a full quarter of ordinary trading after launch, which is what it takes for search, integrations and the returns cycle to reveal what testing could not.
How long after launch do migration problems appear?
Search effects take weeks, because they depend on re-crawl rates. Integration edge cases take as long as it takes for an unusual order to occur. Returns problems take thirty to sixty days, because that is when the first returns arrive. A month of quiet does not mean you are clear.
Can you migrate one part of a store at a time?
Usually, and it is the safer plan. Phasing by template or by market means each phase has its own observation window and its own rollback, and a problem in one does not require undoing all of it. It costs a little more in coordination and saves a great deal in risk.
What should be ready before a migration launches?
A redirect map built from real search and revenue data rather than the sitemap, a decision recorded for every extension or plugin, a tested rollback, and a baseline of the metrics you will judge the launch against. If the baseline is missing you will not be able to tell success from season.
NEXT STEP
Free store audit
A senior Shopify engineer reviews your storefront, theme performance and checkout, then sends a prioritised list of fixes.