The first deliverable in a custom platform to Shopify migration is usually a document that does not exist yet: a plain description of what the old system actually does. The data can be exported one way or another; the rules wrapped around it are harder to reach. How a trade price is calculated, which orders are held for a manual check, what the platform sends to the accounting system each night: on an ageing custom build, answers like these often live in the code and in the memory of the one developer who wrote it.
That is also where most of the disruption risk sits. Trading is rarely disrupted by a malformed product file. It is more often disrupted weeks after launch, when a wholesale customer sees retail prices or a nightly export quietly stops. Keeping the business running through the move depends mainly on sequence: write down the business logic, decide where each rule will live on Shopify, rehearse the data move until the numbers reconcile, and switch over in a short, planned window with the old system kept as a read-only reference. For established stores addressing these constraints, working with a dedicated Shopify migration services ensures diagnostics translate directly into measurable revenue gains.
Why Leaving a Legacy Custom Platform Is Different
Moving from a packaged platform such as WooCommerce or Magento follows a well-worn path, because migration apps already know those databases. A bespoke build has no such shortcut. Shopify’s own guidance lists five routes, from copying content by hand and CSV imports to App Store migration apps, hiring a Shopify Partner, or building a custom migration solution with the Shopify API. For a legacy platform with its own database design, the realistic choice usually narrows to CSV files for the simple data and custom scripts for everything else.
The data is usually the easier half
A bespoke database can be read and mapped field by field, however unusual its structure. What a query does not reveal is meaning. A column called status may hold five values, two of which the checkout treats as a reason to refuse an order. A product flagged as hidden may still be orderable through a trade portal. Those meanings sit in the application code, which is why a field map built without reading that code can be technically complete and commercially wrong.
Knowledge held by one developer
Dependence on one developer is often what prompts the migration in the first place. Writing about legacy integrations, Salesforce observes that the IT knowledge gap is widening, with many current developers unfamiliar with older technology, and cites MuleSoft research that names a lack of IT skill sets as the top challenge to digital transformation. For a retailer, the consequence is specific: if the one person who understands the legacy platform leaves mid-project, the migration loses its best source of truth when it needs it most. Store owners who want an independent baseline before committing development hours can request a free store diagnostic to pinpoint the highest-leverage fixes.
That makes the developer’s time one of the first inputs to secure. A short, paid engagement to explain the system and answer questions during testing often costs less than reverse-engineering behaviour after launch. Where the original developer has already left, the knowledge has to be rebuilt from the code, the database and the staff who use the admin daily, and the plan should allow for that slower route.
Documenting the Business Logic Before Anything Moves
The aim of this stage is a logic register: a list of every rule the platform applies, who relies on it and what happens if it stops. A spreadsheet with one row per behaviour, where it lives in the code, the team that depends on it and a decision column is usually enough. On custom builds, the undocumented behaviour tends to cluster in a few places:
- Pricing and discounts. Customer-specific prices, quantity breaks, price lists by country and promotions that stack in ways the marketing team stopped questioning years ago. Errors here are visible to customers on day one.
- Order handling. Orders held for credit or fraud checks, split shipments, routing to particular warehouses and any manual step the platform prompts staff to perform. Losing one changes what reaches the warehouse.
- Scheduled jobs. Nightly exports to accounting, supplier stock files and feeds for marketplaces or price comparison sites. They run out of sight, so they tend to be noticed only when they stop.
- Customer rules. Trade accounts, tax-exempt customers, restricted catalogues and approval steps for new business buyers, often coded as exceptions.
- Messages. Emails and notifications triggered by status changes that customer service relies on.
Tracing a handful of real orders from basket to invoice, with the developer and someone from operations in the room, tends to surface more than reading the code alone. Orders that went wrong in the past are particularly useful, because exceptions are where hidden business logic shows itself.
Every row then needs a decision. Retain means the rule must work on Shopify from launch day. Replace means the outcome matters but the method can change, for example a manual approval replaced by an automated tag and an alert to the sales team. Retire means the business no longer needs it. On older builds, the retire column is often longer than expected, and each retired rule is one less thing to rebuild, test and maintain.
Where Each Rule Can Live on Shopify
Every retained or replaced rule then needs a home on the new platform. The options below cover most of what a legacy platform does, each with a different cost in flexibility.
| Type of custom logic | Typical Shopify home | Works well when | Trade-off |
|---|---|---|---|
| Extra product or customer data, such as specifications or size charts | Metafields and metaobjects | The data is descriptive and shown in the theme or admin | Structure needs designing up front; free-text legacy fields often need cleaning |
| Back-office workflows such as tagging, holds and alerts | Shopify Flow | The rule fits a trigger, a condition and an action | Long workflows get hard to read; some actions depend on plan |
| Checkout pricing, discount, payment and delivery rules | Apps built on Shopify Functions, or a custom app on Plus | The rule fits a discount, payment or delivery customisation | Custom apps with Function APIs require Shopify Plus |
| Stock, order and invoice sync with ERP or accounting | App connector, middleware or custom integration | A supported connector exists for the back-office system | In-house or older systems often need bespoke work |
| Rules that no longer serve the business | Retired, with the decision recorded | No team can name a current use or owner | A forgotten dependency can resurface, so keep the old code accessible |
Shopify describes metaobjects as custom data structures with multiple related fields, which suits legacy attributes that used to sit in a bespoke table. Shopify Flow runs on triggers, conditions and actions and is available on the Basic, Grow, Advanced and Plus plans, although some of its actions are restricted by plan. For checkout behaviour, Shopify Functions are the extension point: stores on any plan can use public apps that contain functions, while custom apps with Function APIs are limited to Shopify Plus.
That distinction often settles the plan question. A store whose retained business logic fits Flow, metafields and existing apps may run comfortably on a standard plan. A store whose trade pricing needs a custom function may need Plus, or a simpler pricing model. Either answer can be right; the expensive version is finding out after the store has been built.
Sometimes the register points away from Shopify altogether. When the custom logic is the product itself, such as a configurator that prices made-to-order goods from dozens of inputs, forcing it into apps and functions may cost more than modernising the existing platform or rebuilding it on a more flexible stack. If the case for leaving is not yet settled, our article on the signs a custom website has outgrown its build covers that earlier decision.
Moving Data Out of a Bespoke Database
In a custom platform to Shopify migration, data usually moves through extraction scripts written against the old database, a mapping layer that reshapes records into Shopify’s model, and an import through CSV files or the Admin API. Shopify’s productSet mutation is intended for syncing product information from an external data source, which makes it a natural fit for the repeated catalogue loads a rehearsal needs. Shopify’s guidance also sets an import order of products, then customers, then historical orders, so each order can link to the right records.
Two practices do most of the work of keeping that process trustworthy. The first is an ID crosswalk: a table linking each old product, variant, customer and order ID to its new Shopify ID. Integrations, redirects and support queries lean on it after launch. The second is rehearsal. HubSpot’s guide to CRM data migration recommends that the first migration runs in a sandbox rather than in production, and suggests running that sandbox migration at least twice. Applied to a store, the first rehearsal on a development store exposes mapping gaps, and the second shows whether the fixes held.
Each rehearsal should end in reconciliation rather than a visual check. Record counts by type, order totals by month and a sample of records compared field by field give the business something objective to approve. When the numbers disagree, the cause is usually a mapping rule that misread the legacy platform’s data, and fixing it in rehearsal is considerably cheaper than in the first week of trading.
Handling URLs in a Custom Platform to Shopify Migration
Custom builds often have URL patterns of their own design, with category paths, file extensions or query parameters that carry meaning. Shopify’s structure is fixed by comparison. Its Help Center notes that redirects cannot be created for the fixed /products, /collections and /collections/all paths, and that redirects can only be added from URLs that are broken on the Shopify store. The redirect map therefore has to be built from the old URL list towards Shopify’s structure, not the other way round.
Google Search Central’s advice on moving a site with URL changes asks for a mapping of old URLs to new ones, recommends permanent server-side redirects and suggests keeping them for as long as possible, generally at least a year. It also warns that rankings may fluctuate while the site is recrawled. The mechanics of building and testing a redirect map are covered in our guide to 301 redirects for Shopify migrations.
Keeping Day-to-Day Trading Steady Through the Cutover
Disruption has two sources: the hours around the switch, and the weeks after it, when unfamiliar behaviour reaches customers and staff. A good cutover plan addresses both.
One cutover, a phased move or parallel running
A single cutover moves the storefront, data and integrations together in one planned window. Google recommends moving all URLs at once for small and medium sites, and for most stores this approach keeps the period of uncertainty short. Its weakness is that problems tend to surface together, so it depends on thorough rehearsal.
A phased move separates parts of the system and moves them in sequence. On a custom build, the most useful split is often between back office and storefront: rebuilding the ERP or accounting connection on middleware while the old site is still trading, then moving the storefront once that link is proven. The cost is a longer project and temporary connections maintained on both sides.
Running two live stores in parallel sounds safest but tends to create the most work, because stock, prices, orders and customer accounts have to stay consistent across both. It can be justified for one segment, such as a trade portal that moves after the retail store, but rarely for the whole business.
A cutover sequence that protects trading
- Agree a change freeze. Stop catalogue, content and price changes on the legacy platform for a defined period before launch, so the final data load is not chasing a moving target.
- Run the final full load and reconcile it. Compare counts and values against the baseline used in rehearsal, by record type.
- Stop orders on the old platform and load the delta. Move the orders, customers and balance changes created since the full load. HubSpot’s CRM guidance uses the same freeze-then-delta pattern.
- Switch integrations and smoke-test them. Follow real orders through payment, stock deduction, the warehouse or ERP handoff and customer emails.
- Point the domain at Shopify and activate redirects. Crawl the old URL list to confirm that each address resolves to a live page in one hop.
- Keep the legacy platform read-only. HubSpot suggests at least two weeks for a CRM; for a store, the returns window and the next accounting close are better guides to how long the old data must stay accessible.
- Monitor the first weeks with named owners. Track failed integration calls, 404 errors, order exceptions and customer service themes, with the developer who knows the legacy platform available for questions.
Timing matters as much as sequence. Launching in the quietest part of the trading week, well clear of peak season or a major promotion, gives the team room to fix what the rehearsals missed.
Key takeaway: on a legacy custom build, the risk to trading sits less in the data than in the undocumented rules around it. A written logic register, two reconciled rehearsals and a short, frozen cutover window protect day-to-day sales far better than a fast launch date.
Mistakes That Turn a Migration Into a Disruption
- Treating the developer as an exporter. Asking only for data dumps leaves the business logic undocumented, and the gaps tend to appear after launch, in front of customers.
- Rebuilding every rule by default. Recreating features that no team uses adds cost and testing time, and carries old complexity onto the new platform.
- Forgetting outbound feeds. Accounting exports, marketplace feeds and supplier files rarely appear on a feature list, so their absence may go unnoticed until a month-end reconciliation fails.
What a Legacy Rebuild Showed About the System Underneath
WD Market’s work with Saules Aptieka, a Latvian pharmacy brand, was a rebuild on Magento rather than a Shopify migration, so it illustrates a principle rather than the destination. The case study describes a legacy eCommerce platform that “was outdated and no longer competitive in the Latvian market”, no seamless integration with internal systems for stock and order management, and manual stock and order handling that “was creating errors and operational inefficiency”.
The rebuild treated that connection as core scope, integrating the new platform with the client’s custom internal ERP for automated stock synchronisation, order processing and real-time inventory updates. The Saules Aptieka case study carries a lesson for any custom platform to Shopify migration: the storefront is the visible part, but the links to internal systems, and the manual workarounds built around their absence, often decide whether daily operations feel easier after launch.
Internal expert input required: add how the legacy platform’s data and business rules were handled during the Saules Aptieka rebuild, or a verified example from a custom platform migration to Shopify that can be published.
Leaving the Custom Build on Your Own Terms
A custom platform to Shopify migration is less a data problem than a knowledge problem. The disruption owners worry about usually traces back to rules that were not written down, so the work starts with a logic register and a retain, replace or retire decision for each rule. Platform fit, plan tier, rehearsals and cutover then follow with fewer surprises. Secure the developer’s knowledge early, reconcile rather than eyeball, and keep the old system readable after launch. Where the register shows that the custom logic is the business itself, modernising the current platform remains a valid outcome.
From an Undocumented Build to a Planned Shopify Launch
The first stage of WD Market’s Shopify migration services is a feasibility assessment that reviews existing platform functionality and custom logic, sorts it into what can be migrated fully, replaced or simplified, and sets out Shopify’s limitations alongside workable alternatives before development is committed. The stated approach is to raise anything Shopify cannot do early and propose a workaround, so hard-to-move business logic is treated as a finding rather than a reason to push ahead.
To discuss a specific build, share the platform’s background through our contact page, ideally with a rough picture of the integrations it runs and who maintains it today. For shorter notes on replatforming, integrations and legacy systems, follow WD Market on LinkedIn.
Custom Platform Migration: Common Questions
How long does a custom platform to Shopify migration take?
The duration depends mainly on how much business logic has to be rebuilt and how many systems the platform connects to, rather than on catalogue size alone. A store with simple pricing and one accounting export can move far faster than one with trade pricing, warehouse routing and an ERP link. A dependable estimate usually becomes possible once the logic register is complete and the rebuild work can be scoped. Rehearsals and post-launch monitoring belong in the timeline from the start.
Can we migrate if the developer who built the platform has left?
Yes, although it is slower and carries more risk. The missing knowledge has to be reconstructed from the code, the database structure and the people who use the admin daily, such as customer service and warehouse staff. Following real orders from checkout to invoice is especially useful in this situation, because it exposes behaviour that staff did not think to mention. Budget for extra discovery time.
Do we need Shopify Plus to keep our custom logic?
Only in some cases. Public apps from the Shopify App Store that use Shopify Functions can be installed on any plan, so many pricing and checkout rules can be covered without Plus. Plus becomes relevant when a rule needs a custom app that contains Function APIs, or when other Plus-only features are required. Which situation applies depends on the documented rules, so the plan decision is better made after the logic register is finished than before it.
What happens to order history held in a custom database?
Historical orders can be imported through the Shopify API after products and customers, so that each order links to the correct records and staff can look it up. Some businesses import only recent orders, such as those still within the returns window, and keep the full archive in a read-only database or data warehouse. The right split depends on how often the team and customers need older records, and on what finance needs for reporting.