The decision is made and the engineering team is ready. The first thing that breaks in these projects is the product URL that used to bring in an order a day and now returns a 404, and the review history you discover, after the cutover, never leaves the platform at all. Migrating an online store to a custom system is a URL and data project before it is a programming project, and those two items decide how much ranking and customer trust you lose in the first few weeks.

This guide assumes you have already settled the question of off-the-shelf versus custom and reviewed how a custom store compares with rented platforms. What follows is the execution plan itself: the URL map, an honest inventory of what exports and what does not, then the cutover and the rollback.

Start With the URL Map, Before a Line of Code Is Written

What you are doing is not a redesign. Google's site-move guide files any change to URL paths inside a single domain under site moves, so a product page going from shop.com/item?id=1023 to shop.com/products/blue-shirt is a full move as far as the index is concerned, even if the domain name stays put and no customer notices.

The order the documentation sets out runs in four steps that do not swap places: stand the new system up and put it through a full test, build a table pairing every current URL with its new form, configure the server to redirect, then watch traffic on both sides. Mapping comes before redirecting, and redirecting comes before monitoring.

Where the List of Old URLs Comes From

Do not build the map from memory or from your current product list alone. Google suggests four sources that complement each other: the sitemaps you previously submitted, server logs or analytics for the URLs that receive the most traffic, the links report in Search Console, and your CMS list of every page that holds content. Collect all four, then de-duplicate.

One item is forgotten almost every time: embedded content. Google asks you to include the URLs of videos, images, JavaScript and CSS files in the move plan. On a rented platform, product images live on the platform's own domain, which means every one of them changes.

Page typeTypical URL on a rented platformWhat has to happen
Product page/products/product-nameA 301 to the new product URL, one destination per product, not two
Category page/collections/category-nameA 301 to the matching category in the new system
Filter or sort URL/collections/…?sort_by=Decide in advance: consolidate into the category URL, or leave it unindexed
Blog post/blogs/news/post-nameA 301 to the new blog path
Policy page/pages/shipping-policyA 301; these are among the most bookmarked pages you have
Images and attachmentsThe platform's storage domainUpload them to your own storage before the cutover instead of relying on platform URLs
Permanently discontinued productNo equivalent in the new systemA 404 or 410, not a redirect to the homepage

Redirect Rules Worth Writing Into the Specification

Treat these as acceptance criteria for delivery, not as general advice:

  • Use a server-side permanent redirect. The documentation points to status codes 301 and 308 wherever they are technically available, because a permanent redirect is the signal indexing uses to treat the new URL as canonical.
  • Do not build redirect chains. Googlebot will follow as many as ten hops, yet the advice is to redirect straight to the final destination. Where that cannot be done, the ceiling given is three hops as the preferred limit and five as a number never to reach.
  • What is gone should say it is gone. Content that will not move should return a 404 or 410. Redirecting every discontinued product to the homepage creates pages that have nothing to do with what the visitor searched for.
  • Every new URL carries a self-referential canonical, and if your store has an Arabic and an English version, update the hreflang annotations to point at the new URLs.
  • Keep redirects for a long time. The documentation asks you to hold them as long as you can and «at least 1 year», because that window is what lets every signal reach the new URLs. From the visitor's side, the suggestion is to keep them with no end date at all.

Two points make the budget conversation easier. First, permanent redirects do not cost you link equity; the documentation devotes a passage to reassuring site owners and states that permanent redirects «don't cause a loss in PageRank». Second, the Change of Address tool in Search Console applies only when the domain or subdomain itself changes. Swapping paths inside one domain does not call for it, which is the situation of almost every merchant who leaves a rented platform and keeps their domain.

What to Do the Day After

Verify both the old and the new property in Search Console, in every variant, and submit the new sitemap. Watch crawl errors and the indexing report: indexed old URLs falling while new ones rise is exactly what the move should look like.

Give the server room, too. After the move Google crawls the new site at a temporarily higher rate, because it is crawling old and new URLs at once. And when someone asks how long this takes, the documentation puts it at a few weeks for most pages on a small to medium site, and longer on larger ones. Anyone promising a week is not describing your situation.

What Actually Comes Out of the Platform

This is where most surprises live. You are not migrating "the store". You are migrating what the platform lets you export in an importable format, plus whatever you can pull through its APIs. The gap between the two is wide.

ItemWhat the platform documentation saysWhat it means for you
Products and variantsStandard CSV or Excel export; Salla lets you build custom export templates for products and orders, up to five of eachThe easy part, but check variants and SKUs before importing
Product imagesShopify states that a product's images are not part of the CSV fileImages move as a separate job, and keeping the old store open during the import is a practical requirement
Product SEO title and descriptionExported blank unless you edited them manuallyFields that look populated in the storefront are generated on the fly, and you will be writing them again
CustomersCSV export; on Shopify the Total Spent and Total Orders columns are not importedCore data moves; lifetime figures get recalculated from the orders once those are in
PasswordsNot migratable through a CSV because they are hashedEvery registered customer will need a reset. More on that below
Historical ordersNot importable through a customer CSV; they need a migration app or the orders APIA separate engineering item in the scope, not a line in a spreadsheet
ReviewsNo documented export page in the Salla, Zid or Shopify help centres we reviewed; Salla's reviews screen offers publishing, deleting, replying and filtering onlyThe item most likely to be lost. Pull it through an API or copy it manually before you cancel
Discount codesShopify: export to CSV is available, importing discount codes back is notCodes come out; usage rules and per-customer usage counts need a manual review

Zid's own guide for moving a store from Salla shows the scale of it. Step two is to export two files and no more, one for products and one for customers. Orders, reviews, discount codes and loyalty balances sit outside the ready-made path, and become your responsibility or your developer's.

There is also an order you cannot reverse: import products first, then customers, then historical orders, so that orders attach to the right products and the right buyers. Reverse it and you get orphaned orders with no owner and no line items.

Planning to build or scale a digital project?

Snaabble provides a tailored technical assessment to define the right stack & exact budget.

Chat on WhatsAppExplore Services

One small detail saves a chaotic day. Importing historical orders can fire a "new order" notification for every single imported order. Turn order notifications off before the import starts, or your team wakes up to thousands of emails.

Accounts and Passwords: The Item That Upsets Customers

Your customers' passwords are stored hashed in a way that cannot be reversed, which is why they do not travel. Shopify's documentation traces it to the cause: the hashing happens outside the platform, so there is no way to carry passwords across in a CSV. The usual remedy is to invite customers to create a new one at first sign-in.

Names, emails, phone numbers, addresses and tags move. The key to the door does not. Plan it as a user experience rather than as an email:

  • Offer a sign-in path that does not depend on a password at all, such as a one-time code sent by SMS. In Egypt and Saudi Arabia a large share of buyers remember their phone number better than the email they registered with.
  • Match the returning customer to their old record by email or phone, so their addresses and order history are waiting at the first login.
  • Send the reset message after the cutover, never before. A reset link that lands while the new store is still closed costs you trust once and for good.
  • Write it plainly: the store has been upgraded, the account and its orders are intact, and a new password is needed once.

Payments and Shipping: Accounts That Do Not Travel With the Code

Your payment gateway account belongs to you as a merchant, not to the old storefront, but the integration is rebuilt from scratch. API keys and integration IDs belong to the system that calls them, and the return and notification URLs are configured inside those IDs. In Paymob's documentation, once a customer finishes paying they are returned to whichever URL you named as the response callback inside the integration ID, and the endpoint that receives server-side notifications has to sit on a publicly reachable address.

In practice: new keys, new endpoints on the new domain, real low-value test payments before the cutover, and a re-check of every callback URL after the domain points at the new servers. If you are still choosing a provider, start from our guide to payment gateways in Egypt, and do not assume that approval and verification finish the same day.

Shipping follows the same logic. Your carrier account stays, but the automated integration, waybill numbering, zones and rates are rebuilt in the new system, and shipments still in transit at cutover need a manual watch until they close. The details are in shipping solutions for online stores.

E-Invoicing: The Integration Is Rebuilt From the New System

If your store issues invoices tied to a tax authority, that link does not copy across. In Saudi Arabia each invoice-generating unit is onboarded through the Fatoora portal and receives its own certificate, so the new system has to be registered before it issues a single invoice. In Egypt, the system registers with the e-invoicing platform and receives its own credentials, and the documentation requires the system to expose an endpoint the authority can reach during registration.

The practical consequence is the same in both markets: put the tax integration on the timeline as an independent item with an approval period you do not control. The details are in phase two of e-invoicing in Saudi Arabia and connecting your system to Egyptian e-invoicing.

The Cutover Plan: From Parallel Running to the Domain Switch

A good migration is deliberately boring. The new system runs on a temporary subdomain that is blocked from indexing, data is imported and reviewed there, and the team walks a full cycle: order, payment, fulfilment, return, invoice. Comfortable as parallel running is, Google's advice on the URLs themselves runs against intuition: for small and medium sites the recommendation is to move every URL at one time rather than in batches, with section-by-section moves reserved for large sites. Pick a low-traffic window, not the eve of a seasonal campaign.

The day before the switch:

  1. Lower the TTL on your DNS records. That value controls how long resolvers cache the record, and Cloudflare's documentation explains that a longer TTL delays the moment an edit reaches your visitors. A low value means a faster switch, and a faster reversal if you need one.
  2. Disconnect the domain from the old platform before pointing it at the new servers. Shopify's warning is direct: a domain still attached to the platform you are leaving should be released first, otherwise the transfer runs into certificate errors. The certificate on the new store has to be issued and active before the first visitor arrives, not after.
  3. Freeze changes on the old store inside a known window, and sync the orders placed in the final hours before the new one opens.
  4. Remove any noindex rule or robots.txt block you used during development. Google puts leftover blocks at the top of the common errors that keep a new site from being indexed.

A rollback plan is not a luxury. Decide beforehand what counts as failure, such as checkout failing or 404s crossing an agreed threshold, and who owns the decision to roll back. Then answer the question everyone forgets: how do the orders placed on the new system before the rollback get merged back? Without that answer, going back is worse than going forward.

Checklist: Before and After the Cutover

Before

  • A complete URL map, one destination per old URL, no chains.
  • Full backups of everything exported and of the new database (backup strategy).
  • Images uploaded to your own storage, with the old store still open.
  • An active SSL certificate on the domain and a lowered TTL.
  • An end-to-end test payment, and an invoice successfully issued from the test environment.
  • Order notifications disabled while historical orders are imported.
  • Both properties verified in Search Console.

Immediately after

  • Spot-check one URL of each type: product, category, post, policy page, image.
  • Remove noindex and robots.txt blocks, and submit the new sitemap.
  • Place a real test order that passes through payment, invoicing and shipping on the live account.
  • Watch 404s and server logs daily through the first week.
  • Update internal links, your social profile links and your ad campaigns. A redirect is a safety net, not a permanent substitute.
  • Compare page speed with the old store (Core Web Vitals) and review the new hosting setup.

A good migration goes unnoticed. The customer finds the same link working, signs in after a single reset, and receives the order on time, while the index moves gradually towards the new URLs over a few weeks.

If you are planning to move your store to a custom system, send your current store URL and your product and category counts to the Snaabble team, and within 24 hours you will have an outline migration plan with an estimate of the time and the cost, at no charge and with nothing to commit to.

Sources