Migrating away from the GoDaddy online store to a custom Solidus store
The GoDaddy online store is the commerce side of Websites + Marketing, GoDaddy's hosted website builder, and for a small shop bundled with a domain and an email it is an easy, sensible start. It becomes a cage for a business whose online side has become the main event and whose checkout cannot do the one thing the business needs. In this article I set out, specifically for GoDaddy, what the product CSV, the order download, the customer list and the Commerce API that opened up in August 2026 really hand over, where the builder ties you down, why the domain comes with you even though the store does not, and the honest shape of a move onto a custom Solidus store you own. The deep detail on how each data type moves lives in the data type guides, which I link rather than repeat. I am a solo growth engineer: I build the shop and run the move, and you own the result.
What the GoDaddy online store is, and who should stay on it
The GoDaddy online store is the commerce side of Websites + Marketing, GoDaddy's hosted website builder. You pick a template, you lay out pages in the browser, you add products, and GoDaddy runs the whole thing on its own servers on a Commerce plan.1 There is no code you own, no database you can reach, and no server you log into. For a great many small shops that is exactly right. The store usually arrives bundled with a GoDaddy domain and an email address, the setup is quick, and a founder with no technical help can be selling within a day. If that is your situation, and the shop is ticking along, leaving it would cost you money and buy you very little.
I build custom shops on Solidus, the open source Ruby on Rails ecommerce framework, so you know where I stand before I start. That is exactly why I will be fair about the builder. This article is not for the small shop that is happy inside it. It is for the business that has outgrown it: the one whose online side has become the main event, whose checkout cannot do the one thing the business actually needs, and whose owner has started to resent paying rent for a store they can never fully open the bonnet on. If that is you, read on.
This is a platform specific piece. The deep, platform independent questions, how customer records, products and orders 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. Where GoDaddy sits against the wider field, I set out in the platform comparison for a UK shop.
The useful distinction: the domain is yours, the store is not
Before anything else, separate two things that GoDaddy sells you in one bundle, because they behave very differently when you leave.
The domain is portable. A domain you registered through GoDaddy is yours to move. You unlock it, switch off the privacy service, ask GoDaddy for the authorisation code, and start the transfer at your new registrar, subject to the usual sixty day lock after a registration or a contact change.2 Your web address, the thing printed on your van and known to Google, comes with you. That matters more than it first appears, because it means a move off GoDaddy does not have to mean a new address or a loss of the authority your domain has built up.
The store is not portable. The builder, the template, the hosted checkout, the page structure and the hosting itself are GoDaddy's, and they stay behind. What you can take is your data, in the shapes GoDaddy gives you, and that is the honest subject of the next two sections.
What you own, and what GoDaddy holds
The useful way to look at any hosted platform is to ask what you walk away with on the day you leave.
On the GoDaddy online store you own your business data and you can get most of it out, which is to GoDaddy's credit. Your product list exports to a spreadsheet, your orders download as a file, and your customer list can be exported from the payments side of the business. What you do not own is the machinery: the builder and its template, the hosted checkout, the payment processing and the hosting. Those are GoDaddy's, and they stay behind. None of that is a scandal. It is simply what a hosted builder means, and the point here is to help you price it honestly before you decide.
| On the GoDaddy online store | What happens when you leave |
|---|---|
| Products (physical) | Export to a CSV file from the store dashboard, so the catalogue moves as a mapping job34 |
| Orders | Download as a CSV, filtered by date, the whole list rather than a chosen few5 |
| Customer records | Export the customer list from the GoDaddy Payments dashboard, passwords never come with them6 |
| Saved cards | Held by GoDaddy Payments as cards on file, moving them needs the gateway's cooperation6 |
| The Commerce API (since August 2026) | A real route out for stores on GoDaddy Payments, catalogue, orders, customers and taxes78 |
| Checkout, template, hosting, page structure | GoDaddy's own, and they stay behind |
| The domain | Yours, transferable to another registrar2 |
The export and the API, honestly
For years the honest summary of a GoDaddy online store was that you got your products out as a spreadsheet and not much else cleanly. That picture has improved in 2026, and I want to be precise about both the old flat files and the newer programmatic route, because which one you use changes the shape of the move.
The flat files first. Your products export to a CSV from the store dashboard, under the products screen, and the most recent export is there to download as a file.3 The same template imports back into another store, which is what makes a catalogue a mapping exercise rather than a rescue. Two limits are worth knowing before you plan. The import side handles physical products only, so digital products and downloads have to be recreated by hand, and it works in batches, up to one hundred products at a time on a Websites + Marketing Commerce plan, matched on SKU so that an existing code is overwritten rather than duplicated.4 Orders come out too, as a CSV you filter by date range and download as the whole matching list, not a hand picked set.5 Customer records are the awkward one on the builder itself: the cleanest customer export sits on the payments side, where you can export your full customer list from the GoDaddy Payments dashboard.6
Now the part that is genuinely new. On 27 August 2026 GoDaddy launched a Commerce API that lets a developer manage a commerce store programmatically, including its configuration, catalogue, orders, customers, taxes and payment records.7 Everything hangs off one store: the catalogue models products as SKUs and SKU groups, orders reference customers and catalogue items, and transactions are the payment records tied to orders.8 There is a condition attached, and it is the important one for a mover. The store identifier that every call needs, the storeId, is generated when you create a GoDaddy Payments account, and access uses a personal access token carrying scopes in the pattern commerce.{resource}:{action}.8 In plain terms, the API is tied to GoDaddy Payments. A shop that takes its money through GoDaddy Payments now has a proper, scripted way to pull its catalogue, orders and customers in full detail. A shop that does not is back to the flat files. Either way the result is the same shop in the end, but the first route is a cleaner, better checked migration, and it is the first thing I establish about any GoDaddy store.
One hard ceiling sits on top of all of this, the same on every platform and worth stating plainly: passwords do not come across. The exports and the API hand over a customer's contact details and history, never a usable password, because the password is stored as a one way hash and is designed to be impossible to export. A customer brought into the new shop is simply asked to set a password on their first visit, and the customer accounts and addresses guide explains how I turn that reset into a planned relaunch message rather than a cutover day surprise.
The traps that are particular to GoDaddy
Every platform has a handful of places where leaving is harder than the clean export suggests. On the GoDaddy online store these are the ones to look at first.
The builder has a customisation and SEO ceiling, and the URLs are GoDaddy's. Websites + Marketing is a visual builder, which is its strength for a small shop and its ceiling for a growing one. The design, the page structure and the finer points of how the site is marked up for search are only as flexible as the builder allows, and the web addresses of your products and categories follow GoDaddy's own scheme rather than one you chose. When you move, every one of those addresses has to redirect to its new home, or the traffic and rankings behind those pages drain away through a wall of 404 errors. Google's own guidance is to map every old address to its new one, use permanent 301 redirects straight to the destination, and keep them in place for as long as possible.9 Because the domain itself moves with you, those redirects can live on the same web address on the new shop, which is the quiet advantage of keeping the domain. That redirect map is the least glamorous and most valuable deliverable of the whole project, and the products and catalogue data guide covers how it is built.
The checkout and the payment processing are GoDaddy's, not yours. On the GoDaddy online store the hosted checkout and, for most shops, GoDaddy Payments as the processor are part of the bundle. That is effortless while you are inside it and a wall the day you want something GoDaddy does not offer: a delivery slot step, a trade customer's negotiated pricing, an invoicing rule your accountant insists on, a second payment provider for a particular market. On a shop you own, the checkout is your own application code and the payment provider is your choice.
Saved cards are cards on file held by GoDaddy Payments. This is the single most important thing to settle before you move. When a customer saves a card on a GoDaddy store, that card is stored by GoDaddy Payments against the customer file, shown by its last four digits and expiry, and reused on later orders.6 You never hold the card number, which is exactly as it should be, but it means the saved cards do not simply fall out in an export. Moving them to a new processor is the hardest single part of the move and needs the gateway's cooperation. I treat it as the first question, not the last, and the payment tokens and saved cards guide walks through how to confirm what is possible for your shop, as does the wider warning in the hidden dangers of switching payment gateways.
The best route out is tied to the payment account. It is worth saying twice, because it is a GoDaddy specific knot. The Commerce API that makes a clean, scripted migration possible is reached through a GoDaddy Payments account and its storeId.8 So the same company that holds your saved cards also holds the key to the tidiest way of extracting your catalogue, orders and customers. For most movers that is fine, because they are on GoDaddy Payments anyway and can use the API before they switch the money off. It does mean the order of operations matters: pull the data while the payment account is still live, then deal with the cards, then move the processing. Do it in the wrong order and you make your own exit harder.
The honest move to a shop you own
A migration off the GoDaddy online store 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, on servers you control, under a permissive open source licence, which you can hand to any Rails developer tomorrow.10
The sequence is the one I follow for every platform. In discovery I settle what actually moves, who on your side owns the data, and, for GoDaddy, which route the export takes and what happens to the saved cards. I build the new shop and write the import scripts against a copy of your real GoDaddy export, running them again and again until the result is clean. The two shops run in parallel for a few weeks with the catalogue frozen, the final import is rehearsed at least twice, and the cutover happens on a quiet weekday morning with the old shop left untouched for thirty days as a fallback. Each data type follows its own guide: products, customers and orders.
For a GoDaddy store, three questions carry most of the risk, and I answer them before fixing a date. Is the shop on GoDaddy Payments, so the Commerce API is available, or will the migration run from the flat files? Can the saved cards move to the new processor, or do you keep the GoDaddy connection alive for a while and let customers re enter a card as they return? And in which order do we lift the data, handle the cards and switch the processing, so that nothing is stranded behind a payment account that has already been closed? If the answers are clean, the rest is careful data work. If they are not, we know the real cost before anyone signs, which is the entire point of asking first. For the money side of the decision over five years, 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 still weighing the lightweight builders against each other before deciding to own, the Square Online version of this guide and the Wix version cover the near neighbours.
A worked example
Let me make it concrete with an invented shop.
Harbour Lane Candles (harbourlane.example) is a Brighton maker of poured candles and reed diffusers. The shop started on the GoDaddy online store three years ago, bundled with the harbourlane.example domain and a matching email, and for a long time it did the job: a tidy storefront, a few dozen products, cards taken through GoDaddy Payments. Then two things happened. A wholesale side grew, with trade customers who wanted their own price list and to pay on invoice rather than by card at the till, and the retail side outgrew the template, because the owner wanted a build your own gift set where a customer picks three candles from a seasonal range. Neither was something the builder could express, and the owner had started to dislike that the website, the checkout and every card payment were one company she could not change piece by piece.
The export was the calm part, because the shop was on GoDaddy Payments. The products came out as a CSV from the store dashboard, and because the catalogue was all physical candles and diffusers the shape was clean.34 Rather than rely on the flat order and customer files alone, the migration used the Commerce API against the shop's own storeId to pull the full order history and customer list in detail, catalogue, orders and customers together, which is the route that opened up in August 2026.78 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 first visit.
The saved cards carried the risk, and we answered that before fixing a date. The cards on file belonged to GoDaddy Payments, so the plan kept the GoDaddy payment account open through the migration, lifted the data while it was still live, and only then moved the processing to the shop's own chosen provider on the new Solidus store.6 Where a returning customer's card could not move, the new shop asked them to re enter it once, on a checkout that was now the shop's own code. The domain, harbourlane.example, transferred to a new registrar and pointed at the new shop, so the web address and its hard won rankings came across intact, with every old product and category address redirected to its new home.29
The trade price list and the build your own gift set that the builder could not express became ordinary Rails code in the new shop, tested like everything else. Harbour Lane now owns its website, chooses its own payment provider, keeps its domain, and runs its wholesale pricing on logic the business can see and change. 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 the GoDaddy online store if the shop is small, if the bundle of domain, email, hosting and a simple store in one place is a benefit rather than a cage, and if the hosted checkout does what your business needs. At that size GoDaddy runs the whole thing for a modest monthly fee, and leaving would cost more than it saves. It is a sensible builder for a sensible set of needs, and plenty of shops are right to stay inside it.
Move when the online side has become the business, when the checkout or the pricing logic has hit a wall the builder cannot take down, and when you would rather own the shop, choose your own payment provider and keep your data in a database you control than rent all of it from one company. If that is where you are, the move is a known quantity once the payment questions are answered, the domain comes with you, 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 moves cleanly, whether the Commerce API or the flat files is your route out, what the cards on file really allow, and whether a move off GoDaddy 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
-
GoDaddy Help, Statement of support for Websites + Marketing Online Store (the hosted online store on a Websites + Marketing Commerce plan), accessed 14 November 2026, https://www.godaddy.com/help/statement-of-support-for-websites-marketing-online-store-40100 ↩
-
GoDaddy Help, Transfer my domain away from GoDaddy (unlock the domain, remove privacy, use the authorisation code, subject to the 60 day lock after registration or a contact change), accessed 14 November 2026, https://www.godaddy.com/help/transfer-my-domain-away-from-godaddy-3560 ↩ ↩2 ↩3
-
GoDaddy Help, Export my online store products into a .csv file (export from the store dashboard, download the most recent export as a CSV file), accessed 14 November 2026, https://www.godaddy.com/help/export-my-online-store-products-into-a-csv-file-40373 ↩ ↩2 ↩3
-
GoDaddy Help, Import products from a .csv file (physical products only, up to 100 per batch on Websites + Marketing Commerce, matched on SKU with overwrite of existing codes), accessed 14 November 2026, https://www.godaddy.com/help/import-products-from-a-csv-file-16581 ↩ ↩2 ↩3
-
GoDaddy Help, Download orders from my online store (orders download as a CSV, filtered by date range, the whole matching list rather than selected orders), accessed 14 November 2026, https://www.godaddy.com/help/download-orders-from-my-online-store-40577 ↩ ↩2
-
GoDaddy Developer, Commerce core concepts (a GoDaddy store's customers and payment records live with the store, whose storeId is created together with a GoDaddy Payments account, so saved card data sits with GoDaddy Payments), accessed 14 November 2026, https://developer.godaddy.com/docs/api-users/commerce/concepts ↩ ↩2 ↩3 ↩4 ↩5
-
GoDaddy Developer, Changelog: the Commerce API is now available for managing stores, catalogues, orders and taxes, 27 August 2026 (manage a commerce store programmatically, including its configuration, catalogue, orders, customers, taxes and payment records), accessed 14 November 2026, https://developer.godaddy.com/en/docs/api-users/changelog/commerce-apis-launch ↩ ↩2 ↩3
-
GoDaddy Developer, Commerce core concepts (one store holds the catalogue, orders, taxes, customers and channels, the storeId is generated when you create a GoDaddy Payments account, scopes follow commerce.{resource}:{action}), accessed 14 November 2026, https://developer.godaddy.com/docs/api-users/commerce/concepts ↩ ↩2 ↩3 ↩4 ↩5
-
Google Search Central, Site moves with URL changes (map every old URL to its new one, use permanent 301 redirects straight to the destination, keep them in place), accessed 14 November 2026, https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes ↩ ↩2
-
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 ↩