MLM Software Migration Checklist: Switch Platforms Without Losing Data
A practical MLM software migration checklist: what data to move, parallel runs, reconciliation, cut-over timing, distributor communication and rollback.
Key takeaways
- Migrate the full history: members, sponsor and placement trees, ranks, wallets, unpaid commissions, orders, KYC and e-pins.
- Run old and new systems in parallel for at least one commission cycle and reconcile every payout difference.
- Cut over immediately after a payout cycle closes, when pending balances are smallest and easiest to verify.
- Tell distributors what changes, when, and what they must do, before, during and after the switch.
- Keep a tested rollback plan and a read-only copy of the old system until reconciliation is signed off.
Why do MLM companies switch software?
Companies rarely migrate on a whim. Common triggers include:
- Commission errors or slow payouts that the current vendor cannot fix.
- An inflexible plan engine where every plan change needs custom code.
- Performance problems as the network grows, such as slow genealogy views or long payout runs.
- Missing compliance features such as seller KYC, TDS, GST invoicing or audit logs.
- Security concerns, including weak access control or no two-factor authentication.
- Vendor risk: poor support, missing documentation, or a vendor that has stopped updating the product.
- Growth needs such as mobile apps, multi-currency or new markets.
If you are still comparing platforms, start with our 15-point buyer's checklist; a migration is the right time to fix every shortcoming at once.
What data must be migrated?
Migrate history, not just current state. Distributors will ask about payouts from months ago, and regulators and auditors may ask about years.
| Data set | What to include | Common pitfall |
|---|---|---|
| Members | IDs, profiles, contact details, status, join dates, bank details | Duplicate or merged accounts with conflicting IDs |
| Sponsor tree | Who introduced whom, for every member | Orphaned members whose sponsor was deleted |
| Placement tree | Position and leg (binary or matrix), spillover history | Positions occupied twice or left empty |
| Ranks | Current rank, highest rank achieved, qualification dates | Recalculated ranks differing from paid ranks |
| Carry-forward volume | Left and right leg balances, accumulated business volume | Volume reset to zero, changing future pairing |
| Wallet balances | Every wallet type, with full ledger history | Importing balances without the transactions behind them |
| Pending and unpaid commissions | Earned but not yet paid, held or under approval | Paying twice or not at all at cut-over |
| Withdrawals | Requested, approved, rejected and paid, with references | Requests in progress lost in transit |
| Orders | Order lines, volumes, invoices, returns | Volume not linked to the correct period |
| KYC documents | Files, verification status, verifier, dates | Files moved without their approval status |
| E-pins | Issued, used and unused pins, owners, values | Used pins reactivated |
| Tax records | TDS deducted, certificates, GST invoice numbering | Invoice number series restarting |
How should you prepare the data?
- Get a full export early. Confirm with your current vendor what format you will receive and when. Check your contract for data ownership terms.
- Profile the data. Count members, check for missing sponsors, duplicate IDs, impossible dates and negative balances.
- Clean at source where possible. Decide how to resolve each anomaly and document the decision.
- Map fields. Build a mapping document from every old field to its new equivalent, including status codes and wallet types.
- Preserve member IDs. Distributors know their IDs and share referral links built on them. Keeping IDs avoids confusion and broken links.
What is a parallel run and why does it matter?
A parallel run means running the same commission cycle on both old and new systems using the same input data, then comparing results member by member. It is the single most reliable way to prove the new commission engine reproduces your plan exactly.
Reconcile at three levels:
- Totals: total business volume, total commission by bonus type, total TDS.
- Members: every member's commission by bonus type and their closing wallet balance.
- Structure: counts of members per leg and level, rank counts and carry-forward volumes.
Investigate every difference, however small. Often the new system is correct and the old one had a long-standing bug; in that case, decide with your leadership how to handle the change and communicate it openly. Our explainer on how a commission engine calculates payouts helps your team understand where differences typically arise, such as rounding, capping and cut-off times.
Never go live on a new commission engine that has not reproduced at least one full real payout cycle.
What else should you test before go-live?
Commissions get most of the attention, but distributors use many other functions every day. Test each of these with real-world scenarios, not just happy paths:
- Logins: password resets, two-factor authentication and mobile app sign-in for migrated accounts.
- Registrations: new joins under existing sponsors, correct placement and spillover in binary or matrix trees.
- Orders: repurchase orders, returns, invoice numbering continuing from the old series and volume posting to the right period.
- Withdrawals: requests, approval workflow, bank file or gateway payout and TDS deduction.
- E-pins: generation, transfer and redemption, and that pins already used cannot be reused.
- Replicating websites and referral links: existing links shared on social media still resolve to the right distributor.
- Reports and roles: admin staff see only what their role permits, and key reports match old totals.
When is the best time to cut over?
Cut over immediately after a payout cycle has closed and been paid. At that moment, pending commissions are at their lowest, wallet balances are freshly reconciled and the next cycle has not accumulated much volume. In practice:
- Announce a short freeze window for registrations, orders and withdrawals.
- Take the final export after the payout is completed and confirmed.
- Import, run automated checks, then spot-check a sample of members across ranks and legs.
- Avoid month-end, quarter-end, festival peaks and big incentive deadlines.
How should you communicate with distributors?
Distributors worry about one thing above all: their money. A clear communication plan prevents rumours.
- Announcement (several weeks before): why you are switching and what improves.
- Leader briefing: show top leaders the new back office first so they can reassure their teams.
- Freeze notice: exact dates and times when ordering and withdrawals pause.
- Go-live message: new login steps, app download links and a support contact.
- Balance confirmation: ask every distributor to check their wallet, rank and team, with a simple way to raise a query.
- Follow-up: publish answers to common questions in the first weeks.
What should a rollback plan include?
A rollback plan is your insurance. Define, before cut-over, the conditions that would trigger it, such as unreconciled wallet differences above an agreed tolerance or the payout run failing. Keep the old system available in read-only mode, keep the final export and database backup, and decide who has authority to call a rollback. Test the rollback once in your staging environment so you know how long it takes.
How MLM.ERP handles migration
MLM.ERP imports members, sponsor and placement trees, ranks, wallet ledgers, e-pins, orders and KYC records, and supports parallel runs against your existing payouts. The plan simulator, 50+ reports and audit logs make reconciliation transparent, and role-based access keeps migration work controlled. Our MLM software migration service page explains the process, and large networks can read about scale and performance on our enterprise MLM software page. For the full module list, see our features.
20-point MLM software migration checklist
| # | Task | Phase |
|---|---|---|
| 1 | Document reasons for switching and success criteria | Plan |
| 2 | Confirm data ownership and export terms with current vendor | Plan |
| 3 | Document the compensation plan rules in full, including edge cases | Plan |
| 4 | Configure the plan in the new system and test it in the simulator | Build |
| 5 | Obtain a full trial export of all data sets | Data |
| 6 | Profile and clean data: duplicates, orphans, negative balances | Data |
| 7 | Create the field mapping document and preserve member IDs | Data |
| 8 | Import sponsor and placement trees and verify counts per leg | Data |
| 9 | Import ranks, carry-forward volume and qualification history | Data |
| 10 | Import wallet ledgers and match every closing balance | Data |
| 11 | Import pending commissions, withdrawals in progress and e-pins | Data |
| 12 | Import orders, invoices, returns, KYC files and tax records | Data |
| 13 | Run at least one full commission cycle in parallel | Test |
| 14 | Reconcile totals, member-level payouts and structure; explain differences | Test |
| 15 | Test payment gateway, withdrawals, invoices and TDS end to end | Test |
| 16 | Brief leaders and announce the switch and freeze window | Communicate |
| 17 | Agree rollback triggers, owner and tested procedure | Cut-over |
| 18 | Cut over right after a payout cycle closes; take final export | Cut-over |
| 19 | Spot-check members, ask distributors to confirm balances | Go-live |
| 20 | Keep old system read-only until sign-off, then archive securely | Close |
Summary
A safe migration moves full history, proves the new commission engine with a parallel run, cuts over after a payout, keeps distributors informed and has a tested way back. Treat it as a finance project, not just an IT project, because every record represents money someone is owed.
Planning a switch? Book a free MLM.ERP demo and we will review your current data, your plan and a realistic migration timeline with you.
Frequently asked questions
Can I migrate MLM software without losing my genealogy tree?
Yes, if both sponsor and placement relationships are exported for every member and imported with original member IDs. Verify counts per leg and level after import, check for orphaned members and compare a sample of downlines visually in both systems before you cut over. Never rebuild the tree from scratch.
How long does an MLM software migration take?
It depends on data volume, data quality and plan complexity. The longest stages are usually cleaning data, configuring the plan and running at least one full parallel commission cycle. Plan around your payout calendar so cut-over happens immediately after a cycle is paid, and allow time for reconciliation.
What happens to unpaid commissions during migration?
Pending and unpaid commissions should be imported as open liabilities with their original amounts, dates and statuses, or settled in the old system before cut-over. Either way, reconcile them member by member so nothing is paid twice or missed. Cutting over right after a payout cycle keeps the pending amount small.
Should I tell distributors before switching MLM software?
Yes. Announce the switch weeks in advance, brief leaders first, publish the freeze window for orders and withdrawals and share new login steps. After go-live, ask everyone to confirm their wallet balance, rank and team, and provide a simple way to raise queries. Clear communication prevents rumours about missing money.
We design and build MLM software for direct selling companies in India and worldwide. This article reflects our product and implementation experience; it is not legal or tax advice.