Migrating from SliceWP
Concept mapping, terminology differences, and what to expect when moving from SliceWP to Siren.
Last updated: April 10, 2026
Migrating from SliceWP
SliceWP and Siren both manage affiliate partnerships in WordPress, but they’re built around different ideas. SliceWP is a straightforward affiliate tracker: affiliates share links, customers click them, commissions are recorded. Siren is a broader incentive management system that can do affiliate tracking but also handles royalties, revenue shares, bonuses, and other reward structures.
This guide maps SliceWP’s concepts to Siren’s, explains where the two systems differ, and covers what to expect during a migration. For the architectural reasoning behind Siren’s approach, see the migration overview.
Use Beacon for migration assistance
There’s no automated SliceWP importer today. The supported way to migrate is to describe your current setup to Beacon, Siren’s free AI assistant, and let it suggest the matching recipe. If you’re using SliceWP’s Performance Bonuses add-on, describe the rules to Beacon and it’ll build you a distributor that captures the same behavior. If you’re using Product Commission Rates or Product Revenue Share, describe the rate breakdown and Beacon will translate it into a program with the right line item filters.
A good starting prompt is something like “I’m coming from SliceWP. My setup is a 20% global rate, a Performance Bonus that pays $100 to the top referrer each month, and Product Revenue Share on a handful of courses. Build me a recipe that matches this.” Beacon will walk you through any gaps and flag anything that doesn’t have a direct equivalent.
Terminology mapping
Most of what you know from SliceWP has a counterpart in Siren, though some concepts are split into multiple parts and a few are new.
| SliceWP Term | Siren Equivalent | Notes |
|---|---|---|
| Affiliate | Collaborator | Same role, broader label. Collaborators can be affiliates, creators, salespeople, or anyone earning incentives. |
| Commission | Conversion + Obligation | SliceWP combines “what happened” and “what’s owed” into one commission record. Siren separates them. More on this below. |
| Visit | Opportunity | A record of a tracked visitor arriving through a referral mechanism. |
| (no equivalent) | Engagement | A per-program credit claim. When a visitor arrives and the collaborator is enrolled in multiple programs, each program gets its own engagement. SliceWP doesn’t have this because it doesn’t have multi-program attribution. |
| Payout | Fulfillment | The batch operation that groups payments together. |
| Payment | Payout | An individual payment to a collaborator within a fulfillment. |
| Customer | Tracked through opportunities | Siren doesn’t maintain a separate customer table. Customer attribution is tracked through opportunities and engagements instead. |
| Coupon (Pro add-on) | Alias (type: coupon) | Coupon-based tracking in Siren uses the alias system rather than a separate feature. |
| Affiliate referral link | Alias (type: tracking) | Referral codes are stored as aliases. The alias system preserves history, so old codes keep working even after changes. |
| Global commission rate | Program | SliceWP uses one global rate with per-affiliate overrides. Siren puts rates on programs instead. |
| Commission Items | Transaction details | Line-item level data on conversions and obligations. |
| Multi-level Affiliates | Not used | Siren uses multi-program structures instead of MLM tiers. See the explanation below. |
| Cross-site Tracking | Not used | Siren tracks within a single WordPress installation. |
| Performance Bonuses | Distributor | Scheduled aggregate bonuses based on tracked metrics. See add-ons and distributors below. |
| Product Revenue Share | Program with line item filters | A program with collaborator-owned product filtering. See add-ons and distributors below. |
| (no equivalent) | Distributor | Scheduled, aggregate reward distribution based on tracked metrics over time. SliceWP’s Performance Bonuses cover part of this, but distributors are more flexible. |
| Product Commission Rates add-on | Line item filters | Composable filters by category, SKU, product type, or ownership. See product-level commission control below. |
Status mapping
Commission statuses
SliceWP’s commission statuses map to different fields in Siren because Siren separates conversions from obligations.
| SliceWP Status | Siren Equivalent | Which record |
|---|---|---|
| pending | pending | Conversion |
| unpaid | pending | Obligation |
| paid | complete | Obligation |
| rejected | rejected | Conversion or Obligation (depending on when rejection happens) |
In SliceWP, a commission moves through pending, unpaid, and paid as a single record. In Siren, the conversion tracks whether the sale itself is valid, and the obligation tracks whether the collaborator has been paid. A conversion can be approved while the obligation is still pending payment. They move through their lifecycles independently.
Affiliate statuses
| SliceWP Status | Siren Status |
|---|---|
| active | active |
| pending | pending |
| rejected | rejected |
These map directly. No surprises here.
Architectural differences
Commission rates live on programs, not affiliates
SliceWP uses a global commission rate. You set it once, and every affiliate earns that rate unless you override it on their individual affiliate profile. The more affiliates with custom rates you have, the harder it gets to see what’s actually configured across your system.
Siren puts commission rates on programs. A program defines the rate, what triggers the reward, and who is eligible. If you need two different rates, you create two programs. Each program’s rules are self-contained and visible in one place rather than scattered across individual affiliate profiles.
This means that what was “one affiliate program with a bunch of overrides” in SliceWP often becomes “a few programs with clear, distinct rules” in Siren.
Multi-program instead of multi-level
SliceWP supports multi-level (MLM) affiliate structures through an add-on. A parent affiliate recruits sub-affiliates and earns a percentage of their sales. The earning relationship follows the recruitment hierarchy.
Siren doesn’t support MLM structures, and this is a deliberate choice rather than a gap. Multi-level setups tend to couple earning rules tightly to a recruitment tree, which makes the system rigid and hard to reason about.
Siren’s approach is to let you create independent programs for different types of contributions. Instead of having a parent affiliate earn from sub-affiliate sales through an MLM tier, you might create a separate recruiter bonus program that rewards people for bringing in new collaborators, alongside your main affiliate program. Each program has its own rules, and they don’t interfere with each other.
This covers many of the scenarios people reach for MLM to solve, but through a different mechanism. If you genuinely need MLM-style hierarchical payouts, Siren is not the right tool for that.
A commission is a merged record
This is the most important structural difference. In SliceWP, when a sale happens, one commission record is created. That record contains both the event (a sale was attributed to this affiliate) and the financial obligation (you owe this affiliate this amount). The commission tracks the sale and the payment in a single row.
Siren splits these into separate records. A conversion records that something happened and was attributed to a collaborator through a program. An obligation records what’s owed as a result. They’re linked, but they have their own statuses and lifecycles.
Why does this matter? Because in Siren, one sale can create multiple conversions and obligations across different programs. If a customer clicks an affiliate link and buys a course, the referring affiliate might earn a 20% commission through the affiliate program while the course creator earns a 50% royalty through a creator program. Two obligations from the same transaction, tracked independently. SliceWP can’t do this because its commission model assumes one sale equals one record.
If you only ever run a single affiliate program, this separation is invisible. Everything works the same way. But it’s the reason Siren can handle more-complex incentive structures without workarounds.
No separate customer tracking
SliceWP maintains a customers table that links customers to the affiliate who referred them. This makes it easy to look up “which affiliate brought in this customer.”
Siren tracks the same attribution data, but through opportunities and engagements rather than a dedicated customer entity. When a visitor arrives through a referral mechanism and later makes a purchase, the attribution chain connects the collaborator to the transaction. You can trace who referred whom, but there isn’t a standalone customer record to query.
For most use cases this works the same way. If you rely heavily on customer-level reporting in SliceWP, talk through your needs before migrating to make sure the attribution data in Siren gives you what you need.
Add-ons and distributors
SliceWP includes a Performance Bonuses add-on that awards bonuses when affiliates reach targets. You can set targets based on referred order count, referred order totals, or commissions earned, and pay out on a one-time, monthly, quarterly, or yearly basis.
Siren handles this through distributors, which are a more-flexible version of the same idea. A distributor tracks collaborator performance over a period using any combination of metric events (sales, course completions, blog visits, coupon uses, and more). When the distribution triggers on schedule, the reward can go to the top performer, be split proportionally by score, or be divided evenly among everyone who participated. SliceWP’s Performance Bonuses are limited to three metrics, four schedule options, and flat bonus amounts. Siren distributors support arbitrary metrics, any schedule, and multiple distribution strategies.
If you’re using SliceWP’s Recurring Commissions add-on, Siren handles per-renewal commissions through the renewal conversion type in programs, not through distributors. But if you want to bonus collaborators based on how many renewals they generated over a period, a distributor handles that.
SliceWP’s Product Revenue Share add-on links affiliates to specific products so they earn on every sale regardless of referral. In Siren, this is a program with line item filters set to collaborator-owned products. It works the same way but uses the standard program system rather than a separate feature.
Transaction filtering and commission calculations
SliceWP calculates commissions on the post-discount cart total. There is no option to calculate on the pre-discount amount. Shipping and tax each have toggles in the settings to include or exclude them. Fees are not addressed in the documentation.
Without the Product Commission Rates add-on, SliceWP calculates percentage commissions from the cart’s total amount rather than per line item. The add-on adds per-product and per-category rates, and with it enabled, commissions are calculated per product and summed. You can also disable commissions on individual products through a checkbox on the product edit screen.
Siren’s transaction filtering gives you more control at both levels.
For the commission base, each component (line items, discounts, fees, shipping, taxes) is an independent compiler that you enable or disable per program. SliceWP hardcodes discounts as always subtracted. Siren lets you choose whether discounts factor in. SliceWP doesn’t address fees at all. Siren has a fees compiler you can toggle.
For product-level control, Siren’s line item filters let you stack category, SKU, product type, and collaborator ownership filters with AND logic. SliceWP’s Product Commission Rates add-on provides per-product and per-category control, but cannot filter by SKU or product type, and cannot combine independent filter conditions.
Per-product and per-category rates
With the Product Commission Rates add-on, SliceWP lets you set a custom rate on individual product edit screens and on product categories. If Product A should pay 30% and Product B should pay 15%, you set those rates directly.
In Siren, you create a program for each distinct rate and use line item filters to target the products. A 30% program filtered to Product A’s SKU and a 15% program filtered to Product B’s SKU achieves the same outcome. For categories, a program filtered to a specific category with the desired rate works the same way.
This is more setup than SliceWP’s inline rate fields, but it scales better. Adding a new product to an eligible category automatically includes it in the program without touching the product’s settings. And because filters compose, you can express things like “25% on subscriptions in the premium category” as a single program rather than setting rates on each subscription product individually.
What migrates
| SliceWP Data | Siren Destination | Notes |
|---|---|---|
| Affiliates | Collaborators | User accounts likely already exist in WordPress. The migration creates collaborator records and enrolls them in the appropriate programs. |
| Commissions | Conversions + Obligations | Historical records. Imported as completed conversions and fulfilled obligations to preserve earning history. |
| Visits | Opportunities | Historical records. Imported as completed opportunities for reporting continuity. |
| Payments | Payouts | Historical payment records within fulfillments. |
| Tracking codes | Aliases | Existing referral codes are stored as aliases so published links continue to work. |
| Multi-level relationships | Do not migrate | These don’t have a Siren equivalent. You’ll need to restructure the earning logic as separate programs. |
| Cross-site tracking config | Does not migrate | Siren operates within a single WordPress installation. |
| Customer records | Not directly migrated | Customer attribution is tracked through opportunities and engagements. The data is preserved in the attribution chain, not as a standalone table. |
Active browser cookies from SliceWP won’t transfer. If a customer clicked a referral link before the migration but hasn’t purchased yet, that attribution will be lost unless you handle it manually. For most sites this is a narrow window, but it’s worth noting if you have long cookie durations configured.
Database table reference
If you’re writing a custom migration script or inspecting data directly, this shows where SliceWP’s tables map to in Siren.
| SliceWP Table | Siren Destination |
|---|---|
slicewp_affiliates | collaborators + aliases |
slicewp_commissions | conversions + obligations |
slicewp_visits | opportunities |
slicewp_payouts | fulfillments |
slicewp_payments | payouts |
slicewp_customers | Tracked through opportunities and engagements |
The slicewp_affiliates table splits into two Siren tables because the affiliate’s identity (collaborator record linked to a WordPress user) and the affiliate’s tracking code (alias record) are stored separately in Siren. Similarly, slicewp_commissions splits into conversions and obligations because Siren separates attribution from financial records.