Switching eSIM reseller platforms
What actually moves with you, what quietly does not, and the redirect step that decides whether you keep the search traffic you spent two years earning.
هذه المقالة منشورة بالإنجليزية. الموقع العربي مترجم بالكامل، أما المدونة فلا — لأن ادعاءً واحداً مترجماً ترجمة سيئة عن تسعير منافس أسوأ من عدم وجوده.
Take an inventory before you decide anything
Moving an eSIM store is mostly not a technical problem. It is an ownership audit: some of what you think of as your business is genuinely yours and travels with you, and some of it is registered in somebody else’s name and does not.
Do this inventory before you evaluate a single alternative platform, because the answers change what you should be shopping for.
| Asset | Moves with you if… | Check this |
|---|---|---|
| Domain name | It is registered to you | Who is the registrant on the WHOIS record |
| Customer list | You can export it | Try the export during evaluation, not during the move |
| Payment account | The merchant account is yours | Whose name is on the statement descriptor |
| Provider account | You opened it | If the platform buys the eSIMs, there is nothing to move |
| Order history | You can export it | You may need it for tax long after you have left |
| Search rankings | The URLs survive or redirect | The section below — this is the one people lose |
| Reviews and social proof | They are on platforms you control | On-site testimonials rarely survive; third-party reviews do |
If the domain is registered in the platform’s name, resolve that first and separately. Everything else in a migration is negotiable; a domain you do not control is a business you do not control.
The three that actually trap people
Most of the inventory above is fine for most resellers. Three items are where migrations genuinely stall.
The payment account is theirs
If customer money has been landing in the platform’s account and being forwarded to you, then you have never had a merchant account, you have no processing history in your own name, and you will be applying as a brand-new merchant. That application takes weeks and can be declined. Start it before you do anything else.
There is no provider account to move
On a platform that sells you the eSIMs, your supply relationship is with the platform. Moving to a bring-your-own-keys arrangement means opening a provider account from scratch, agreeing terms with no volume history to negotiate on, and accepting that your first rates will be worse than your eventual ones. That is a real cost and it is worth being clear-eyed about it.
The catalogue does not map one-to-one
Your new supplier’s packages will not exactly match your old ones — different data sizes, different durations, different country groupings. Every price you publish has to be reset, and any customer expecting the exact package they bought last year may not find it. Budget an afternoon for this and do it before cutover, not after.
The order that avoids downtime
The mistake is treating this as a switch to flip on a date. Run both in parallel and make the cutover boring.
- Apply for the payment account and, if you are bringing your own supply, the provider account. Everything else waits on these, so start them on day one.
- Export everything from the old platform while you still have access: customers, orders, invoices. Do this early — export tools have a habit of being unavailable to accounts that have given notice.
- Build the new store on a temporary address, with the real catalogue and the real prices. Do not point your domain at it yet.
- Place real orders through the new store on real handsets, including one refund, before a customer ever sees it.
- Write the redirect map from your old URLs to the new ones. This is the step the next section is about and the one that is impossible to do after the old site is gone.
- Move the domain during your quietest hours, and keep the old platform paid up for at least one more billing cycle. Cancelling on cutover day removes your fallback on the day you are most likely to need it.
- Watch orders and support for a week before cancelling anything.
The sixth step is the one people economise on and regret. One extra month of a subscription you are leaving is cheap insurance against a cutover that goes wrong at the weekend.
The step that decides whether your traffic survives
If your store gets any search traffic at all, this is the highest-stakes part of the migration and it is the part no platform will help you with.
Search engines have accumulated an understanding of your URLs — which page is about which destination, and how much it is trusted. Change the addresses without telling anyone and that understanding is discarded. Rankings you spent two years earning go to your competitors, and they do not come back on their own.
What to actually do
- Before you move, list every URL that gets traffic. Your analytics and your search console both know; export from whichever you have.
- Map each old URL to its closest new equivalent. Closest — not the homepage. A blanket redirect of everything to the homepage is treated as a soft 404 and loses the ranking anyway.
- Implement them as permanent redirects, not temporary ones, and verify each returns a 301 rather than a 200 or a chain of hops.
- Keep the redirects in place indefinitely. There is no month at which it becomes safe to remove them, and the cost of keeping them is nothing.
- Resubmit your sitemap after cutover and watch the coverage report for a month. Errors show up there before they show up in your revenue.
Ask any platform you are evaluating whether you can configure redirects on it, before you commit. A platform that cannot serve a 301 for an address it does not recognise is a platform you cannot migrate onto without losing traffic — and, for the same reason, one you would struggle to migrate off later.
If you have no search traffic to lose, skip all of this and move on. It only matters in proportion to what you have already earned.
When to stay where you are
Migration has a real cost — the applications, the catalogue remap, the cutover risk and the week of watching. It is worth it for a structural reason and rarely worth it for an irritation.
- Worth moving: you have outgrown a pricing model, you need a supply relationship you cannot get where you are, or a capability that is genuinely absent rather than merely worse.
- Worth moving: you have discovered that something you assumed was yours — the domain, the customer list, the payment relationship — is not.
- Not worth moving: the interface annoys you. You will find things to dislike about the new one within a month.
- Not worth moving: a competitor is marginally cheaper. Run the arithmetic on your real volume first; the difference is often smaller than the migration costs.
- Not yet: you are below a couple of hundred orders a month. At that volume almost every platform difference is noise next to finding more customers.
And the honest note from a company that would like you to migrate to it: if your current platform holds your provider account and your payments and you are happy with both, the case for moving is weaker than our marketing would suggest. Do the inventory first and let it decide.
الأسئلة الشائعة
How do I move my eSIM store to another platform?
Start the payment and provider account applications first, since everything waits on them. Export your customers and orders while you still have access, build the new store on a temporary address, test real orders on real handsets, write a redirect map from your old URLs, then move the domain during quiet hours and keep the old platform paid for one more cycle as a fallback.
Will I lose my customers if I switch eSIM platforms?
Only if you cannot export them, which is why that is worth testing during a trial rather than during a migration. If your payments run through your own merchant account you also hold a customer record there independently, which is a useful second copy.
Will switching platforms hurt my search rankings?
It will if the URLs change and nothing redirects. Map every old address that gets traffic to its closest new equivalent with permanent 301 redirects, keep them in place indefinitely, and resubmit your sitemap. Redirecting everything to the homepage instead is treated as a soft 404 and loses the ranking anyway.
What might I not be able to take with me?
Anything registered in the platform’s name rather than yours. The three that trap people are a domain the platform registered, a payment relationship where the merchant account was theirs, and a supply relationship that only ever existed between you and the platform — so there is no provider account to move.
How long does an eSIM platform migration take?
The store rebuild is days. The realistic timeline is a few weeks, and the wait is almost always payment gateway approval or provider account approval — the same two things that gate a launch. Run the old and new stores in parallel rather than treating cutover as a single date.