Migrating away from Volusion to a custom Solidus store

What Volusion is, and who should stay on it

Volusion is a hosted ecommerce platform. You pay a monthly plan, Volusion runs the servers and the security of the platform, and you build your shop inside the admin it gives you. It is one of the longer established names in the category: it was founded in 1999, grew out of a small web design agency, and is run from Austin, Texas, where it describes itself as an all in one ecommerce solution for small and medium sized businesses.¹ For a shop that is early, simple or modestly sized, that is a fair description and a reasonable place to be.

I build custom shops on Solidus, the open source Rails ecommerce framework, so you know where I stand. That is exactly why I will start with the honest half. If your catalogue is small, your checkout is conventional, and the shop is a sales channel rather than the thing customers come to you for, Volusion runs it for a modest fee and leaving would cost more than it saves. This article is not for that shop. It is for the business that has outgrown the platform: the one that wants modern performance and better search rankings, that keeps hitting the edges of an admin and an API built in an earlier era of the web, and whose owner has started to wonder what it would take to own the shop outright. Where Volusion sits against the wider field is a separate question, and I set it out in the platform comparison for a UK shop.

This is a platform specific piece. The deep, platform independent questions, how customer records, products, orders and saved cards actually move, belong to the data type guides in this series, and I link each one where it matters rather than repeat it. Start with the overview, what moves and what does not, and come back.

What you own, and what the platform holds

The useful way to look at any hosted platform is to ask what you walk away with on the day you leave.

On Volusion you own your data, and you can get the core of it out as spreadsheets, which is to the platform's credit. What you do not own is the machinery around the data: the checkout, the theme, the hosting and the payment configuration. Those are rented, and they stay behind when you go. None of that is a scandal. It is simply what hosted means, and the point of this article is to help you price it honestly before you decide whether a move is worth it.

Pricing shows the shape of the pressure. Volusion's published plans run from Personal at 35 US dollars a month, through Professional at 79, to Business at 299 a month on annual billing or 399 month to month, with a Prime tier priced by sales volume. Each plan carries an annual sales cap, 50,000 dollars on Personal, 100,000 on Professional and 400,000 on Business, along with product and staff limits, and the page notes that additional fees may apply if you are not on a preferred payment gateway.² In practice, merchants who use Volusion Payments have those gateway maintenance fees waived, so choosing another gateway for a better rate or a market specific method carries a cost.³ Read all that plainly and the structure is familiar among hosted platforms: the better the shop does, the higher the tier it is pushed onto, and the sales caps are measured in US dollars, so for a shop that banks in pounds the ceiling moves with the exchange rate rather than with the accounts.

On Volusion	What it means when you leave
Products, customers, orders	Yours, exportable as CSV, the raw material of the move4
The checkout and payment setup	The platform's, configured not coded, stays behind5
The theme	The platform's template system, a front end rebuild
Saved cards	Held by the gateway, not by Volusion, so the question is where they sit5
URLs and rankings	Volusion's structure, so every address needs a redirect6

The export and the API, honestly

Here is where Volusion needs a careful, fair account, because the tools are real but they come from an earlier generation of the web, and you should plan around their shape rather than be surprised by it.

The spreadsheet route is the straightforward one. Under Inventory, the Import and Export tools let you run a Standard Export of a database table to a CSV file and a Standard Import of a CSV back into a table, which you edit in any spreadsheet application in between.⁴ Products, customers and orders all export this way, so the catalogue and the customer list become a mapping exercise rather than a rescue operation. The import side has the usual sharp edges worth knowing in advance: field types must match, so a product code longer than its thirty character limit fails the row, empty columns and stray commas from a spreadsheet cause errors, and the overwrite options include one that deletes a table's contents entirely, which Volusion itself advises against unless you mean to clear the table.⁴ For how each of these data types maps onto a new shop, which fields matter and where the traps are, I have written a guide per type: products and catalogue data, customer accounts and addresses, and order and purchase history.

Beyond the spreadsheets there is the Volusion API, and this is where the platform's age shows. It is available on the Business and Prime monthly plans, it moves data in XML rather than the JSON most current tools expect, and instead of an API key it authenticates with an administrator email address and an encrypted password string carried in the query string of a URL.⁷ Because of PCI guidelines that password is changed every ninety days, and each time it changes the URL that drives the integration has to be updated.⁷ There is a documented set of endpoints behind it, covering exports and the management of products, categories, options, customers and orders,⁸ so a scripted migration is genuinely possible. The constraint to plan around is the generic export: each run returns at most one hundred records, starting from the first row of the table, the download URL becomes invalid once it is used, and you reset and regenerate the export to fetch the next batch, with filters restricted to explicit values rather than ranges.⁹ For a shop with thousands of orders that is not a wall, but it does make a full history extraction a paced, scripted job of many small batches rather than a single afternoon, and it is one reason I rehearse the whole import on a copy of your data before anyone commits to a date.

One hard ceiling is the same on every platform and worth stating plainly: passwords do not come across. Customer passwords are stored as one way hashes, never in a form any export can carry, so every customer arrives at the new shop without one and is asked to set a password on their first visit. That is correct and expected, not a failing, and the customer accounts guide explains how I turn that reset into a planned relaunch message rather than a cutover day surprise.

The traps that are particular to Volusion

Every platform has a handful of places where leaving is harder, or the move matters more, than the clean CSV export suggests. On Volusion these are the ones to look at early.

The checkout and the payment setup are the platform's, not yours. The hosted checkout is configured, not coded. You can adjust it within the limits Volusion allows, but the flow belongs to the platform, which is fine until the business needs a step the platform does not offer: a delivery slot, a trade customer's negotiated pricing, an unusual tax or invoicing rule. On a shop you own, the checkout is your own application code, written and tested to do exactly what the business needs.

Saved cards live with the gateway, and Volusion's own gateway is a US product. A customer's stored card is held in tokenised form by the payment provider, not by the shop software. Volusion's current in house option, Volusion Payments Powered by Stripe, combines a merchant account and a PCI Level 1 gateway in one and is offered to United States merchants,⁵ which matters at migration time in two ways. If your cards are vaulted with an independent Stripe account, the new Solidus shop can connect to that same account and the saved cards simply stay where they are. If they sit inside a provider you are also leaving, moving them is the hardest part of any migration and may need the losing provider's cooperation. Either way this is the first question to settle, not the last, and the payment tokens and saved cards guide walks through how to confirm it.

The theme does not travel. A Volusion storefront is built in the platform's own template system. It is serviceable, but a Volusion theme is written for Volusion and does not port to another platform. The front end is a rebuild, which is a cost on the day and, if you have wanted a shop that looks like your brand rather than a template and loads faster than the old one did, an opportunity rather than a loss.

The URLs are the platform's, and they carry your rankings. Older Volusion stores in particular use URL structures from an earlier era, and those addresses carry years of links and search rankings. When you move, every one of them has to redirect to its new home, or the traffic drains away through a wall of 404 pages. Google's own guidance is to map every old URL to its new one, use permanent 301 redirects that point straight at the destination, and keep them in place for as long as possible.⁶ The redirect map is the least glamorous and most valuable deliverable of the whole project, and the products and catalogue guide covers how it is built.

The API is a reason to move carefully, not a reason to stay. The XML format, the password in the URL and the hundred record export cap are not so much criticisms as signs of a platform built in an earlier era. They make the extraction slower and more manual than on a newer system, which is an argument for scripting it properly and rehearsing it, and in the end an argument for moving to something you can query and extend without those limits.

The honest move to a shop you own

A migration off Volusion onto a custom Solidus store is not a button. It is a project, and done properly it is a calm one, because Solidus is an ordinary Ruby on Rails application and a PostgreSQL database that you own outright, under a permissive open source licence, on servers you control, which you can hand to any Rails developer tomorrow.¹⁰

The sequence is the one I follow for every platform. In discovery we decide what actually moves and who on your side owns the data. Then I build the new shop and write the import scripts against a copy of your real Volusion export, running them again and again until the result is clean, which is where the hundred record batches and the XML get tamed once rather than on the day. We run the two shops in parallel for a few weeks with the catalogue frozen, rehearse the final import at least twice, and cut over on a quiet weekday morning with the old shop left untouched for thirty days as the fallback. Each data type follows its own guide: products, customers, orders and payment tokens.

On order history there is a decision to make early rather than drift into: how far back to bring it. A few years of orders as read only history covers almost every customer service question and keeps the catalogue mapping sane, while the full export stays archived for your accountant. The new shop must never reuse an order number the old one issued, so the new sequence starts above the highest old number with a visible gap, and the order and purchase history guide sets out why and how.

One question decides whether the move is simple or hard, and it is about payments, so I settle it first: can your saved cards stay with their current gateway, reconnected to the new shop, or do they have to move. If they can stay, the rest is careful data work. If they cannot, we know the real cost before anyone signs, which is the whole point of asking first. For the money side over a five year horizon, build and hosting included, read the five year total cost of ownership, and for the deeper question of who holds your records and on what terms, who actually owns your business data. If you are weighing Volusion against the other hosted names, the near neighbour is migrating away from BigCommerce, another hosted US platform with the same rent or own question underneath.

A worked example

Let me make it concrete with an invented shop.

Harrow Lane Supplies (harrowlane.example) is a Leeds business selling cleaning and janitorial products, doing about 650,000 pounds a year online, much of it to offices and schools that buy on account. It has been on Volusion for nine years, on the Business plan, and it runs a conventional catalogue of around 4,000 products with a lot of case pack variants. The owner wrote to me after a frustrating year: the store felt slow on a phone, the search rankings had slipped behind newer rivals, and the one feature the business really wanted, account customers with their own price list and a monthly statement, was something the hosted checkout would not do.

The export was the methodical part. Products and customers came out as CSV and went into the mapping spreadsheets, while the order history came through the API in its hundred record batches, scripted over a couple of evenings around the reset and regenerate cycle so that nothing was missed.⁹⁴ The passwords stayed behind, as they always do, so the plan included a service message to every account holder before cutover and a short welcome page that set a new password on the first visit.

The payment question carried the risk, and we answered it first. Harrow Lane's cards were vaulted with an independent Stripe account, so the new Solidus shop connected to that same account and the saved cards never moved at all. Only once that was confirmed did we set a cutover week in the quietest month, build the redirect map from nine years of Volusion URLs, and rehearse the import twice. The account pricing and monthly statements that the old checkout could not do became ordinary Rails code in the new shop, tested like everything else. Harrow Lane now owns its shop, loads faster on a phone, and pays for hosting rather than a plan tier that climbs with its sales. That is an invented shop, not a client story, but every step in it is a step I would take.

When you should stay, and when to move

I will end where I began, because the honesty is the point.

Stay on Volusion if your catalogue is small, your checkout is conventional, and the plan you are on comfortably covers your sales. At that size the platform runs your shop, handles the hosting and the security, and leaving would cost more than it saves. Volusion is a long established platform and plenty of shops are right to stay on it.

Move when the platform's age has become your problem rather than its history: when performance and search rankings are holding the shop back, when the checkout or the pricing logic has hit a wall the platform cannot take down, and when you would rather spend the budget on a shop you own than on rent measured against a dollar sales cap. If that is where you are, the move is a known quantity, and the result is yours.

If you want a second opinion on your own numbers, bring them to a free workshop, and the first two weeks of work are on me. We will go through what would move cleanly, what the saved cards question answers for your shop, and whether a move off Volusion actually pays for you. Sometimes the honest answer is to stay, and if it is, I will say so. My rates are on the pricing page.

Footnotes

1. Volusion, About Volusion (founded in 1999, grown from a small web design agency, headquartered in Austin, Texas, an all in one ecommerce solution for small and medium sized businesses), accessed 14 November 2026, https://www.volusion.com/about ↩

2. Volusion, Pricing (Personal 35, Professional 79 and Business 299 US dollars a month on annual billing or 399 month to month, Prime by sales volume, annual sales caps of 50,000, 100,000 and 400,000 dollars, product and staff limits, and a note that additional fees may apply if you are not on a preferred payment gateway), accessed 14 November 2026, https://www.volusion.com/pricing ↩

3. Volusion, Credit Card Processing (gateway maintenance fees, with the fee waiver available exclusively to active Volusion Payments merchants), accessed 14 November 2026, https://volusion.com/credit-card-processing ↩

4. Volusion Help Center, How to Import a File Into a Table Within Your Database (Standard Export and Standard Import under Inventory, CSV files, field type limits such as a thirty character product code, and overwrite options including one that clears a table), accessed 14 November 2026, https://help.volusion.com/s/HowtoImportaFileIntoaTableWithinYourDatabase ↩ ↩² ↩³ ↩⁴

5. Volusion Help Center, Volusion Payments Powered by Stripe (a combined merchant account and PCI Level 1 certified gateway, available to United States merchants, with saved cards and wallet payments held by the gateway), accessed 14 November 2026, https://help.volusion.com/s/volusion-payments-powered-by-stripe ↩ ↩² ↩³

6. Google Search Central, Site moves with URL changes (map every old URL to its new one, use permanent 301 redirects straight to the destination, and keep them in place), accessed 14 November 2026, https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes ↩ ↩²

7. Volusion Help Center, The Volusion API (available on Business and Prime monthly plans, manages data in XML format, authenticates with an administrator email and an encrypted password string in the URL rather than an API key, and the password changes every ninety days under PCI guidelines so the URL must be updated), accessed 14 November 2026, https://help.volusion.com/s/thevolusionapi ↩ ↩²

8. Volusion Help Center, Developer Resources (the administrative API documentation, covering exports and the management of products, categories, options, customers and orders), accessed 14 November 2026, https://help.volusion.com/s/developerresources ↩

9. Volusion Help Center, Generic Exports With the Volusion API (generic XML exports of Orders, Products and Customers, at most one hundred records per export, the download URL invalid once used so the export must be reset and regenerated, and WHERE filters limited to explicit values), accessed 14 November 2026, https://help.volusion.com/s/genericexportswithvolusionapi ↩ ↩²

10. Solidus, solidusio/solidus repository and licence on GitHub (open source Ruby on Rails ecommerce under the BSD 3 clause licence), accessed 14 November 2026, https://github.com/solidusio/solidus ↩