Ecommerce Replatforming: The URLs Are The Whole Game

Ecommerce replatforming is one of those projects that is estimated by the build and paid for by everything else. The store gets rebuilt roughly on schedule. The traffic, the integrations and the historical data are where the year goes.

Here is what a migration actually consists of, in the order things go wrong.

First: is the platform the problem?

Worth an honest hour, because replatforming is expensive and sometimes solves nothing.

Some complaints are genuinely structural. The platform will not accept your category. The data model cannot express per-customer pricing. You cannot write the storefront you need. Those do not improve with effort.

Others are not about the platform at all. The site is slow because of an accumulation of apps and a heavy theme. Nobody can find anything because the taxonomy was never designed. Conversion is poor because shipping cost appears at the last step. Every one of those follows you to the new platform, arrives on day one, and is now competing with a migration for attention.

The test: write down the three things that are wrong. For each, ask whether a competitor on the same platform has solved it. If they have, it is not the platform.

The URLs are the whole game

This is the part that turns a project into a disaster, and it gets a line item.

Every platform structures URLs differently. Products, categories, blog posts, filtered pages. If your rankings mean anything to your revenue, a redirect map is not a task at the end, it is a deliverable with the same status as the storefront.

What that means concretely. Export every indexed URL before you start, from your sitemap, your analytics and a crawl, because none of the three is complete alone. Map every one to its new destination. Not to the homepage: to the equivalent page, or the closest parent category if the page is genuinely gone. Use permanent redirects, and make sure they are single hops, because chains lose value at each step and some get abandoned entirely.

Then test the map before launch, not after. And expect a dip anyway. A well-executed migration usually loses some traffic for a few weeks while search engines reprocess. A badly executed one loses it permanently, and by the time that is obvious the team has moved on.

What does not come across cleanly

Customer passwords. Stored as hashes, and a different platform hashes differently. Usually every customer has to reset. Plan the email, because the alternative is a support queue and a bad first impression on the new store.

Saved payment methods. Tied to your processor and sometimes to the platform's account with it. Subscriptions in particular can mean re-collecting card details from every subscriber, which is a churn event dressed as an IT project. Ask this question early.

Order history. Usually importable as records, rarely with everything attached. Partial refunds, per-line fulfilment states and edit history tend to flatten. Decide what finance and support genuinely need before agreeing to a shape.

Reviews. Often owned by an app rather than the store, portable only if the app supports it. Losing them is a real conversion cost and it surprises people.

Every integration. Accounting, email, ERP, feeds, analytics. Each is rebuilt. This is where the timeline usually slips, because they are scoped as one line and are each a small project.

The migration people forget

Content. Product descriptions with formatting that does not survive. Images at the wrong sizes. Category copy nobody owns. Meta titles and descriptions, which if lost are a ranking loss on top of the URL change.

Budget real time for it and give it a name, because unnamed work does not get done.

Sequencing that reduces the damage

Build and populate the new store fully before touching anything live. Test the redirect map against the real list. Keep tracking configured identically so that after-versus-before means something. Launch at a quiet time, and not before a peak season, because if something goes wrong you want a slow week to fix it rather than your best month.

Then watch coverage and rankings weekly for a couple of months. A migration is not finished at launch, it is finished when traffic recovers, and the difference between the two is where the money is.

Where we fit, and where we do not

Migrating to dashfordevs means the storefront is yours to write, so URLs are entirely your decision rather than a platform convention, and the redirect map can be exactly the one you want. The catalog, customers and orders come in over the API, so an import is a script you can run repeatedly against a staging environment rather than a one-shot upload.

The honest cost: you are also taking on the storefront, so this suits teams who were going to write one anyway. If you are not, a hosted platform is a shorter migration and a better fit, and moving to us would be the wrong direction.

Where we are the wrong answer more generally: if your three problems are not structural, do not migrate at all, fix them where you are. If nobody on your side writes front end code, this is not the platform. And if you need to be on the new store in three weeks, that is not a migration, it is a rebuild with the risk left in.

The short version

Confirm the platform is actually the problem. Treat the redirect map as a deliverable. Ask early about passwords, saved cards and subscriptions. Assume every integration is a rebuild. Launch into a quiet week and keep watching for two months.

If you are scoping a move and want to see what an import looks like, the docs have the catalog and customer endpoints.