Migrating from AffiliateWP
Concept mapping, terminology differences, and what to expect when moving from AffiliateWP to Siren.
Last updated: April 10, 2026
Migrating from AffiliateWP
This guide maps AffiliateWP’s concepts, terminology, and data structures to their Siren equivalents. It assumes you’ve read the Migration Overview, which explains why Siren’s architecture works the way it does. This page focuses on the specifics of moving from AffiliateWP.
Use Beacon for migration assistance
Siren doesn’t ship with an automated AffiliateWP importer. Migration is a manual concept-mapping exercise, and the supported way to get help with it is Beacon, Siren’s free AI assistant. Describe your current AffiliateWP setup to Beacon (your global rate, per-affiliate overrides, any add-ons like Tiered Affiliate Rates or Allowed Products, your coupon assignments) and ask it to translate the structure into a Siren recipe. For example, “I’m running a 20% global rate with three VIP affiliates at 30%, and I use the Tiered Affiliate Rates add-on to bump affiliates to 25% after $5,000 in sales. Can you build me a recipe that matches this?”
Beacon will typically respond with a program group for the tier logic and a distributor for the performance threshold. Review the mapping tables below alongside Beacon’s output so you understand what each piece is doing.
Terminology mapping
| AffiliateWP Term | Siren Equivalent | Notes |
|---|---|---|
| Affiliate | Collaborator | Broader term, same WordPress user model underneath |
| Referral | Conversion + Obligation | Siren separates “what happened” from “what’s owed” |
| Visit | Opportunity | The trackable visitor instance |
| (no equivalent) | Engagement | Per-program credit claim. AffiliateWP doesn’t have this because it doesn’t have multi-program. |
| Payout | Fulfillment (batch) + Payout (individual) | Siren splits the batch from the individual payment records within it |
| Creative | Not used | WordPress block editor handles promotional materials. See the Migration Overview for context. |
| Campaign | Not used | Nobody has asked for it |
| Coupon | Alias (type: coupon) | See Aliases |
| Referral URL parameter | Alias (type: tracking) | Existing referral links keep working through aliases |
| Global commission rate | Program | Rates live on programs, not globally or per-affiliate |
| Per-affiliate rate override | Separate program enrollment | Create a program with different rates and enroll the collaborator in it |
| Referral type (sale/opt-in/lead) | Conversion type (sale/lead/renewal) | |
| Direct Link Tracking | Not supported | |
| Lifetime Commissions | Roadmapped, not yet available | |
| Recurring Referrals | Supported via renewal conversion type | Requires the Renewals feature flag |
| Affiliate Groups | Program Groups | The concept is different. See the section below on program groups. |
| Smart Commission Rules | Programs | Per-product and per-category filtering are built into programs |
| Tiered Affiliate Rates | Distributor | Scheduled aggregate bonuses based on performance metrics. See add-ons and distributors below. |
| Sign Up Bonus | Distributor or Program | See add-ons and distributors below. |
| Leaderboard | Distributor | Distributors compute rankings as part of their normal operation. |
| (no equivalent) | Distributor | Scheduled, aggregate reward distribution based on tracked metrics over time. AffiliateWP has no equivalent concept. |
| Allowed Products add-on | Line item filters | Composable filters by category, SKU, product type, or ownership. See product-level commission control below. |
| Disable referrals (per product) | Line item filters | Filter approach instead of per-product toggles. |
| Per-product rates | Program with line item filters | Rates live on programs. Filters control which products qualify. See transaction filtering below. |
Status mapping
Referral statuses
AffiliateWP referral statuses map to a combination of conversion and obligation statuses in Siren.
| AffiliateWP Referral Status | Siren Equivalent |
|---|---|
| pending | Conversion: pending |
| unpaid | Obligation: pending (approved, awaiting payout) |
| paid | Obligation: complete (included in a fulfillment) |
| rejected | Conversion: rejected OR Obligation: rejected |
The split between conversion and obligation statuses is why “pending” maps differently than “unpaid.” In AffiliateWP, a pending referral hasn’t been reviewed yet. An unpaid referral has been approved but not paid. In Siren, the conversion tracks whether the event was legitimate, and the obligation tracks whether the payment has been made. These are separate questions with separate answers.
Affiliate statuses
These map directly.
| AffiliateWP Affiliate Status | Siren Collaborator Status |
|---|---|
| active | active |
| inactive | inactive |
| pending | pending |
| rejected | rejected |
Architectural differences
The Migration Overview covers Siren’s general architecture. This section focuses on the differences that will feel most noticeable coming from AffiliateWP specifically.
Commission rates live on programs, not affiliates
In AffiliateWP, you set a global commission rate in Settings, then override it per affiliate when someone negotiates a better deal. The more affiliates you have with custom rates, the harder it gets to see what’s actually happening across your program.
Siren puts rates on programs. Each program defines what triggers a reward, how it’s calculated, and who’s eligible. If you need a different rate for a specific collaborator, you create a program with that rate and enroll them. All the commission logic stays in one place rather than being scattered across individual affiliate profiles.
This feels like more work at first. In practice, most AffiliateWP setups have only a handful of distinct rate tiers. Turning those tiers into named programs makes the structure visible and easier to reason about.
One sale can create multiple payouts
AffiliateWP creates one referral per sale. One affiliate gets credit, one commission is calculated, one payout eventually happens.
Siren can create multiple conversions and obligations from a single transaction because each program evaluates the sale independently. If a customer clicks an affiliate link and then buys a course created by a content partner, the affiliate might earn a 25% commission and the course creator might earn a 50% royalty. Two obligations from the same sale, through two different programs, without conflict.
If you only run a single affiliate program, this works identically to AffiliateWP. The separation only becomes visible when your incentive structures grow beyond one-affiliate-one-commission.
Program groups are not affiliate groups
AffiliateWP’s affiliate groups are organizational buckets. You put affiliates into groups to apply bulk rate overrides or manage them more easily. The groups themselves don’t have logic.
Siren’s program groups solve a different problem. A program group is a set of mutually exclusive programs. When a sale could trigger multiple programs in the same group, the group’s sorter picks a winner. For example, if you have both a “Standard Affiliate” program and a “VIP Affiliate” program in the same group, the sorter determines which one applies to a given conversion.
If you’re using AffiliateWP affiliate groups purely for organization, the equivalent in Siren is just enrolling collaborators in the appropriate programs. If you’re using groups to manage which rate applies, that logic moves to program groups with sorters.
No per-affiliate rate overrides
This follows from rates living on programs. In AffiliateWP, you might have 50 affiliates at 20% and 3 at 30%. In Siren, you’d create two programs: one at 20% and one at 30%. The three collaborators who earn 30% are enrolled in the higher-rate program instead of (or in addition to) the standard one.
This means looking at a program tells you exactly who earns what. You don’t have to check each collaborator’s profile to find hidden overrides.
Tracking is more granular
An AffiliateWP visit records “someone clicked affiliate X’s link.” Siren splits this into two records.
An opportunity records “someone arrived through this referral mechanism.” An engagement records “this collaborator has a credit claim in this specific program.” One opportunity can produce multiple engagements if the collaborator is enrolled in multiple programs.
For a single-program setup, this distinction is invisible. You’ll see opportunities where you used to see visits, and the engagement layer operates in the background. For multi-program setups, the separation is what allows per-program attribution to work.
Add-ons and distributors
Several AffiliateWP add-ons cover use cases that Siren handles through distributors.
AffiliateWP’s Tiered Affiliate Rates add-on automatically bumps an affiliate’s commission rate when they hit a threshold, like 50 referrals or $5,000 in earnings. The rate change applies going forward to future transactions. In Siren, a distributor can track the same metrics (sales count, total earnings, or anything else) over a period and award a bonus when the distribution triggers. The difference is that AffiliateWP changes the per-transaction rate, while Siren pays an aggregate bonus on a schedule. The result for the collaborator is similar, but Siren’s approach is more flexible because you can track any metric, use any schedule, and distribute the reward proportionally, to the top performer, or evenly across everyone who hit the threshold.
AffiliateWP’s Sign Up Bonus add-on awards a one-time flat payment when a new affiliate registers. In Siren, a distributor can handle this, though for a simple one-time bonus a program may be more straightforward depending on the setup.
If you’re using AffiliateWP’s Recurring Referrals add-on to pay commission on subscription renewals, Siren supports this through the renewal conversion type when the Renewals feature flag is active. This is a per-transaction feature handled by programs, not distributors. But if you want to pay a bonus based on how many renewals a collaborator generated over a month or quarter, a distributor handles that naturally.
AffiliateWP’s Leaderboard add-on displays a ranked list of top affiliates. Distributors compute exactly this kind of ranking as part of their normal operation, since incentive structures like top score wins and performance weighted pool require calculating who performed best. The display side is separate, but the data is there.
Transaction filtering and commission calculations
AffiliateWP calculates percentage commissions per line item and always uses the post-discount amount. There is no option to calculate on the pre-discount price. Shipping and tax each have a toggle in Settings > Commissions to include or exclude them. Fees (signup fees, subscription fees) are included with no toggle.
For product-level control, AffiliateWP offers per-product rates, per-category rates, a “Disable referrals” checkbox to exclude individual products, and a free Allowed Products add-on that provides an allowlist of eligible product IDs. These work through a priority hierarchy where the most specific rate wins (affiliate-specific beats product, beats category, beats global).
Siren’s transaction filtering works differently in two ways.
First, the commission base itself is modular. Each component of a transaction (line items, discounts, fees, shipping, taxes) is an independent compiler that you enable or disable per program. If you want commissions on the pre-discount amount, don’t enable the discounts compiler. If you want subscription signup fees to count, enable the fees compiler. AffiliateWP hardcodes discounts and fees. Siren lets you choose.
Second, when line items are enabled, composable filters narrow which products qualify. You can filter by category, SKU, product type (products vs. subscriptions), or collaborator ownership, and filters combine with AND logic. AffiliateWP has category-based rates and product exclusions, but cannot filter by SKU or product type, and cannot combine independent filter dimensions.
Per-product and per-category rates
AffiliateWP lets you set a custom commission rate on individual products and on product categories. If Product A should pay 30% and Product B should pay 15%, you set those rates directly on each product’s edit screen. If everything in the “courses” category should pay 25%, you set a category rate.
Siren doesn’t have per-product or per-category rate fields. Instead, you create separate programs with different rates and use line item filters to control which products each program applies to. A program paying 30% filtered to Product A’s SKU and a program paying 15% filtered to Product B’s SKU achieves the same result. For category-based rates, a program filtered to the “courses” category with a 25% rate works the same way.
The tradeoff is that Siren requires creating a program for each distinct rate, while AffiliateWP lets you set rates inline on product screens. The upside is that Siren’s approach keeps all commission logic visible in one place (the programs list) rather than scattered across individual product settings. It also means you can combine the category filter with other dimensions. A program that pays 25% only on subscription products in the “courses” category that are owned by the collaborator is a single program in Siren. In AffiliateWP, there is no way to express that combination because per-product rates, per-category rates, and per-affiliate rates are separate override layers that don’t compose.
When migrating, audit your per-product and per-category rates and group them by distinct rate. Each group becomes a program with the appropriate rate and filters. Most stores have a small number of distinct rates even if they’re applied to many products, so the number of programs stays manageable.
What migrates
These AffiliateWP records have direct Siren equivalents and can be migrated.
- Affiliate accounts become collaborator records, linked to the same WordPress user accounts.
- Affiliate tracking IDs become aliases (type: tracking), so existing referral links continue to resolve.
- Referral history becomes conversions (historical) and obligations (fulfilled).
- Coupon assignments become aliases (type: coupon).
- Payout history becomes fulfillments and payouts (historical records).
- Commission rates require creating programs that match your current rate structure. If you have a 20% global rate and a few affiliates at 30%, you’ll create two programs.
What doesn’t migrate directly
Some AffiliateWP features have no Siren equivalent, either by design or because they haven’t been built yet.
- Creatives. Siren doesn’t have a built-in creative management system. Use WordPress pages or blocks to provide promotional materials to your collaborators.
- Campaign data. The campaign label that AffiliateWP attaches to visits and referrals has no equivalent in Siren.
- Direct Link Tracking. Not supported.
- Lifetime commission customer links. Roadmapped but not yet available.
- Per-affiliate rate overrides. These need to be restructured as separate programs with the appropriate rates.
- Active browser cookies. Visitors who clicked a referral link before the migration but haven’t purchased yet will lose their attribution. This is a narrow window for most sites, but worth considering if you use long cookie durations.
Database table reference
A quick reference for how AffiliateWP’s database tables map to Siren’s tables.
| AffiliateWP Table | Siren Equivalent |
|---|---|
| affiliate_wp_affiliates | Collaborators table + Aliases table |
| affiliate_wp_referrals | Conversions table + Obligations table |
| affiliate_wp_visits | Opportunities table |
| affiliate_wp_payouts | Fulfillments table + Payouts table |
| affiliate_wp_creatives | No equivalent |
| affiliate_wp_customers | Tracked through opportunities and engagements |