How to Move a Custom-Coded Website to Shopify in India
If your store runs on code a local agency wrote for you in PHP, Laravel or React, moving to Shopify is a different job from moving off WooCommerce. There is no importer that understands your database, your URLs follow rules nobody wrote down, and the people who hold the server keys may not be around any more. This guide covers what moves and how, what happens to customer logins, how to protect your search rankings, and which custom features to rebuild or drop.
Import limits and methods below are from Shopify's Help Centre and developer documentation, checked on 30 September 2026.

Photo: qubodup via Flickr, CC BY 2.0
Why is a custom-coded site harder to move than WooCommerce?
Because every migration tool assumes a platform it recognises. Shopify's migration documentation has guides for named platforms such as WooCommerce, Wix, Squarespace, Etsy and Amazon. A site your agency built from scratch is not one of them. Its products might sit in a MySQL table designed in 2019, its categories in a second table, its images in a folder on the server, and its prices partly calculated in code.
So a custom migration always starts with someone reading your database and turning it into the formats Shopify accepts. Shopify offers two routes: CSV files for products and customers, and the API or a migration app for everything CSV cannot carry, including orders, blog posts and pages. Neither route knows your old structure. That translation is the real work, and it is where most of the effort in these projects goes.
If you are on WooCommerce or Magento rather than custom code, read our WooCommerce to Shopify migration guide instead, because the tooling there is far better.
Who controls your data before you start?
Find this out before you agree a migration date with anyone. On a custom site, the data you need usually sits in places you have never logged into yourself:
- The database. Products, customers and orders. You need a full export or read access, not a spreadsheet someone makes for you.
- The server or hosting account. Product images, downloadable files and anything uploaded through the old admin.
- The domain registrar and DNS. You will point the domain at Shopify on launch day, so you need to control it.
- Payment gateway and courier accounts. Razorpay, Cashfree, Shiprocket or whatever the old site used. These should be in your company's name and email.
- Google Search Console and analytics. You will need the old site's data to check that rankings survive the move.
If the agency that built the site is still friendly, ask for a database export and a list of every URL pattern the site uses. If the relationship has ended badly, our developer handover checklist covers how to get your assets back. Either way, get the export before anything else starts. A migration plan built on data you cannot reach is not a plan.
What data can move to Shopify, and how?
Most of it, through different routes. This is what Shopify documents for each type:
| Data | Route into Shopify | What to know |
|---|---|---|
| Products and variants | Product CSV import | Each CSV file can be 15 MB at most, so large catalogues are split into several files. Custom attributes need metafields set up first. |
| Customers | Customer CSV import | Also 15 MB per file. Includes marketing consent fields for email, SMS and WhatsApp, which accept only yes or no. |
| Customer passwords | Cannot be moved | Covered in the next section. |
| Orders | Migration app or API | Not possible through CSV in the admin. |
| Blog posts and pages | Migration app, API, or copy and paste | Small sites often just recreate these by hand. |
| Images | Referenced from the product data | The old server must stay online until the import finishes. |
Two decisions make the biggest difference to the effort involved.
Do you need historical orders in Shopify at all? Some stores need them, for repeat purchase analysis, customer service or loyalty points. Many do not, and keep an export of old orders in a spreadsheet or the old database for reference instead. Importing orders means an app or custom API work, so decide deliberately rather than by default.
How clean is the product data? Custom sites often store things in odd places: sizes in the product title, colours in a notes field, prices that change in code depending on the city. Every one of these has to be untangled into Shopify's product, variant and metafield structure. Budget time for cleaning, and have someone who knows the catalogue check a sample after each test import.

What happens to customer accounts and passwords?
Customer records come across, passwords do not. Shopify's customer import documentation is direct about it: "Because passwords are encrypted outside of Shopify, you can't migrate customer passwords from another online store using a CSV." That is true of any platform, because a properly built site never stores passwords in a form that can be read back.
What your customers experience depends on which customer accounts your Shopify store uses. With Shopify's current customer accounts, customers sign in with a one-time code sent to their email, so there is no password to lose. We cover how that works, including phone-based login options for Indian stores, in our guide to Shopify customer accounts and phone login. With the older password-based accounts, Shopify's documentation says you invite imported customers to create new passwords.
Either way, tell customers before launch. A short email saying the store has moved and explaining how to sign in prevents a wave of "I cannot log in" messages in your first week. Import the marketing consent fields carefully: a customer who never agreed to email marketing on the old site should not be marked as subscribed on the new one.
How do you protect SEO when your old URLs look nothing like Shopify's?
With a complete redirect map, prepared before launch. This is the biggest risk in a custom migration, and the one founders most often underestimate.
Shopify uses fixed URL patterns: products live under /products/, categories under /collections/, content pages under /pages/ and blog posts under /blogs/. Your custom site used whatever its developer chose: /product.php?id=123, /shop/mens/kurta-blue, or a different pattern for every section. None of those addresses will exist after launch unless you redirect them. Every page that ranks in Google, every link from another site and every old WhatsApp broadcast link would otherwise land on a "page not found".
Shopify's URL redirect feature lets you create redirects one at a time or import them from a CSV. On a site with more than a handful of products, the only sensible approach is a mapping built from data:
- List every old URL. Combine a crawl of the live site, the old sitemap, and the pages Google Search Console shows receiving traffic. Include category pages, content pages and blog posts, not only products.
- Match each one to its new Shopify address. Ideally by a product ID or SKU that exists in both systems, not by guessing from titles.
- Import the redirects as a CSV once the products exist in Shopify.
-
Test them. Run the old URL list through a crawler and confirm every one lands on the right page. Pay particular attention to old URLs with query strings like
?id=123, and confirm with your developer how those are being handled, because they behave differently from clean paths. - Watch Search Console after launch for pages reported as not found, and add redirects for anything the map missed.
Redirects should be live the moment the domain points to Shopify. Keep the product handles in Shopify close to the words in your old URLs where you can, and carry across your page titles and meta descriptions, so Google sees the same page at a new address rather than a new page.

Which custom features should you rebuild, replace or drop?
This is where custom migrations succeed or drag on. Your old site probably does a few things exactly the way your business wanted, and every one of them needs a decision. List them all, then put each into one of four routes:
| Route | When it fits | Examples on Indian stores |
|---|---|---|
| Built into Shopify | Shopify already does it with settings | GST tax settings, basic discount codes, multiple locations |
| App from the Shopify App Store | A common need that apps already solve | COD rules and pincode checks, WhatsApp notifications, reviews, subscriptions |
| Custom development | Genuinely specific to your business and worth paying for | An integration with your own ERP or warehouse system, unusual pricing logic |
| Drop it | Nobody would miss it, or the reason for it no longer exists | Old admin reports, features built for a campaign years ago |
Two platform facts shape the custom development route. Checkout customisation on Shopify is done through Shopify Functions and checkout extensions, not by editing checkout code. And Shopify's developer documentation states that stores on any plan can use public App Store apps that contain Functions, but "only stores on a Shopify Plus plan can use custom apps that contain Shopify Function APIs." If your old site had bespoke checkout rules and you are not planning to move to Plus, the realistic options are an existing app or changing the rule. Our article on rebuilding checkout customisations goes into what each plan allows.
For India-specific pieces, check the existing guides before commissioning anything custom: GST setup on Shopify and Razorpay and Cashfree on Shopify cover what works out of the box. In our view, founders tend to over-value features they paid to build. Ask of each one: does it make money, save real time, or matter to customers? If none of those, drop it and launch sooner.
What order should a custom site migration happen in?
The sequence matters more than the speed. Doing these in order avoids the two classic failures, launching before the data is right and launching without redirects:
- Secure access and export. Database, images, domain, and third-party accounts in your name.
- Decide features. The rebuild, replace or drop list above, agreed in writing.
- Build the Shopify store. Theme, apps, payment and shipping settings, tested with sample data.
- Transform and test-import data. Products, customers and, if you decided to, orders. Check samples against the old site.
- Build and test the redirect map. Every old URL accounted for.
- Final import and cut-over. A last data export from the old site, import, redirects live, domain pointed at Shopify, customers told how to sign in.
- Monitor. Orders, payments, Search Console errors and customer messages, daily at first.
Keep the old site and database available, even if hidden, until you are confident nothing is missing. Switching off the old server on launch day is how images and order records get lost for good.
What should a migration quote for a custom site include?
Because there is no standard tool, quotes for custom migrations vary more than for any other kind of Shopify project. A quote you can trust should spell out:
- Which data is being moved, by which route, and whether historical orders are included.
- Who writes the data transformation and how the result will be checked.
- A redirect map as a named deliverable, including how old URLs will be collected and tested.
- The feature list with a decision for each: native, app, custom build or dropped.
- What happens on launch day, and what support is included after it.
- Access and ownership: every account and app registered to your business.
If a quote says "full migration" without those details, you cannot tell what you are paying for. Our guide to reading a Shopify quote covers the rest of what a good proposal should state.
Planning a move off a custom-built site?
Free migration planning conversation. Get in touch or email hello@exactwhy.com with the subject "Custom site migration" and your current store URL. Tell us what the site is built on, roughly how many products and customers you have, whether you can get a database export, and which custom features you rely on. We reply within 4 hours with the main risks we see, what can move by which route, and what we would want to check first.
If you go ahead. We scope the migration around the redirect map and the feature decisions above, and we put both in writing before any build starts. If your site is simple enough that you could move it yourself with CSV files and an afternoon of redirects, we will tell you that too.