Custom Platform to Shopify Migration: How to Move Off a Custom-Built or Legacy Store
A custom platform to Shopify migration has no shortcut. There is no connector that understands your database, no standard export, and often no complete documentation of how the platform behaves. The work starts with finding out what the system actually does, then rebuilding the parts that matter on Shopify.
This guide is for store owners and ecommerce managers running a bespoke build, an in-house PHP or .NET system, or an old platform the vendor no longer develops. It covers how we approach these projects and where they usually go wrong.
Why merchants leave custom platforms
The reasons are rarely about features. They are about risk and cost.
- Key-person dependency. One developer or one agency understands the code. When they leave, nobody can safely change checkout or pricing.
- Security and compliance. Custom checkouts carry PCI DSS responsibilities, server patching and framework upgrades. Every unpatched dependency is a liability.
- Slow change. A new landing page, a payment method or a promotion type needs a development ticket. Marketing teams wait weeks for changes that are a setting on Shopify.
- Integration drag. Each new tool needs a custom integration, where on Shopify most already exist as apps.
- Hosting and scaling. Peak trading days mean capacity planning and late-night monitoring. Shopify handles hosting, scaling and checkout uptime for you.
If any of these sound familiar, the question is not whether to move but how to move without losing data, rankings or the business rules your team relies on.
What moves in a custom platform to Shopify migration, and what doesn't
With no standard connector, every record is mapped field by field. Most commerce data has a clear destination.
- Products and variants: yes, with mapping. SKUs, prices, stock and media are transformed into Shopify products and variants. Shopify allows up to 2,048 variants per product but no more than three options, so products with four or more attributes need restructuring.
- Categories and custom attributes: yes. Categories become collections. Custom attributes move to metafields or metaobjects.
- Customers and addresses: yes. Bring email marketing consent across so your list stays lawful.
- Customer passwords: no. Passwords are stored as one-way hashes and can't be transferred. Customers activate their Shopify account or sign in with a one-time code.
- Order history: yes. Orders are imported through the Shopify API or a tool like Matrixify, linked to customers, without sending emails, taking payments or changing stock.
- Content and blog posts: yes. Pages and posts move to Shopify pages, blogs and metaobjects. Layouts are rebuilt in the theme.
- Reviews: yes, via a review app. Export the review data and import it into your chosen Shopify review app.
- Customer-specific pricing: yes, with mapping. This becomes discounts, B2B catalogues on Shopify Plus, or custom logic, depending on the rule.
- Discount logic: recreated. Rebuilt with Shopify discounts or Shopify Functions.
- Gift cards and store credit: partly. Balances are reconciled and recreated in Shopify.
- Subscriptions: depends. Recurring orders move to a Shopify subscription app. Whether saved payment details can move depends on your payment provider.
- Custom code: no. Nothing runs as-is. Each feature is replaced by a native Shopify feature, an app, or new custom code.
Source discovery: the step generic guides skip
On a known platform you can look up how data is stored. On a custom build you have to find out. We start with three questions.
1. What can we read?
Ideally read-only access to the database or an API, plus any existing exports, the code repository and whatever documentation exists. Check how records are identified, how they relate to each other, and how much history there is.
2. What does the platform actually do?
Undocumented rules live in code, in data and in people's habits. We trace them through real orders, storefront behaviour and interviews with the team that runs the store every day. Typical finds: a hard-coded free shipping threshold for one region, a trade price list applied by email domain, or a stock rule that hides products below a set quantity.
3. What talks to it?
List every system that sends or receives data: ERP, warehouse, accounting, marketplaces, email, feeds. For each one, note which system owns the data, how often it syncs and who supports it.
4. What is worth keeping?
Legacy databases collect clutter: test products, duplicate customers, abandoned carts, discontinued lines and years of logs. Decide before the build what moves and what stays behind in the read-only archive. A common split is to move every active product, every customer with a valid email, and all orders from the last few years, then archive the rest. Customers can still see older orders if the team can look them up in the archive, and the Shopify import is smaller, faster and easier to reconcile.
Make the rules explicit, for example "customers with no order and no login in five years stay behind", and get sign-off from finance and customer service before anything runs.
Pre-migration checklist
- Secure read-only access to the database, API or exports.
- Identify a stable unique key for every product, customer and order.
- Count records: products, variants, customers, orders, reviews and content pages.
- Write down every pricing, discount, shipping and tax rule, with an example order for each.
- Crawl the site with Screaming Frog or Sitebulb and export every indexable URL.
- Pull 12 months of Google Search Console and GA4 data to find the pages that earn traffic and revenue.
- List integrations, owners and data direction.
- Decide how long the old platform stays available in read-only mode after launch.
- Agree a freeze window for content and catalogue changes.
Step-by-step custom platform to Shopify migration
- Technical discovery. Inspect the architecture, data, integrations and hosting.
- Reconstruct the requirements. Document the business rules and workflows found during discovery, and agree which ones survive.
- Design the Shopify architecture. Decide the catalogue model (products, options, metafields), customer and B2B setup, Markets, apps and integration approach.
- Build the extraction and transformation. Write repeatable scripts that pull from the source, clean the data and output it in Shopify's format. Shopify's own Store Migration app covers named platforms only, and migration services such as Cart2Cart and LitExtension are built around known platforms, so a custom build usually needs its own pipeline.
- Load into a development store. Use Matrixify for spreadsheet-based imports, or the Shopify Admin API for larger or more complex datasets. Every run should be repeatable from scratch.
- Reconcile. Compare record counts and totals between source and Shopify. Spot-check edge cases: refunded orders, multi-address customers, products with unusual options.
- Build the storefront and integrations. Rebuild templates, connect the ERP and other systems, and configure payments, shipping and tax.
- Validate in parallel. Run test orders through every payment method and rule, and compare the results with what the old platform would have done.
- Cut over. Freeze, run the final delta, import redirects, switch DNS, and keep a named owner for each integration on launch day.
- Monitor. Watch orders, integrations, 404s and Search Console for at least 30 days.
SEO: URL mapping and 301 redirects from a custom platform
Custom platforms produce every kind of URL: /product.php?id=123, /p/123/blue-runner, /shop/trainers/blue-runner.html, .aspx pages, and session or tracking parameters. Shopify uses fixed patterns: /products/handle, /collections/handle, /pages/handle and /blogs/blog-name/post-handle. Nearly every indexable URL will change.
Build the URL inventory from several sources
A crawl alone misses pages that are no longer linked internally but still rank. Combine:
- a full crawl of the live site,
- Google Search Console pages with impressions,
- GA4 landing pages,
- backlink data for the pages other sites link to,
- the routing rules in the code, where available.
Map and test
- Match products by SKU or the source product ID, then generate the Shopify handle.
- Send each category to its matching collection. Merged categories go to the closest match, not the homepage.
- Import the map under Content, Menus, URL redirects using Shopify's CSV template. Standard stores allow up to 100,000 redirects.
- Watch out for query strings. Shopify's documentation says URLs with query parameters might not redirect as expected. If your important URLs look like /product.php?id=123, test them early and plan a workaround before launch.
- Shopify can't redirect a .html URL to the same path without .html, and only redirects URLs that would otherwise 404. Test a sample of every URL type on launch day.
Carry over meta titles, descriptions, image alt text and structured data, and update internal links in content so they point at the new URLs directly.
Replacing custom features with Shopify apps and native tools
- Custom attributes and filters: metafields and the Search & Discovery app.
- Custom page layouts: theme sections, templates and metaobjects your team can edit without a developer.
- Bespoke pricing and discounts: Shopify discounts, Shopify Functions, and B2B catalogues on Shopify Plus.
- Back-office automation: Shopify Flow for tagging, alerts and routing.
- Multi-currency and languages: Shopify Markets and Translate & Adapt.
- Bulk data management: Matrixify.
- Anything genuinely unique: a custom Shopify app, scoped to that feature only.
The aim is a store with less custom code than you started with, so that the next change doesn't depend on one person.
Timeline and team
A custom platform to Shopify migration typically takes 4 to 6 weeks, and longer when discovery turns up complex integrations or undocumented rules. A rough split:
- Week 1: discovery, rule inventory and Shopify architecture.
- Weeks 2 to 4: pipeline build, test migrations, storefront and integrations.
- Weeks 5 to 6: parallel validation, cutover and monitoring.
From your side, involve the person who knows the legacy system best, whether that's an in-house developer or the agency that built it, plus the people who run orders, customer service and finance. Their knowledge is what turns hidden rules into documented ones.
Common mistakes in custom platform migrations
- Skipping discovery. Assumptions about the data become launch-day surprises.
- Recreating every legacy rule. Some rules exist only because of old workarounds. Rebuild what the business still needs.
- One-off imports. If the migration can't be re-run from scratch, every fix is manual and the final sync is risky.
- Building the redirect list from a crawl only. Pages that rank but aren't linked internally get missed.
- Switching off the old system too soon. Keep it read-only for reference, reporting and customer service queries.
- Leaving integrations to the last week. ERP and warehouse connections are where cutover problems surface.
Custom platform to Shopify migration FAQ
Usually, yes. Read-only database access or regular exports are often enough. We confirm what can be extracted during discovery, before scoping the rest.
Yes. Historical orders can be imported and linked to customers without triggering emails, payments or stock changes.
Yes. Passwords are stored as one-way hashes, so customers activate their Shopify accounts or sign in with a one-time code.
Not if every valuable URL is mapped and redirected, and metadata and internal links move with it. Expect some movement for a few weeks after launch.
Yes. Many teams keep it available in read-only mode for reference, reporting and support for a set period.










