Switching SMM panels is easy at the login level and harder at the operational level. Order history, refill rights, wallet balance and service IDs do not automatically move with you.
Quick answer: inventory open orders first, protect refill windows, spend down or resolve the old balance, test the new panel separately, then migrate links and API mappings in stages.
What Does Not Transfer to the New Panel?
- Order IDs
- Start counts
- Refill eligibility
- Refill request history
- Wallet balance
- Local service IDs
- Support tickets
- Provider-specific service rules
Step 1: Export Active and Recent Orders
Before changing anything, keep a record of orders that still matter. Include order ID, link, service ID, quantity, completion date, start count and refill period.
Step 2: Identify Links With Open Refill Windows
If an old order still has refill coverage, placing a new order from another panel on the same link can make the baseline harder to verify. Finish or settle the old refill process first where possible.
See What Does Refill Mean in an SMM Panel? for the start-count logic.
Step 3: Resolve the Old Wallet Balance
Many panels use non-withdrawable prepaid credit. Review the published withdrawal/refund rules before assuming the remaining balance can be returned to the original payment method.
Step 4: Test the New Panel Independently
Use a different test link and a small quantity. Do not contaminate an existing refill baseline merely to test a replacement provider.
Step 5: Re-Map Every Service ID
Service IDs are panel-local. Service 123 on Panel A may be unrelated to service 123 on Panel B. Compare the actual service name, type, rate, min/max, refill and description before mapping.
Step 6: Move Traffic Gradually
A staged migration makes problems easier to isolate. Move one category or a small group of services first, monitor the results, then expand.
API Migration Checklist
| Item | Old panel | New panel |
|---|---|---|
| API endpoint | Record current URL | Verify new URL |
| API key | Keep until migration complete | Create and store securely |
| Service IDs | Export mappings | Re-map manually or by rules |
| Open orders | Continue status checks | Do not duplicate |
| Refills | Keep old order references | New panel cannot honor old IDs |
| Balance | Spend/resolve | Fund minimally for testing |
Why a New Panel May Not Fix a Service Problem
Two panels can share the same upstream provider. If you move because one service is failing and the new panel routes to the same source, the problem may continue.
Research shared supply signals in How to Tell If Two SMM Panels Use the Same Provider.
Keep the Old Account Accessible for a Short Transition
Do not delete the old account while you still need order IDs, invoices, refill records or payment evidence. Keep access until the migration is fully reconciled.
When to Switch Immediately
If you suspect credential compromise or a serious security issue, protecting API keys and payment credentials can take priority over a slow migration. Rotate secrets first, then reconcile operational data.
Plan the Migration in Phases
A clean switch is not one button. Treat it as four phases: inventory, test, cutover and cleanup. This reduces the chance of losing refill rights or creating duplicate API orders.
| Phase | Main task | Exit condition |
|---|---|---|
| Inventory | Export open orders, refills, balances and mappings | You know what still depends on the old panel |
| Test | Run small orders on the new panel | Key services and payment flow are verified |
| Cutover | Move new orders/API traffic gradually | New panel handles expected volume |
| Cleanup | Resolve old balance and refill windows | No important workflow remains on old panel |
Create a Service Mapping Sheet
Do not map by numeric ID. Create a row for each important service with old ID, old name, new ID, new name, rate, min/max, refill and any restrictions. This makes it much easier to spot a mismatch before customers place orders.
Keep Provider Correlation in Mind
If the new panel uses the same upstream provider, switching may not solve the problem that triggered the migration. Compare unusual catalog patterns, synchronized availability changes and provider disclosures before assuming the new panel is independent.
API Cutover: Avoid Double Submission
During API migration, use a clear cutover point. Requests created before that point should continue checking the old provider; requests after that point should use the new mapping. Do not resend uncertain timeout orders to the new panel without confirming whether the old panel accepted them.
Preserve Customer-Facing Order IDs
If you run your own reseller panel, customers should keep seeing your local order ID even when you change upstream providers. Store the old and new provider IDs internally so your support team can trace both sides.
Handle Old Balance Intentionally
Before depositing heavily at the new panel, decide what will happen to the old balance. Spend it on low-risk remaining orders if appropriate, request a withdrawal only if the policy supports it, or keep a small amount available for refill-related workflows if required.
Customer Communication
If the switch changes service IDs, prices, min/max values or expected delivery, update customer-facing descriptions. Do not silently replace a service with a materially different product while keeping the same promise.
Rollback Plan
A migration is safer when you can roll back. Keep the old API credentials and mappings active until the new provider has handled enough volume to build confidence, unless the reason for leaving is a security incident.
Migration Metrics to Watch
- Start-time distribution
- Partial/cancel rate
- Support tickets per 100 orders
- Provider balance consumption
- Price changes
- Refill request acceptance
- API error rate
When Not to Wait
If you believe an API key is compromised, the panel has stopped processing payments correctly, or there is a serious security issue, rotate credentials and stop new traffic immediately. Operational convenience should not override security.
How to Use This Guide in Practice
Use this article as a research framework rather than as a permanent promise about any individual panel. Save the service name, policy wording, date and evidence that supports your decision. If a panel changes its catalog, provider, payment method or terms, update your conclusion instead of assuming the old information still applies.
For high-value decisions, compare at least two independent sources and verify the current information directly on the relevant website. SMMFAQ’s Panel Directory can help with discovery, while individual service, API and provider guides provide context for interpreting what you find.
What to Document
- The exact page or service you checked
- The date and time of the observation
- Any payment, refill, cancel or delivery terms that influenced the decision
- Whether the claim came from the panel itself or from an independent source
- What remains unknown because it requires an authenticated account or paid test
This evidence-first approach is especially important in SMM research because service catalogs can change quickly and one panel can use several upstream providers at the same time.
Migration Example for an API Reseller
Suppose your panel sells 40 active services from Provider A and you want to move 12 of them to Provider B. Do not replace all 12 mappings at once. Start with two low-risk services, monitor order acceptance and status updates, then expand the mapping after the behavior is stable.
Keep the old provider ID attached to existing orders. New orders can use the new provider while old orders continue checking their original source for status and refill. This preserves traceability.
Customer-Facing Service Changes
If the new source has a different refill period, min/max, speed or targeting, update the service description and price before routing customer orders. A provider migration should not silently change the product customers believe they are buying.
Final Migration Checklist
- No active order is being duplicated across providers.
- Old refill-eligible orders still reference the old provider.
- New service IDs are mapped by product, not by number.
- Payment balance exists at the new provider.
- Support team knows which provider handles which order.
- Customer-facing descriptions match the new source.
- Rollback credentials remain available until the cutover is proven.
When the Migration Is Complete
Close the old operational dependency only after balances, open orders, refills and records are reconciled. Keep historical exports for accounting and support. If the old account contains no remaining business data or balance, then you can reduce access or close it according to the provider’s process.
Protect SEO, Branding and Customer Access During a Platform Move
If you are moving your own reseller website rather than merely changing one upstream API, preserve the customer-facing domain, URLs and account access where possible. A backend migration should not force customers to relearn the brand or create new accounts unless technically necessary.
Export customer balances carefully and reconcile them before cutover. A migration that moves services but loses wallet balances or transaction history creates a larger support problem than the provider issue you were trying to solve.
Post-Migration Review
After one week and again after one month, compare the new panel with the old baseline: provider cost, Partial rate, cancellation rate, refill tickets, API errors and support volume. Keep the new source only if the operational result is actually better, not simply because the interface looked newer.
Do Not Judge the New Panel From the First Day Alone
Early migration traffic is often small and unusually easy to support. Keep measuring after normal volume returns. A provider that works for ten test orders may behave differently during peak periods or larger quantities.
Maintain a short transition report that records which services moved, when they moved, the old and new provider IDs, and any customer-facing changes. This becomes valuable when a refill request appears weeks later and support needs to know which upstream source originally handled the order.
Keep a Read-Only Migration Archive
After the cutover, preserve a read-only export of old order IDs, provider IDs, balances, refill dates and service mappings. You may not need the old panel operationally, but historical records can still resolve customer questions, accounting differences and refill disputes long after new traffic has moved elsewhere.
Frequently Asked Questions
Does refill coverage transfer to a new SMM panel?
No. Refill is tied to the original order and the provider or panel that recorded its start count and conditions.
Should I close the old panel account immediately?
Usually not. Keep access until active orders, refill windows, payment records and any remaining balance are resolved.
Can I reuse the same service IDs on a new panel?
No. Service IDs are local to each panel and can refer to completely different products.
How should API resellers migrate?
Export active orders, map new service IDs, test the new provider, update endpoint/key settings, and move traffic gradually instead of switching everything at once.
What is the biggest refill mistake during migration?
Placing a new order on a link that still has an active order or refill window on the old panel.