E-commerce15 min read•

Ecommerce Website Development in Pune: Moving an Existing Store Between Shopify, WooCommerce and Custom Builds Without Losing Orders, Reviews or Search Traffic

How to migrate an online store between Shopify, WooCommerce or a custom build: inventory, redirect map, customers, orders, reviews, testing, launch day and monitoring.

#ecommerce migration#Shopify to WooCommerce#redirect map#replatforming#ecommerce SEO

You can move an online store from one platform to another, for example from Shopify to WooCommerce, from WooCommerce to Shopify, or from either to a custom build, without losing your search traffic, but only if the migration is treated as a content and URL project first and a technology project second. Products, categories and pages move by export and import; reviews, customer accounts, subscriptions and order history need individual decisions; and every old URL that has ever earned a visit or a link needs a permanent redirect to its closest equivalent on the new store. Stores that skip the redirect map are the ones that watch organic sales fall after launch. This guide is for owners and managers who are considering ecommerce website development in Pune or elsewhere for an existing store and want to know what to ask, what to check and what can safely be left behind.

It is written for stores that already have customers and orders, not for first builds. It covers whether you should move at all, what has to be inventoried before work begins, how the main platforms differ in URL structure and exports, how to plan redirects, what to do with customer accounts and order history, how to test before launch, how to cut over on the day, and what to monitor in the following weeks. It does not quote prices for migration, because the effort depends on catalogue size, custom features and data quality; ask for a written scope with a fixed deliverable list instead.

First question: should you move at all?

Replatforming is disruptive and rarely pays back quickly. Before you commit, write down the real reason in one sentence. Some reasons are sound.

  • A capability you cannot get. For example, trade pricing, complex bundles, a multi-language store or a marketplace integration that your current platform handles poorly or only through costly apps.
  • Cost structure that no longer fits. Monthly subscription plus app costs that exceed what the equivalent self-hosted setup, including hosting and maintenance, would cost, once you have counted the time and skills needed to run the latter.
  • Performance or control limits. You need page-level control the platform's theme system does not permit.
  • A decision to own the code and data. Some businesses prefer a custom build for strategic reasons.

Some reasons are weak: a competitor uses another platform, a developer prefers a different tool, or a redesign is wanted and a platform change seems to come with it. A redesign can usually be done on the existing platform. Our comparison of Shopify versus WooCommerce for platform choice sets out the trade-offs, and the article on headless commerce explains when a custom front end is justified.

Step 1: Inventory everything before touching anything

Create a spreadsheet with one row per thing that must survive the move. Sections you need:

Area What to list Where the data comes from
Products Title, handle or slug, SKU, price, sale price, weight, images, variants, stock, descriptions, metafields and custom fields Platform export file
Categories or collections Name, URL, description, images, rules for automated collections Platform admin, export or crawl
Content pages About, policies, contact, size guides, landing pages, blog posts Crawl and sitemap
URLs Every URL that is indexed, linked or visited XML sitemap, a crawler, Search Console, analytics landing pages
Redirects already in place Existing 301s on the old platform Admin redirect list
Customers Names, emails, addresses, marketing consent status Platform export
Orders Order history, invoices, refunds, notes Platform export, accounting system
Reviews and ratings Text, rating, date, product App export, if the app allows
Discount codes and gift cards Active codes, balances Platform admin
Apps and integrations Payment gateway, shipping, accounting, email, WhatsApp, loyalty, reviews, analytics Admin app list
Tracking Analytics, ad pixels, Search Console, merchant feed Tag manager and admin
Email and domain Domain registrar, DNS, email sending setup Registrar and DNS panel

The number most people underestimate is the app list. Each app on the old store does a job. Some jobs are replaced by built-in features on the new platform, some need a new plugin, and some have no equivalent. List the job, not the app name, and decide how each will be covered.

Decide what to leave behind

Not everything should move. Products that have not sold for years, discontinued items with no traffic, thousands of tag pages with no value, and unused apps are candidates for retirement. For discontinued products with traffic or backlinks, follow the principles in our guide to out-of-stock and discontinued product pages rather than deleting blindly.

Step 2: Understand how URLs differ between platforms

The reason migrations damage search traffic is that URLs change. Typical default patterns, which a theme or settings can alter, look like this:

Page type Shopify default pattern WooCommerce default pattern
Product /products/product-handle /product/product-slug/ or a shop-base variation
Category or collection /collections/collection-handle /product-category/category-slug/
Product within a collection /collections/collection-handle/products/product-handle (also reachable) Not applicable by default
Content page /pages/page-handle /page-slug/
Blog post /blogs/news/post-handle /post-slug/ or a date-based pattern, depending on permalink settings

Because of this, even a store that keeps identical product names will change every address when it moves between these two platforms. In WooCommerce the permalink settings and product-base setting can be configured to mimic some patterns, but exact mimicry of a Shopify structure is not always possible. Plan on redirecting, not on matching.

Where the new platform allows it, choose product slugs that match the old handles so that redirects can be simple rules rather than thousands of individual lines. Even then, the folder prefix changes, so a rule is needed.

Why URL preservation beats clever redesign

Search engines treat a new URL as a new page. Redirects carry most of the value of the old one, but not instantly and not perfectly. Keep the number of changes low: fewer URL changes, fewer chances for something to be missed. If a redesign of the category structure is also wanted, do it as a second phase a few months after the platform move, so that you can tell what caused any change in traffic.

Step 3: Build the redirect map

A redirect map is a two-column table: old URL, new URL. It is the single most important deliverable in a migration.

  1. Collect the old URLs. Combine the XML sitemap, a full crawl of the live store, the landing pages report from your analytics, the Pages report from Search Console, and any list of backlinks you can export. Remove duplicates.
  2. Prioritise. Sort by traffic and by links. The top few hundred URLs deserve a manual check. The long tail can use pattern-based rules.
  3. Map each old URL to its closest equivalent. A product maps to the same product. A discontinued product maps to the most relevant category or a successor product, not to the home page. Sending everything to the home page is treated by Google as a soft 404 in many cases and gives the visitor nothing.
  4. Use permanent (301) redirects. Temporary 302s do not signal that the move is permanent.
  5. Avoid chains. A redirects to B, which redirects to C, wastes crawling and slows the visitor. Point A directly at C. Check that existing redirects on the old platform do not form chains when combined with new ones.
  6. Keep parameters in mind. Old URLs with tracking parameters, filter parameters or variant parameters may need rules.
  7. Test the map in staging before launch, using a crawler in list mode, and again on launch day.

Our guides to 404 errors and redirects and to the redirect map for a domain change contain more detail on the mechanics, and the same method applies when the domain stays the same.

Where redirects live on each platform

On Shopify, redirects are managed in the admin under URL redirects, where a CSV of old and new paths can be imported. On WooCommerce, redirects can be set with a redirect plugin or with server rules in the web server configuration, and the best choice for very large lists is usually the server because it is faster. On a custom build, redirects are implemented in the application or at the web server or CDN. Ask your developer where the redirects will live, who will maintain them, and how they will be kept when the site is later rebuilt.

Note that Search Console's Change of Address tool is for moves from one domain to another. If the domain stays the same and only the platform changes, you do not use it; you rely on correct redirects and an updated sitemap.

Step 4: Move the product data cleanly

Export and import

Both major platforms support CSV export and import for products. The columns differ, so a mapping step is required. Typical issues:

  • Variants. Shopify represents variants as extra rows under a product; WooCommerce uses variable products with attributes. The structure maps, but the spreadsheet needs transformation, and attribute naming should be tidied during the move.
  • Images. Image URLs in an export usually point to the old store's CDN. Import tools generally fetch them; confirm that all image files arrive and that the alt text is preserved. Keep image file names descriptive where possible.
  • Descriptions. HTML in descriptions may contain classes or shortcodes from the old theme that mean nothing on the new one. Clean them.
  • Stock levels. Freeze inventory changes or reconcile after the final import, as stock sold during the migration will otherwise be wrong.
  • SEO fields. Page titles and meta descriptions often live in separate fields or an SEO plugin. Export and import them, otherwise every product title tag will reset to a default. See our guide to writing page titles and meta descriptions.
  • Structured data. Check that product schema, price and availability are output on the new store. See product schema for Shopify and WooCommerce.
  • Product data quality. A migration is the best moment to fix missing weights, inconsistent units and duplicate SKUs. Our piece on preparing product catalogue data shows how.

Import a small batch first, review it visually, then import the rest.

Step 5: Customers, orders, reviews and subscriptions

These four need separate decisions.

Customer accounts

Customer names, emails and addresses can be exported and imported on most platforms. Passwords are the sticking point. Shopify does not export customer passwords, and most platforms store passwords as hashes that are not portable between systems. The standard solution is to import the customer records and invite customers to set a new password the first time they log in, with a clear email explaining why. Plan that message. Do not email customers who have not agreed to marketing emails with promotional content; a service message about their account is different from marketing, but get advice if unsure. Respect the consent status you exported. The data-protection side is covered in our article on DPDP Act website compliance.

Order history

Old orders have three uses: customer support, repeat purchase, and your accounting and tax records. For the first two, importing recent orders so that customers can see them in their account is helpful but not essential. For the third, what matters is that you can produce invoices and records for the period the law requires you to keep them. Ask your accountant how long and in what form. Keep a full export of orders and invoices from the old platform in a secure place, even if you import only a subset to the new one, and do not cancel the old platform's account until you have confirmed that the export is complete and readable. Our order history and reorder guide describes what a customer account area should offer once the data is there.

Reviews and ratings

Reviews are valuable for conversion and are often held in a third-party app. Check whether that app can export, whether the new platform's equivalent can import, and whether the review dates and verified-buyer flags survive. Sometimes the best route is to keep the same review app on the new platform, if it supports it. Do not recreate reviews by hand or invent them; imported reviews should be real reviews from real customers. Our article on product reviews and ratings systems has more.

Subscriptions and saved payment methods

These are the hardest items. Recurring subscriptions depend on a stored payment token held by a payment provider, and moving tokens between systems generally needs support from the provider and sometimes from the customer. If your store sells subscriptions, ask your payment provider early whether and how tokens can be transferred to the new platform, and what the customer must do. If it cannot be done, plan a transition where customers re-authorise. See our guide on subscription commerce for the design side.

Step 6: Rebuild integrations and tracking

For each integration on your inventory list, assign an owner and a test.

  • Payment gateway. Connect the gateway on the new store and run live test transactions of small value, including a failure, a refund and a cancelled payment.
  • Shipping and couriers. Configure rates, delivery estimates and tracking. Place real test orders for different pincodes.
  • Accounting and invoicing. Confirm that invoices carry the correct business details and tax fields, and that the accounting integration receives orders.
  • Analytics and ad pixels. Re-install analytics, the ad platform tags and the conversion events, and check the purchase event on a real test order. Our guide on order confirmation pages and tracking lists what to verify.
  • Product feeds. Rebuild the feed for Google Merchant Center and Meta catalogue, as product identifiers and URLs will change. See Merchant Center and Meta catalogue ads.
  • Email and WhatsApp. Reconnect abandoned-cart flows, order notifications and WhatsApp messages, after confirming the sender setup. See transactional emails and our WhatsApp commerce service page.
  • Search Console and sitemap. Verify the property if the platform changes the verification method, and submit the new sitemap.

Step 7: Test on staging, as a customer would

A migration is not ready because the import finished. It is ready when a person who has never seen the store can complete each of the journeys below without help. Protect the staging site with a password and keep it out of search, as described in our article on robots.txt, noindex and staging sites.

  1. Search for a product, filter it, open it, choose a variant, add it to the cart.
  2. Apply a discount code, change quantity, remove an item.
  3. Check out as a guest and as a registered customer.
  4. Pay using each payment method you offer, including a failure.
  5. Receive the confirmation email and any WhatsApp message.
  6. Log in to an imported account using the password reset flow.
  7. Track an order, request a return, or contact support, depending on what you offer.
  8. Run the redirect list through a crawler and confirm every old URL ends at a single 200 page.
  9. Check mobile layouts, page speed and the main product and category templates against your current baseline. See store speed and Core Web Vitals.
  10. Run through the broader pre-launch testing checklist.

Step 8: Launch day

  • Pick a quiet time. Choose a low-traffic day and avoid festival or sale periods. If your sales peak around a season, plan the migration well before it or after it.
  • Lower DNS TTL in advance, a day or two before, so that the switch propagates quickly. Check with your host on how to do this.
  • Freeze changes. Stop product edits and new orders on the old store for the final sync window, or use a delta import for orders placed after the main import.
  • Take final backups of the old store, including database, files and exports.
  • Switch the domain and confirm HTTPS works on every page.
  • Turn on the redirects and run the full crawl against the live site.
  • Remove staging protections that should not be live, and confirm that the live site does not carry a noindex setting from staging. This is the most common launch-day mistake.
  • Place a real order on the live store, and confirm payment, email, accounting and analytics.
  • Keep the old store accessible in a non-public state for at least some weeks, in case data needs checking.

Step 9: The first eight weeks after launch

Expect some movement. A short dip in organic traffic after a platform change is common and not necessarily a sign of failure; a sustained drop is a sign that something was missed. Monitor:

  • Search Console Pages report for new "Not found (404)", "Page with redirect", and "Excluded by noindex" entries.
  • Crawl stats and sitemaps to confirm Google is fetching the new URLs.
  • Organic landing pages and revenue against the previous period, allowing for seasonality.
  • Server logs or a crawler for redirect chains and errors.
  • Customer support enquiries about login, missing orders and payment problems, which reveal gaps fastest.
  • Ranking and click changes on your top fifty URLs, noted weekly.

Keep the redirects in place for a long time. The common advice is at least a year, and for URLs with strong external links, indefinitely, because removing a redirect removes the path that carries any remaining value.

What a sensible scope document should contain

If you are commissioning the work from an agency, ask for a written scope that names the inventory and retire decisions, the redirect map with its test method, the product, customer and order migration approach (including passwords and consent), the integration list with owners, a password-protected staging site with test results, a launch plan with a rollback option, a post-launch monitoring period, and what is excluded, such as new design, new features and product photography. If a proposal says "migration included" without this detail, ask for it.

When a migration is not the answer

If the real problem is slow pages, weak product photography or poor conversion, a new platform will not solve it. Fix what is broken on the current store first; our product page conversion checklist is a cheaper place to begin, and the guidance on whether to rebuild or redesign a website applies to stores as well.

Frequently Asked Questions

Will I lose my Google rankings if I move my store to a different platform?

Not necessarily. Rankings are usually protected by keeping content and page quality the same and redirecting every old URL permanently to its closest equivalent on the new store. Some short-term fluctuation is common. Losses mostly come from missing redirects, accidental noindex settings or lost page titles.

Can I move customer passwords to the new store?

Generally no. Platforms store passwords in a form that is not portable, and Shopify does not export them. Import the customer records and ask customers to set a new password through a reset email.

How long does an ecommerce platform migration take?

It depends on catalogue size, custom features, the number of integrations and how clean the data is. A small, simple catalogue can be moved in a few weeks; a store with custom logic, subscriptions or multiple integrations takes longer. Ask for a written plan with milestones rather than a single estimate.

Do I need to tell Google I changed platforms?

Not through a special tool if the domain stays the same. Submit the new XML sitemap in Search Console, make sure redirects work, and monitor the Pages report. The Change of Address tool is only for moves to a different domain.

Should I keep my old store running after the new one goes live?

Keep it accessible in a private state for some weeks so you can check data, and keep full exports of products, customers and orders for as long as your accountant advises. Do not cancel the account until you have verified those exports.

Where to Start

Before speaking to any developer, spend an afternoon on the inventory spreadsheet and export your top landing pages from analytics and Search Console. Those two files tell you what is at stake and let you judge any proposal against it.

Govindani Infotech is a website design and development company in Pune, at Landmark Plaza, Satara Road, Parvati Paytha. We build and rebuild online stores on Shopify, WooCommerce and custom stacks; see our ecommerce development services and website creation services. To discuss a move, contact us or call 092019 58274.

Sources:

Need Help With Your Digital Strategy?

Govindani Infotech helps Indian businesses and NGOs build websites, run ads, and grow online. Contact us for a free consultation.