Start a store migration with an inventory of what the business depends on. Products and images are only part of it. You also need a plan for open orders, customer records, working links, payment settings, shipping rules, and changes made while the new store is being prepared.
Work in this order: inventory what must survive, rehearse the difficult cases, move the catalog, reconcile the last changes, and test the live buying journey after switching the domain. Choose a launch date once you know how those steps will work.
Download the migration worksheet. It includes an inventory, URL map, rehearsal checks, and cutover record. Fill in the owner, expected result, evidence, and status for each row. An unanswered row is a task to resolve before scheduling the move.
1. Decide what has to arrive in the new store
Give every item one destination: transfer, rebuild, reconnect, archive, or retire. This stops “move the store” from hiding five different kinds of work.
| Store asset | What to record | Acceptance check |
|---|---|---|
| Catalog | Product IDs, SKUs, prices, options, stock, weights, and categories | A representative product has the right buying choices and stock behavior |
| Images and files | Original files, product associations, captions, and usage rights | The correct image appears on the correct product at a useful size |
| Orders | Open orders, fulfillment state, refunds, and historical records | Someone can finish every open order and retrieve the history they need |
| Customer records | Contact details, account dependencies, and recorded preferences | Required fields have a supported destination; account behavior is tested separately |
| URLs and content | Product, category, editorial, campaign, and service pages | Important old links have an intentional destination |
| Commerce settings | Payment methods, shipping rules, tax configuration, discounts, and notifications | Expected totals and order messages match a written test case |
| Connections | Domain, email, analytics, ads, fulfillment, and other services | Each connection has an owner and a post-switch check |
Keep a dated export and the original media files somewhere you control. A download link in an export is not the same as a copy of the image. Open a sample of the files before treating the backup as usable.
Separate historical access from active operations. You might preserve old orders in a searchable archive while new orders begin in the new platform. That is a workable decision only if the people handling support, fulfillment, and refunds know which system to use.
Ask the destination about leaving, too. Which records can you export, in which format, on which plan, and with what access after cancellation? Open a sample export and check whether you can retrieve the original media and history the business needs. A platform should keep earning your business through its usefulness; make the next exit a demonstrated process while you can still choose.
2. Prove what the destination can import
An export proves that data can leave one system. It does not prove that the next system can interpret it.
For example, Ecwid’s migration guidance, checked on 28 September 2026, describes separate product transfer, customer transfer, settings, and website setup. Its CSV guidance explains that external files may need changes to match its import format. Treat that as a useful warning against assuming that two CSV buttons form a complete migration path.
Choose a small test set with the cases that matter to your store: a normal product, an item with several images, a sold-out item, and any product with options or unusual delivery requirements. If you sell digital files, subscriptions, gift cards, or personalized goods, include the relevant case before approving the destination. Setka doesn’t sell subscriptions or digital products yet.
Write down how each source field maps to the destination. Then check the result from both sides: the record in the admin and the product a customer sees. An import that finishes without an error can still have misplaced categories, missing images, or the wrong stock quantity.
For a 40-product store, a useful rehearsal might include a simple product, a product with several options, a heavy item with different shipping, a sold-out item, and one with several images. Pick the cases that could break your store, fix the mapping, then move the rest.
3. Give old URLs an explicit destination
Make a list of current URLs before rebuilding navigation. Include pages reached from search, email, social profiles, packaging QR codes, and ads. For each, record whether the address will stay the same, move to an equivalent page, or be retired.
| Old address | Intended destination | Decision to confirm |
|---|---|---|
/products/blue-bowl | The same bowl in the new catalog | Can the destination preserve the address or implement the required redirect? |
/collections/tableware | The new tableware collection | Does the collection still contain the expected products? |
/journal/caring-for-stoneware | The care guide | Who is moving the article, images, and links? |
| An expired campaign page | A relevant replacement, if one exists | Does the replacement fulfill the original link’s promise? |
Confirm how the destination handles redirects, and test old links after the switch. Do not assign every old address to the homepage just to finish the spreadsheet.
Preserve the reason someone follows each important link. A care article should still answer the care question; a campaign for a particular gift should reach the promised product and relevant gifting details. Carry over the useful explanations, accurate specifications, truthful images, and delivery and returns information that let someone decide. Check the route on desktop and mobile, including the path from the page to checkout.
Also confirm that customers can recognize and contact the business after the move. Review the store name, contact details, policy links, and order-message identity together. A changed design can be intentional; contradictory product information or an unreachable support address is a defect to resolve before accepting the launch.
Use the store SEO checklist for the new site’s crawl and indexing checks. A clean URL map is part of a migration plan; it is not a promise that rankings or traffic will remain unchanged.
4. Rebuild the operating rules and check the totals
Treat payments, shipping, tax settings, and promotions as configuration work with test cases. Record your existing rules before trying to reproduce them. Carry your approved tax requirements into the new setup.
For each test basket, write the expected product total, discount, delivery charge, and applicable tax result. Include a supported destination, an unsupported destination, and a basket near any free-shipping threshold. Assign someone to investigate differences rather than accepting whichever total the new checkout produces.
Also check who receives order notifications and how fulfillment begins. The migration is incomplete if the buyer receives a confirmation but the person packing the order cannot find it.
If you are evaluating Setka, its payment workflow uses your own Stripe account, connected in Settings → Payments, and one store currency. You configure accepted payment methods in Stripe. After publication, a successful payment creates a paid Setka order, updates inventory, and sends notifications. The payment guide explains that workflow.
5. Plan the last changes before the switch
The old store can keep changing while you prepare the new one. Orders arrive, stock falls, products are edited, and customers update details. A catalog export from last week cannot account for those changes by itself.
Set a final reconciliation time and choose an owner. Decide whether you will briefly pause changes, import a final update, or reconcile a small number of records manually. The method depends on the systems and sales activity; agree it before the switch.
Suppose your export records eight blue bowls, then two sell in the old store before the switch. Importing the original file leaves the new store offering eight bowls when only six remain. Your final check needs to catch that difference, as well as new products, price edits, refunds, and canceled orders that affect stock.
Record which system owns each open order. Avoid a situation where an order appears in both stores and two people fulfill it, or where neither team considers it theirs. Keep the old admin accessible for the operational work you still need to complete there.
6. Separate domain switching from accepting the launch
Before changing the domain, record the existing settings and the exact new instructions. Include business email in the check so a website move does not accidentally disrupt another service using the same domain.
Setka lets you add an owned hostname, follow its store-specific DNS instructions, confirm the connected state, choose the primary hostname, and publish the approved storefront. Use the custom-domain guide for that sequence. If you have an existing store, Setka migrates your data for you. Self-service bulk import and redirects from old URLs aren’t available yet; when they arrive, you’ll be able to hand them to your own agent through Setka’s storefront MCP. If your move depends on redirects at launch, tell us at [email protected]: requests go straight to the people building Setka.
After the switch, place a real order, then refund it from the Setka order before you send customers to the store. Check the paid order, inventory, customer confirmation, merchant notification, and fulfillment handoff. Use the launch checklist to record results.
For a worksheet row such as “live order,” replace “checkout works” with a result someone can verify: “Payment succeeded; the order appears as paid; stock fell by one; buyer and merchant received the expected messages.” Add the order reference and the person who checked it. That gives you evidence to accept the launch.
Hold promotion if the checkout charges the wrong total, a paid order cannot be fulfilled, or a key buying link is broken. Cosmetic fixes can have owners and deadlines; a broken buying journey needs fixing before you send customers to it.
Name a person who can pause promotion or reverse the cutover if a critical check fails. Returning the website to its previous destination does not undo orders already placed in either system. Your fallback plan must account for those orders and their stock effects.
7. Close the migration only when the remaining work has an owner
Review missing images, broken old links, failed transactions, and support questions after the switch. Compare the intended inventory with what arrived. Keep a list of exceptions with an owner and deadline, including any historical records that remain in the old system.
Do not cancel the old platform merely because the new homepage loads. First confirm that backups can be opened, open orders and refunds have a workable process, and every service you depend on has moved or has an agreed replacement. Keep the export instructions, access requirements, and named owners with the new store’s operating notes so the next move starts with a usable record.
If you are moving because the storefront is hard to change
Setka is our product. It builds the storefront from your brief and catalog, then lets you describe changes, edit wording, preview, and publish. If keeping the design up to date is why you’re moving, Setka removes that work: you describe the change instead of commissioning it.
Setka runs the migration for you: send your completed inventory to [email protected], whether it holds orders, customers, blog posts, or anything else, and we’ll go through each row with you. Then start a Setka store to work on the new presentation while the old store continues serving customers. A storefront you like and a transfer plan you can execute are both needed before the domain moves.