Understand assisted migration
Assisted migration is for sellers who already run products, subscriptions, integrations, or funnels on another platform and want to move to AtomicPay without rebuilding everything alone. It is a service-led onboarding path, not a self-serve import button inside the dashboard.
Use this guide to set expectations with finance, support, and launch teams before a platform switch.
What assisted migration is designed to do
| Goal | What it means in practice |
|---|---|
| Parallel setup | Rebuild products, billing, and integrations before the public switch |
| Lower switch risk | Test buyer paths before replacing live links |
| Recurring customer continuity | Preserve active subscriptions where the migration plan supports it |
| Integration continuity | Replicate webhooks, MemberKit, pixels, and funnel paths where needed |
| Post-switch support | Dedicated follow-up during early operations |
Assisted migration vs manual onboarding
| Topic | Assisted migration | Manual onboarding |
|---|---|---|
| Who does the setup | Migration team plus seller collaboration | Seller team inside AtomicPay |
| Best for | Existing operations with live buyers and subscriptions | New launches or small catalogs |
| Timing | Planned project with testing and switch window | Seller-controlled pace |
| Risk profile | Higher stakes because live revenue already exists | Lower switch risk but still needs testing |
| Documentation entry point | This article plus first-sale workflow | Create business and first-sale workflow |
Typical migration phases
| Phase | What happens |
|---|---|
| Operation diagnosis | Map products, recurring billing, integrations, and structure |
| Parallel setup | Rebuild products, pricing, checkout, and delivery in AtomicPay |
| Testing | Validate checkout, subscriptions, webhooks, pixels, and funnels |
| Live switch | Move traffic and links according to the agreed plan |
| Follow-up | Support during early post-migration operations |
What your team should prepare
- List of active products, offers, and subscription plans
- Current checkout links, funnels, and campaign paths
- Integrations such as webhooks, MemberKit, Notazz, or Zapier / Make
- Finance expectations for payout timing, fees, and withdrawals
- Support workflow for existing buyers during the switch
- Team access plan for launch and support staff
What to verify before the public switch
| Check | Why it matters |
|---|---|
| Test buyer path works end to end | Payment, Sales, and delivery |
| Subscription behavior is understood | See subscriptions and overdue handling |
| New links and redirects are ready | Reduces campaign attribution gaps |
| Finance setup is progressing | Avoids payout surprises after switch |
| Support scripts are updated | Especially for payment methods and access issues |
Best practices
- Treat migration as a project, not a same-day toggle.
- Keep old links working until redirects or replacements are confirmed.
- Test PIX and card flows on the new checkout path.
- Review reconcile Dashboard and Finance after the first post-migration sales.
- Run before-launch checklists even during migration testing.
Common mistakes
- Expecting every object to migrate automatically without verification.
- Switching traffic before subscription and delivery tests finish.
- Ignoring affiliate or funnel dependencies.
- Changing finance expectations without reading fees and settlement timing.
- Skipping support training on incomplete payments and buyer access.
FAQ
Is assisted migration the same as creating a new product manually?
No. Manual setup is for new launches. Assisted migration is for moving an existing operation with parallel replication and switch planning.
How do I start assisted migration?
Contact the AtomicPay migration team from the marketing site or your account representative. This help article explains expectations, not the sales intake process.