Migrating away from Shift4Shop to a custom store

What Shift4Shop is, and who is right to stay on it

Shift4Shop is a hosted ecommerce platform run by Shift4, the American payments company. It used to be called 3dcart, and the developer documentation still lives on the old 3dcart domain, which tells you something about its age and its roots.¹ It is a full featured store builder: product catalogue, categories, customer accounts, orders, promotions, a theme system and a long list of built in modules. For a US shop that processes cards through Shift4 Payments, the software itself can cost nothing per month, which is a genuinely strong offer.²

I want to be fair before I am critical. If you run a modest US based shop, you take payments through Shift4, and the standard themes and modules do what you need, Shift4Shop is a reasonable place to be and the price is hard to argue with. This article is not for you. It is for the shop that has outgrown the platform: the business whose checkout needs to behave in a way the theme will not allow, whose catalogue logic has outrun the built in fields, who wants to choose a payment provider on price and features rather than be told which one to use, or who simply wants to own the software that runs the shop instead of renting it. If that is you, the honest question is what a move actually costs and what moves cleanly. That is what the rest of this piece answers.

I have written the platform independent side of migration elsewhere, so I will not repeat it here. The pillar guide on what moves and what does not covers the universal rules, and the data type guides go deep on each kind of record. This article stays specific to Shift4Shop.

The free plan is a payments coupling, and that is the real trap

The headline that brings most people to Shift4Shop is the free plan. It is real, but it comes with a condition that matters enormously the day you want to leave. In Shift4Shop's own words, "the only requirement to use the free plan is that your store uses Shift4 Payments to process payments on your store".² The platform is free because the processor is not. You are paying through card processing fees, and the software rides along at no separate charge.

Two more conditions sharpen the point. The free plan is American only: "to sign up for our free plan, you must be a United States merchant", and "at this time, the free plan does not support international customers".² And Shift4 Payments "cannot process high risk transactions", so some trades are excluded outright.² If you run a shop in Britain, you were never on the free plan to begin with. You are on a paid tier, the pricing page lists an unlimited plan at $41 a month, and it warns that "a monthly SaaS fee may be charged depending on your plan and monthly processing amount".³ Either way, the economics of Shift4Shop are built around its own processor. Payments and platform are coupled.

Why does that matter for a migration? Because leaving Shift4Shop is not only a software move. It is very often a payment processor move at the same time, and those are two of the hardest things in commerce to change together. When you leave, the saved card details your customers trusted to the shop do not come with you in any usable form. The card numbers themselves never export, by design and by law, and the stored tokens are tied to Shift4's gateway, so they are meaningless to any other processor. I explain exactly why, and what the honest options are, in the guide to payment tokens and saved cards. Changing the processor under live customers also carries risks that have nothing to do with Shift4Shop and everything to do with how gateways behave, which I set out in the hidden dangers of switching payment gateways. Read both before you commit to a date.

This is the single most important thing to understand about Shift4Shop. The platform is generous precisely because it keeps you on its rails. Walking off those rails is the work.

What you own, and what is locked

It helps to separate your data, which is yours, from the machinery around it, which is not. Here is the honest split.

What moves out cleanly	What is locked or lost
Product catalogue, categories, options, images (CSV and API)⁴¹	The theme and its template language (proprietary to Shift4Shop)
Customer records: names, emails, addresses, groups (CSV and API)¹	Customer password hashes (never export; shoppers reset on first login)
Order and transaction history (API)¹	Vaulted card data and gateway tokens (tied to Shift4 Payments)
Store settings you can read back through the API¹	Built in modules and any app logic bound to the platform
Your own domain name and your content	The free monthly price, which depends on staying with Shift4 Payments²

The pattern is the one you see on every hosted platform. The records that describe your business are portable. The things that make the shop run on this particular platform are not, because they were built for it. Owning your customer accounts and addresses is straightforward. Owning the exact behaviour of the checkout, the theme and the payment vault is where the work and the honesty live.

The export and the API, and what they really hand over

Shift4Shop gives you two ways to get data out: comma separated files from the admin, and a REST API for everything programmatic. Both are usable, and neither is magic.

The CSV side is the quick path for the catalogue. The product list in the Online Store Manager has an export and import tool, you can pull either a set of basic fields or the full product data into one large file, and Shift4Shop states there is no limit on the number of products you can import this way.⁴ Category structures export and import the same way. For a one off move of a few thousand products, the CSV route is often enough, especially if you treat the exported file as a starting point and clean it before it goes anywhere near the new shop.

The API is where the real migration happens, because it exposes the records CSV does not describe well. The REST API lives at a base address of the form https://apirest.3dcart.com/3dCartWebAPI/{version}/{service}, and you authenticate each request with three headers: the merchant's secure URL, your application's private key and the merchant's token.¹ The list of resources is long and, for a migration, encouraging. It includes Customers and customer groups, Orders with their items, shipments and transactions, Products with their options, images and discounts, Promotions, Gift Certificates, and, tellingly, Payment Tokens.¹ That last one is worth a careful word: the API will hand you a token record, but a token is a reference held by Shift4's gateway, not a card. It cannot be replayed through anyone else's processor, which is exactly the point of the payment tokens guide.

The API has limits, and you should plan around them rather than be surprised by them. Shift4Shop says plainly that "to ensure the stability of our platform, we do have limitations in place for the amount of calls".⁵ The documented batch sizes are modest: a single GET returns at most 300 orders, 200 products, or 500 records for other resources, so a large catalogue or a long order history comes out in pages, not in one gulp.¹ Requests are throttled per key and per endpoint, and when you go over the limit the API returns an HTTP 429 with a Retry-After header telling you how long to wait.¹ None of this is a blocker. It simply means a full history extraction is a paced, scripted job that runs over hours, with retries and checkpoints, not a button you press once. Build it to resume, because it will need to.

One ceiling is absolute and worth stating with the rest. Customer passwords are stored as hashes, so they never come out in a form you can reuse, on Shift4Shop or anywhere else. Every shopper sets a new password on first login to the new shop, and the honest way to handle that is a planned reset email, not a silent hope that people remember. The customer accounts guide covers the wording and the timing.

The traps that are specific to Shift4Shop

Every platform has its own sharp edges. These are the ones I would flag on Shift4Shop before anything else.

The payments coupling comes first, because I have already shown it decides the shape of the whole project. If you are a US merchant on the free plan, leaving means giving up the free price, because the free price was always the price of staying on Shift4 Payments.²³ If you are outside the US, you were paying a monthly fee anyway, but you are still on a platform whose defaults, features and support assume an American processor and an American merchant account.² Either way, the move off the software and the move off the processor tend to happen together, and that is the hardest combination to sequence safely.

The theme is the second trap. Shift4Shop's storefront runs on its own template system, hosted on its own servers, and that design does not travel. Any custom work baked into the theme, any behaviour a developer added to the checkout or the product page, has to be rebuilt rather than copied. This is not unique to Shift4Shop, but it is worth naming because people often assume the look of the shop is part of what exports. It is not. What exports is the data. The appearance and the behaviour are rebuilt.

The third trap is the one search engines punish: your URLs. Shift4Shop generates its own address structure for products and categories, and a custom store will almost certainly use different paths. If the old addresses simply stop working, the rankings and the inbound links that took years to earn go with them. The fix is unglamorous and non negotiable: a complete map from every old URL to its new home, served as permanent 301 redirects, kept live for at least a year. I treat the redirect map as part of the products and catalogue data work, because the product URLs are the ones that carry the most search value, and losing them is the most common self inflicted wound in any migration.

A quieter trap is the built in module. Shift4Shop ships a great deal of functionality as platform features: email tools, certain promotions, gift registries, review handling and more. Where your shop leans on one of those, that behaviour is not in your export. It has to be re created in the new build, either natively or through a chosen service, and it needs to be on the list from the start rather than discovered on cutover day. If any of that functionality runs subscriptions or recurring billing, treat it as its own project and read the subscriptions and recurring payments guide first, because active recurring agreements are the single hardest thing to move and sometimes need the old platform's or the gateway's cooperation to move at all.

The honest move onto a custom Solidus store

When a shop has outgrown Shift4Shop and wants to own what comes next, I build the new store on Solidus, the open source Rails ecommerce framework, and I run the move. There is no licence, no revenue share and no processor you are forced to use. You pick the gateway. You own the code. Here is the shape of the work, mapped to the deeper guides so I am not repeating them.

First, the catalogue. I pull products, categories, options and images through the CSV export for the bulk and the API for anything the CSV flattens, then model them properly in Solidus rather than carrying across quirks you only tolerated because the old fields forced them. The detail is in migrating products and catalogue data.

Second, the customers. Names, emails, addresses and groups come through the API, the password hashes do not, and every account is set up to require a reset on first login. The approach is in migrating customer accounts and addresses.

Third, the orders. Historical orders, their line items, shipments and transactions come through the API, paged within the batch limits, and I load them as read only history so your reporting and your customer service keep their past. The method is in migrating order and purchase history, and if you want that history to feed forecasting, migrating analytics and historical data for forecasting explains how to keep it useful.

Fourth, and hardest, payments. This is where Shift4Shop's coupling makes itself felt. You choose a new processor, the saved cards do not transfer in any replayable form, and the safe pattern is to re capture consent and card details at the first transaction on the new shop rather than to pretend the old tokens still work. The reasoning is in payment tokens and saved cards, and the gateway risks are in the hidden dangers of switching payment gateways. If this sounds like the part to plan first, that is the correct instinct.

Fifth, the redirects and the cutover. Every old URL maps to a new one as a 301, the new shop is tested against real order data, the catalogue is frozen for the switch, and the old shop is kept readable for a month so nothing is lost in the handover. Owning your data in the legal sense matters here too, which is the subject of who actually owns your business data.

If you want to see the numbers behind all this against staying put, I have modelled the five year total cost of ownership of moving to Solidus and compared the main platforms in Solidus versus Shopify, Shopware, Magento and WooCommerce. A hosted platform in a similar shape, BigCommerce, has its own version of these same trade offs if you are comparing exits.

A worked example

Let me make it concrete with an invented shop. Northgate Tool Company (northgatetool.example) is a Leeds business selling hand tools, fixings and workwear, turning over about £1.4 million a year online. It has roughly 4,000 products with variants, a growing trade counter whose customers want account pricing and monthly invoices, and four years on Shift4Shop behind it. It is not American, so it never had the free plan. It pays a monthly platform fee, processes cards through the provider the platform steers it towards, and the checkout cannot be made to behave the way the trade side needs. The owner has decided to build a shop the business actually owns.

The first thing I do is not technical. I write down the payment questions before anything else: which processor the new shop will use, what the card fees look like against the current ones, whether any customers have saved cards they expect to still work, and whether there is any recurring billing in play. On this shop there is no subscription product, which removes the worst of the risk, but the saved cards still will not transfer, so the plan is to re capture card details at the first order on the new store and tell customers why in plain language. That decision shapes the timeline, so it comes first.²

Then the data. I script the API extraction for customers, orders and transactions, paging within the 300 order and 200 product limits and letting the job resume when the throttle returns a 429.¹ The catalogue bulk comes out as CSV because 4,000 products is comfortably inside the no limit import, and I clean the file before it goes near Solidus.⁴ Customer accounts load with a forced password reset. Orders load as read only history so the trade counter keeps every past invoice. The trade pricing the old checkout could not do becomes a proper customer group with its own price list in Solidus, which is the whole reason for the move.

Finally the switch. Every old product and category URL maps to a 301 on the new paths, the redirects stay live for a year, the new shop runs against real orders in a rehearsal, and the Shift4Shop store stays readable for thirty days after go live. The owner ends with a shop on their own code, a processor they chose on merit, invoicing the trade counter needed, and no monthly rent for the software. The whole thing turns on having asked the payment questions on day one rather than on cutover day.

When staying is the right answer, and how to decide

I will say the honest thing one more time. If you are a small US shop, happy with Shift4 Payments and the standard features, the free plan is a good deal and leaving would cost you money for no gain. The buyer for a migration is the shop that has hit a wall: a checkout that cannot change, a catalogue the fields cannot describe, a processor you did not choose, or a simple wish to own the software outright. For that shop, the move is worth it, and the risk is entirely manageable once the payment questions are answered first and the redirect map is complete.

If you are not sure which shop you are, that is exactly what the workshop is for. Bring your product count, your current payment setup and a clear picture of what the checkout cannot do today, and I will tell you honestly whether a move pays off. Sometimes it does not, and I will say so.

Shift4Shop (3dcart) REST API, getting started reference: base URL, authentication headers, the list of resources including Customers, Orders, Products and Payment Tokens, the batch sizes (300 orders, 200 products, 500 for others) and the HTTP 429 with Retry-After throttling, checked November 2026. https://apirest.3dcart.com/v1/getting-started/index.html ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰
Shift4Shop, "Build a Free Online Store", stating that the only requirement for the free plan is using Shift4 Payments, that you must be a United States merchant, that the plan does not support international customers, and that Shift4 Payments cannot process high risk transactions, checked November 2026. https://blog.shift4shop.com/build-free-shop ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸
Shift4Shop, pricing page, listing the unlimited plan at $41 per month and the note that "a monthly SaaS fee may be charged depending on your plan and monthly processing amount", checked November 2026. https://www.shift4shop.com/pricing.htm ↩ ↩²
Shift4Shop Knowledgebase, CSV export and import for products, including the sample file and the statement that there is no limit to the number of products you can import with CSV, checked November 2026. https://support.3dcart.com/Knowledgebase/Article/View/348/58/how-do-i-import-products-via-csv ↩ ↩² ↩³
Shift4Shop Knowledgebase, "Are there limits to the API calls", confirming that "to ensure the stability of our platform, we do have limitations in place for the amount of calls", checked November 2026. https://support.3dcart.com/Knowledgebase/Article/View/842/6/are-there-limits-to-the-api-calls ↩